Aide à prévenir les abus des utilisateurs

Qu’est-ce que l’abus des utilisateurs?

C’est lorsque vous maltraitez inutilement et (espérons-le) involontairement vos utilisateurs en apportant des modifications à la communauté d’utilisateurs qu’ils n’apprécient pas. Je sais qu’il est difficile de croire que tous vos utilisateurs n’attendent pas avec enthousiasme toutes vos modifications, mais c’est vrai. Il y a plusieurs raisons pour lesquelles vos utilisateurs peuvent ressentir cela:

– ils n’ont peut-être pas été avisés des changements, ils ont donc été pris par surprise – et ils n’étaient pas d’humeur pour une surprise

– ils n’ont peut-être pas le temps pour le moment d’apprendre les modifications et vous ne pourrez pas continuer à utiliser l’ancienne version tant qu’ils ne le feront pas

– le nouveau changement peut ne pas fonctionner réellement

– la nouvelle modification peut être incompatible avec les premières versions (par exemple pour accéder à vos données)

– le nouveau changement peut fonctionner mais il est perçu comme gratuit

– ils sont peut-être déjà fatigués de toutes les modifications que vous avez apportées récemment

– ils peuvent avoir leur propre couche de processus ou de comportement construite autour de votre version précédente, et maintenant cela est cassé et ils doivent la mettre à jour

Alors, qu’est-ce qui cause l’abus des utilisateurs?

Changement principalement. En règle générale, les utilisateurs n’aiment pas le changement. Bien sûr, ils veulent que le logiciel soit génial et ils réclament de nouvelles fonctionnalités, mais la plupart des gens ne sont pas enthousiastes à l’idée de prendre le temps d’apprendre une nouvelle façon de faire quelque chose qu’ils pourraient déjà faire.

Bien sûr, c’est un problème, car la plupart d’entre nous oeuvrent dans le domaine du changement. Nous avons des équipes de produits qui travaillent sans relâche pour ajouter de la valeur et offrir de nouvelles capacités à nos utilisateurs et clients. Les besoins changent, les technologies changent et les marchés changent, et nos logiciels doivent évoluer avec eux.

La solution aux abus des utilisateurs n’est pas d’empêcher le changement, c’est d’être intelligent dans le déploiement du changement.

En vérité, l’abus des utilisateurs a toujours été un problème, même avec les logiciels de bureau commerciaux. Consultez un magazine de logiciels datant de 15 ans et vous verrez à quel point les utilisateurs étaient frustrés par les modifications apportées à Windows et Office à l’époque. Mais en général, comme la fréquence de mise à jour des logiciels de film rétractable était naturellement limitée (généralement une à deux fois par an), les dégâts étaient limités.

Cependant, Internet a changé tout cela, de deux manières importantes. Tout d’abord, Netscape a introduit l’ère du téléchargement de logiciels, et le coût de la distribution de logiciels a considérablement baissé. Mais toujours au moins dans le modèle de téléchargement de logiciel, les utilisateurs pourraient contrôler le moment où leur logiciel a changé.

Mais ensuite sont venues les applications Web. Essentiellement, tous les logiciels d’application qui comptent sont désormais gérés côté serveur – il n’y a en fait qu’une seule installation du logiciel, et le créateur de ce logiciel décide quand et si ce logiciel sera modifié. Ils effectuent le changement une fois, et leurs millions d’utilisateurs le voient instantanément. Incroyablement puissant.

Mais avec ce pouvoir vient la responsabilité. Dans un environnement d’entreprise, si vous allez installer une nouvelle version de logiciel, vous planifiez généralement la mise à jour, notifiez les utilisateurs, préparez-les pour les temps d’arrêt, installez et testez, puis tenez les mains des utilisateurs alors qu’ils luttent pour traiter avec les nouveaux changements. Mais dans le modèle des applications Web, le logiciel est généralement remplacé par les utilisateurs.

Lorsqu’elles apportent un changement, peu d’organisations considèrent le véritable impact sur la communauté des utilisateurs. Ils se concentrent simplement sur leur coût interne (ou leur manque de coût car c’est pratiquement gratuit) et cela les amène à assumer que le changement est facile et gratuit, nous pouvons le faire aussi souvent que nous le souhaitons.

Ne vous méprenez pas. Je suis le plus grand champion de l’architecture d’applications Web pour clients légers que vous trouverez. En fait, je soutiens qu’il s’agit de la plus grande contribution à l’informatique et à la productivité individuelle de l’histoire de notre industrie. J’adore le peu de clients de bureau que je dois installer maintenant lorsque je reçois un nouvel ordinateur. Et vous pouvez imaginer comment cela réduit les coûts de gestion des entreprises. Et des technologies comme Ajax et Flash nous permettent en tant que fournisseurs d’applications de créer et de fournir une expérience utilisateur avec presque la richesse d’un gros client natif.

Maintenant, en vérité, si vous ne faites affaire qu’avec des utilisateurs précoces et si votre application n’est pas quelque chose dont vos utilisateurs dépendent réellement, vous pouvez la traiter en toute sécurité comme un grand bac à sable et la modifier aussi souvent que vous le souhaitez. J’admets que c’est un état amusant à vivre. Mais une fois que vous créez une communauté de toute taille, ou une fois que vous commencez à prendre de l’argent pour votre service, ou si votre service est quelque chose dont vos utilisateurs dépendent pour leur subsistance, alors vous devez soyez intelligent sur le déploiement des changements.

Il est particulièrement facile pour les équipes utilisant des méthodes Agiles (comme XP ou Scrum) de tomber dans ce piège, car la méthodologie encourage de nombreuses petites itérations. En fait, j’aime beaucoup les méthodes Agile et le principe de faire de nombreuses itérations, mais lorsque vous essayez d’utiliser des méthodes Agile pour des produits commerciaux avec des communautés actives d’utilisateurs, vous devrez ajuster les méthodes. Bien sûr, continuez avec les itérations courtes, mais ne livrez pas nécessairement chaque itération, car il peut être plus logique de regrouper plusieurs dans une version réelle pour les utilisateurs. (J’ai discuté ailleurs de la façon dont vous devriez tester vos modifications avec de vrais utilisateurs bien avant cette étape de toute façon, donc je ne reviendrai pas ici).

Alors, comment déployez-vous le changement?

Commencez par communiquer les changements à l’avance. Publier un aperçu contenant des captures d’écran est génial. Mais utilisez également des newsletters, des formations sur site et des tutoriels.

Deuxièmement, s’il y a des questions sur le bon fonctionnement de la nouvelle version de votre produit, que ce soit en raison de problèmes de fiabilité, d’échelle ou de performances, vous devez redoubler vos efforts de test pour essayer de vous assurer que vous n’aurez pas à revenir en arrière. vos mises à jour, ce qui aggrave considérablement l’angoisse de la communauté.

Troisièmement, si le changement est important, il est important de contenir le risque en poursuivant une certaine forme de déploiement en douceur – tel qu’un déploiement parallèle, progressif, géographique ou progressif. La plupart de notre secteur a récemment vu un excellent exemple de déploiement parallèle avec la nouvelle version de messagerie Web de Yahoo. Ils ont utilisé ces stratégies de déploiement progressif et je ne doute pas que cela leur a coûté considérablement de le faire, mais avec la taille et la vigueur de leur communauté de messagerie, je dirais qu’ils n’avaient pas le choix et qu’il leur aurait été fatal de faire autrement. .

Si vos utilisateurs aiment votre produit ou service, vous avez une réserve de bonne volonté sur laquelle vous pouvez vous appuyer, mais vous devez la conserver lorsque vous en avez vraiment besoin; ne gaspillez pas cette bonne volonté en abusant des utilisateurs.