Comment déployer de nouvelles fonctionnalités sans blesser les utilisateurs fidèles

« Soyez agile ; libérer tôt; relâchez souvent. Nous connaissons l'exercice. Mais est-il stratégiquement judicieux de continuer à déployer souvent des fonctionnalités ? Surtout une fois qu'un produit que vous construisez atteint une certaine taille, vous ne voulez probablement pas risquer l'intégrité de votre application à chaque nouvelle version mineure.

La pire chose qui puisse arriver à votre produit est que les utilisateurs fidèles, les clients qui ont utilisé cette petite fonctionnalité de manière constante au fil des ans, ne sont soudainement plus en mesure de l'utiliser de la même manière pratique. Le changement peut donner plus de pouvoir aux utilisateurs, mais l'expérience devient moins simple. La frustration et l'anxiété envahissent les médias sociaux rapidement et soudainement, et la pression sur le support client pour répondre de manière significative et dans les délais augmente à chaque minute. Bien sûr, nous ne voulons pas déployer de nouvelles fonctionnalités pour nous rendre compte qu'elles nuisent en fait aux utilisateurs fidèles.

Lectures complémentaires sur SmashingMag : Lien

• Comment nous avons commencé à publier des fonctionnalités deux fois plus vite
• La liste de contrôle de lancement de site Web - 15 vérifications essentielles avant de passer en direct
• Une approche centrée sur l'utilisateur de la conception Web pour les appareils mobiles
• Comment lancer n'importe quoi

Nous pouvons éviter cela en étant plus stratégiques lors du déploiement de nouvelles versions de nos produits. Dans cet article, nous examinerons une stratégie permettant aux concepteurs de produits et aux ingénieurs frontaux de tester et de déployer en profondeur une fonctionnalité avant de la diffuser à l'ensemble de la base d'utilisateurs, et comment éviter que les problèmes UX ne se propagent sur la route.

Avant de plonger dans une stratégie de test réelle, revenons en arrière et examinons les idées fausses courantes sur la façon dont une nouvelle fonctionnalité est conçue, construite et finalement déployée.

Idées fausses sur les nouvelles fonctionnalités

Chaque fois qu'une nouvelle fonctionnalité pour un produit existant est conçue, l'accent est généralement mis sur la manière exacte dont elle doit être intégrée dans l'interface existante. Pour assurer la cohérence, nous, les concepteurs, examinons souvent les modèles existants et appliquons le langage de conception établi pour que la nouvelle fonctionnalité s'intègre bien dans l'interface utilisateur. Cependant, les problèmes surviennent souvent non pas parce que les composants ne fonctionnent pas ensemble visuellement, mais plutôt parce qu'ils s'avèrent déroutants ou ambigus lorsqu'ils sont combinés de manière inattendue .

Peut-être que la copie de l'interface est ambiguë dans des zones connexes mais distantes du site Web, ou que le résultat de deux fonctionnalités activement utilisées en même temps a du sens d'un point de vue technique mais ne correspond pas aux attentes de l'utilisateur ou a des implications majeures en termes de performances et nuit à l'UX .

En fait, dans la conception, ce sont ces nombreuses combinaisons qui sont si difficiles à prévoir et à examiner de manière approfondie. Une façon d'aborder le problème tout en étant déjà dans le processus de conception est de considérer les valeurs aberrantes - des cas d'utilisation où les choses sont plus susceptibles de mal tourner. À quoi ressemblerait un profil d'utilisateur si le nom de l'utilisateur était très long ? Un aperçu des e-mails sans réponse est-il toujours évident lorsqu'une douzaine d'étiquettes de boîte de réception sont utilisées ? Un nouveau filtre aurait-il un sens pour les utilisateurs qui viennent de s'inscrire et qui n'ont que quelques e-mails dans leur boîte de réception ?

Concevoir des valeurs aberrantes : la pile de l'interface utilisateur

Comment pouvons-nous exactement concevoir les valeurs aberrantes une fois que nous les avons identifiées ? Une bonne stratégie consiste à étudier les différents états de l'interface utilisateur. La "pile d'interface utilisateur", une idée introduite par Scott Hurff, est polyvalente et compliquée, et lorsque nous concevons nos interfaces, il ne suffit généralement pas de créer une maquette au pixel près dans Photoshop, Sketch ou HTML et CSS - nous devons considérer divers cas et états limites : l'état vide, l'état de chargement, l'état partiel, l'état d'erreur et l'état idéal. Ce ne sont pas aussi simples qu'on pourrait le penser.

L'état vide n'a pas besoin d'être vide - nous pourrions utiliser des techniciens de service pour offrir une meilleure expérience hors ligne aux visiteurs réguliers. L'état partiel n'a pas besoin d'être cassé - nous pourrions améliorer l'expérience avec des images cassées et du JavaScript cassé grâce à une amélioration progressive.

L'état idéal peut différer considérablement de nos maquettes de "résultat parfait" - en raison des préférences personnalisées de l'utilisateur et du choix du navigateur de l'utilisateur ; certains contenus et certaines polices Web peuvent ne pas s'afficher en raison de la configuration d'un navigateur, par exemple.

Ainsi, le paysage est, comme toujours, complexe, alambiqué et imprévisible, et nous ne pouvons pas rendre négligeable le risque que les choses tournent mal, mais cela ne signifie pas que nous ne pouvons pas minimiser efficacement le risque. En explorant les valeurs aberrantes et l' ensemble de la pile d'interface utilisateur dès le début, nous pouvons prévenir les problèmes UX courants dès les premières étapes de la conception. Cela ne devient pas plus facile sur le plan technique, cependant.

L'effet papillon dans le déploiement

Même des modifications mineures ont tendance à entraîner des réactions en chaîne, introduisant des bogues dans des domaines et des situations qui semblent absolument sans rapport. La raison principale en est la quantité de variables qui influencent l'expérience utilisateur mais qui sont hors de notre contrôle. Nous connaissons nos habitudes avec les navigateurs, mais cela ne signifie pas que nous en savons plus sur le contexte dans lequel un utilisateur choisit de voir le site Web que nous avons si inlassablement et minutieusement conçu.

Maintenant, alors que des changements mineurs comme le rembourrage sur un bouton ou une zone de texte progressivement améliorée peuvent ne pas sembler être un gros problème, nous avons tendance à sous-estimer l'impact de ces petits changements brillants ou fonctionnalités à grande échelle. Chaque fois que nous prenons une décision de conception ou de développement, ce changement a un effet sur le système complexe que nous construisons, principalement parce que les composants que nous construisons n'existent jamais isolément.

La réalité est que nous ne construisons jamais simplement un bouton, ni n'écrivons jamais une nouvelle fonction JavaScript - les boutons et les fonctions appartiennent à une famille de composants ou de bibliothèques, et ils fonctionnent tous dans un certain cadre, et ils sont inévitablement connectés à d'autres parties du système par leurs propriétés ou par leur portée ou par leur nom ou par les conventions non écrites de l'équipe.

Ces connexions « silencieuses » à peine perceptibles sont la raison pour laquelle le déploiement de fonctionnalités est difficile et pourquoi la prévision des conséquences à long terme d'un changement s'avère souvent être un exercice de perspicacité. C'est pourquoi c'est une bonne idée d'éviter autant que possible les dépendances inutiles, que ce soit dans CSS ou JavaScript - elles ne vous aideront pas pour la maintenance ou le débogage, surtout si vous comptez sur une bibliothèque que vous ne comprenez pas entièrement .

Heureusement, pour mieux comprendre l'impact d'un changement, nous pouvons utiliser des ressources telles que les outils de développement d'un navigateur. Nous pouvons mesurer la portée d'un sélecteur ou la portée d'une fonction JavaScript, et parfois il peut être judicieux d'y revenir pendant le développement pour garder la portée du changement aussi locale et minimale que possible.

C'est utile, mais ce n'est aussi qu'une partie de l'histoire. Nous formulons des hypothèses, consciemment et inconsciemment, sur la base de notre propre expérience de l'interface et de nos propres habitudes - oubliant souvent que les hypothèses peuvent (et, par conséquent, varieront ) considérablement d'un utilisateur à l'autre. La plupart des applications n'ont qu'une seule interface, mais cette interface ou ses configurations peuvent avoir des dizaines d'états, les vues changeant en fonction des paramètres et des préférences de l'utilisateur.

Pensez à des tableaux de bord avec des cartes personnalisables (logiciel d'analytics), des clients de messagerie avec des vues "compactes", "confortables" et "détaillées" (Gmail), une interface de réservation qui change pour les clients connectés et pour les invités, une expérience de lecture pour les personnes utilisant un bloqueur de publicités ou un filtre antivirus agressif. L'effet papillon a un impact sur plus que la base de code ; tous ces facteurs externes pèsent également, et les tester par rapport à eux - contrairement aux tests unitaires ou à l'assurance qualité en général - est très difficile car nous ne savons souvent même pas sur quoi tester.

Validation des fonctionnalités et maximum local

Nous pouvons utiliser des diagnostics et des métriques pour déterminer les modifications à apporter, mais en suivant uniquement les données, vous risquez de stagner à ce que nous avons tendance à appeler un "maximum local", un état de l'interface avec une conception suffisamment bonne mais qui manque totalement d'innovation car il suit toujours des itérations prévisibles et logiques. Lorsque nous travaillons sur un projet et explorons les données, nous avons tendance à regrouper les fonctionnalités dans les quatre compartiments suivants :

• Caractéristiques brisées. . Fonctionnalités qui semblent cassées ou inefficaces — évidemment, nous devons les corriger ;
• Fonctionnalités inutilisées. . Des fonctionnalités qui fonctionnent comme prévu mais qui sont rarement utilisées - souvent un signe qu'elles doivent être supprimées ou qu'elles ont désespérément besoin d'innovation ;
• Caractéristiques d'utilisation inattendues. . Des fonctionnalités qui sont utilisées d'une manière extrêmement différente de ce que leurs créateurs avaient initialement envisagé - un bon candidat pour un raffinement lent et continu;
• Caractéristiques de la bête de somme. . Des fonctionnalités qui sont fortement utilisées et semblent fonctionner comme prévu - auquel cas nous nous demandons s'il existe un moyen d'améliorer encore leur UX en explorant à la fois le processus itératif lent et des concepts innovants entièrement différents en parallèle.

Les deux premiers compartiments sont essentiels pour maintenir une interface fonctionnelle et utilisable, tandis que les deux derniers sont essentiels pour maintenir l'engagement et la satisfaction des utilisateurs. Idéalement, nous voulons atteindre les deux objectifs en même temps, mais les contraintes de temps, de budget et d'équipe ont le dessus.

Pourtant, une fois qu'une nouvelle itération ou une nouvelle idée est choisie, il peut être tentant de se lancer immédiatement dans la conception ou la construction de la nouvelle fonctionnalité. Mais avant même de penser à la façon dont une fonctionnalité s'intégrerait dans une interface existante, il est judicieux de valider d'abord l'idée - avec un prototype rapide et une recherche d'utilisateurs. Un moyen courant d'y parvenir consiste à utiliser un processus itératif rapide, tel que le sprint de conception de Google Ventures. En itérant en quelques jours, vous pouvez identifier comment la nouvelle fonctionnalité doit être implémentée et/ou si elle est utile de la manière dont vous l'aviez imaginée initialement.

Avec les sprints de conception, nous exposons l'idée à la recherche d'utilisabilité dès le début. Dans la méthodologie de Google Ventures, vous testiez une conception avec cinq utilisateurs par jour ; ensuite, vous itéreriez et passeriez par une autre série de tests de la nouvelle conception. La raison pour laquelle tous les mêmes utilisateurs sont impliqués est que si vous testez une conception différente avec chaque utilisateur ce jour-là, vous n'auriez aucune donnée valide pour savoir quels éléments doivent changer. Vous avez besoin de quelques utilisateurs pour valider une itération de conception.

Nous appliquons un modèle légèrement différent dans nos sprints. Lorsque nous commençons à travailler sur une nouvelle fonctionnalité, une fois qu'un premier prototype est construit, nous réunissons les concepteurs, les développeurs et l'équipe UX dans la même pièce, invitons de vrais utilisateurs à tester, puis itérons selon un calendrier serré. Le premier jour, les premiers testeurs (deux à trois personnes) peuvent être programmés pour un entretien de 30 minutes à 9h00, le deuxième groupe à 11h00, le suivant à 14h00 et le dernier une vers 16h00. Entre les entretiens avec les utilisateurs, nous avons des "fenêtres ouvertes", lorsque nous itérons réellement sur la conception et le prototype jusqu'à ce qu'à un moment donné, nous ayons quelque chose de viable.

La raison en est que, très tôt, nous voulons explorer rapidement des directions entièrement différentes, parfois même opposées; une fois que nous avons recueilli des commentaires sur différentes interfaces, nous pouvons converger vers ce qui ressemble à l' interface "maximum absolu" . Nous pouvons ainsi obtenir plus rapidement des commentaires très divers sur des itérations de conception très diverses. Les commentaires sont principalement basés sur trois facteurs : les cartes thermiques qui enregistrent les clics des utilisateurs, le temps dont les utilisateurs ont besoin pour accomplir une tâche et la qualité de l'expérience pour eux. Plus tard dans la semaine, nous continuons à travailler de manière cohérente avec un plus grand nombre d'utilisateurs, tout comme Google le fait, validant en permanence le nouveau design au fur et à mesure.

Jusqu'ici tout va bien, mais parfois une nouvelle fonctionnalité apparemment innovante entre en collision avec une fonctionnalité existante, et les avoir toutes les deux dans la même interface encombrerait la conception. Dans ce cas, nous examinons si l'une des options pourrait être considérée comme une extension de l'autre. Si cela pouvait l'être, alors nous commençons par réitérer sa fonctionnalité et son design. C'est alors que nous devons choisir une refonte radicale ou un changement progressif. Ce dernier est moins risqué et conservera un modèle d'interaction familier pour les utilisateurs, tandis que le premier est nécessaire si des changements critiques sont impossibles à réaliser autrement ou si les gains des changements incrémentiels seraient trop superficiels.

Dans les deux cas, il est essentiel de se concentrer sur l'ensemble de l'expérience utilisateur du produit, plutôt que sur la valeur d'une seule fonctionnalité au sein de ce produit. Et une fois que vous avez choisi la fonctionnalité et que vous avez conçu et construit le premier prototype, il est temps de tester.

Les huit niveaux de test

Alors, comment empêcher efficacement les erreurs et les échecs de se glisser dans un environnement réel ? Combien de vérifications, d'examens et de tests effectuons-nous avant qu'une fonctionnalité ne soit déployée ? Et dans quel ordre exécutons-nous ces tests ? En d'autres termes, à quoi ressemblerait la stratégie ultime de déploiement des fonctionnalités ?

L'une des meilleures stratégies de déploiement de fonctionnalités a été proposée par Andrew Sumin, responsable du développement chez Mail.ru, un important fournisseur de messagerie en Russie. La stratégie ne serait pas applicable à tous les projets, mais il s'agit d'une approche raisonnable et complète pour les entreprises qui proposent des produits de taille moyenne et grande à des milliers de clients.

Examinons la stratégie en détail et couvrons les huit étapes d'un déploiement de fonctionnalités, couvrant le processus de développement de produits de Mail.ru :

1. tester avec les développeurs,
2. tester avec de vrais utilisateurs dans un environnement contrôlé,
3. tester avec des utilisateurs de toute l'entreprise,
4. tester avec des bêta-testeurs,
5. tester avec des utilisateurs qui s'inscrivent manuellement,
6. split-test et vérification de la rétention,
7. relâcher lentement et progressivement,
8. mesurer la suite.

Dans le cas de Mail.ru, la fonctionnalité la plus importante à garder intacte, peu importe ce qui compose un message (évidemment). C'est la partie la plus utilisée de l'interface, et lui permettre d'être indisponible ou de ne pas fonctionner correctement même pendant quelques secondes serait absolument hors de question. Et si nous voulions étendre les fonctionnalités d'une zone de texte, peut-être en ajoutant quelques fonctions de saisie semi-automatique intelligentes, un compteur ou un aperçu latéral ?

1. Testez avec les développeurs

Plus le temps passe dans le développement, plus il devient coûteux de résoudre un problème. Encore une fois, réfléchissez à la façon dont toutes les décisions sont liées dans le développement de produits ; plus le produit est raffiné, plus il faut revenir sur les décisions, ce qui coûte du temps et des ressources. Ainsi, l'identification et la résolution précoces des problèmes concernent à la fois une perspective commerciale et une perspective de conception et de développement.

Vous ne pouvez pas déboguer une idée, cependant, les tests initiaux doivent avoir lieu pendant la production, sur les tout premiers prototypes. Les premiers testeurs de Mail.ru sont donc les développeurs qui écrivent réellement le code. L'entreprise encourage ses employés à utiliser le produit pour la communication interne (et même la communication privée) ; ainsi, les développeurs pourraient être considérés comme des utilisateurs invétérés du produit.

La première étape est assez évidente : concevez et créez la fonctionnalité, puis testez-la localement, révisez-la et déployez-la sur le serveur intermédiaire. C'est là qu'interviennent les tests d'assurance qualité, avec des outils complets et des exécuteurs de tâches qui tentent de planter la fonctionnalité et l'interface, potentiellement automatisés avec des outils de test de singe tels que Gremlins.js.

Les résultats sont surveillés puis renvoyés dans la boucle de rétroaction pour la prochaine itération de la fonctionnalité. À un moment donné, les développeurs se sentiront assez confiants avec la construction : le changement semble fonctionner comme prévu et les exigences ont été respectées. C'est alors que les vrais tests utilisateurs entrent en jeu.

2. Testez avec de vrais utilisateurs dans un environnement contrôlé

Lorsque le premier prototype fonctionnel est terminé, la fonctionnalité est testée auprès d'utilisateurs réels lors d'entretiens. Les clients sont invités à effectuer des tâches et, ce faisant, l'équipe UX surveille les impasses et les problèmes qui surgissent et les résout sur place.

Cependant, non seulement la nouvelle fonctionnalité est testée ; l'objectif du test d'utilisabilité est de s'assurer que la nouvelle fonctionnalité n'affecte pas les composants critiques de l'interface, c'est pourquoi les utilisateurs effectuent des tâches de routine, telles que composer un message et ouvrir, répondre et parcourir les e-mails dans leur boîte de réception. Si la nouvelle fonctionnalité et les anciennes fonctionnalités sont bien comprises, le processus peut continuer.

3. Testez avec des utilisateurs de toute l'entreprise

De toute évidence, les commentaires du test d'utilisabilité incitent les développeurs à introduire des modifications, qui sont ensuite renvoyées aux testeurs d'utilisabilité, en faisant des allers-retours jusqu'à ce que le résultat semble avoir de la valeur pour un public plus large. La prochaine étape consiste donc à mettre la fonctionnalité en lumière au sein de l'entreprise : un e-mail à l'échelle de l'entreprise est envoyé pour encourager tous les collègues à vérifier la fonctionnalité et à soumettre des rapports, des bogues et des suggestions dans un outil de suivi.

Avec les tests, il n'y a pas de différence particulièrement grande entre les utilisateurs des services « distants » au sein de l'entreprise et les utilisateurs dans la nature. Même les utilisateurs internes ne savent pas à quels changements s'attendre ou ne savent pas exactement ce que fait une fonctionnalité ou comment elle est censée fonctionner ou ressembler. La seule différence principale est que les collègues peuvent être invités à soumettre rapidement des commentaires ou à laisser un commentaire. C'est alors que les formulaires de vote sont introduits. Les testeurs peuvent non seulement jouer avec la fonctionnalité, mais également ajouter un commentaire et voter pour ou contre. Le vote doit être mis en balance avec la stratégie produit et les exigences commerciales, mais si les utilisateurs trouvent clairement une fonctionnalité inutile ou utile, c'est un moyen simple et efficace de recueillir des commentaires et de tester si le produit fonctionne comme prévu.

4. Testez avec des bêta-testeurs

Si une fonctionnalité a passé un contrôle technique, un contrôle d'utilisabilité et un examen au sein de l'entreprise, la prochaine étape logique consiste à la présenter à certains segments du public. Cependant, au lieu de le déployer à un segment aléatoire d'utilisateurs, l'équipe soumet une fonctionnalité à l'examen des bêta-testeurs - les utilisateurs qui ont choisi de participer aux tests et de soumettre des commentaires sur les fonctionnalités expérimentales. Ils peuvent voter contre ou pour une fonctionnalité, ainsi que signaler des bogues et valider des morceaux de code.

Mais comment choisir les bêta-testeurs appropriés ? Eh bien, si vous voulez encourager les testeurs à casser l'interface, vous pouvez vous concentrer sur les utilisateurs fidèles avancés avec des compétences techniques - les utilisateurs qui seraient en mesure de fournir des détails techniques sur un bogue si nécessaire, et les utilisateurs qui connaissent suffisamment bien l'interface existante pour être capable d'anticiper les problèmes que d'autres utilisateurs pourraient avoir.

Cependant, vous avez besoin de critères pour déterminer si un utilisateur est suffisamment avancé pour être un testeur bêta. Dans le cas d'un client de messagerie, il peut s'agir de quelqu'un qui utilise Chrome ou Firefox (c'est-à-dire qu'il sait comment changer son navigateur par défaut), qui a créé plus de trois dossiers dans sa boîte de réception et qui a également installé l'application mobile.

5. Testez avec des utilisateurs qui s'inscrivent manuellement

Jusqu'à présent, les tests ont impliqué un nombre gérable d'utilisateurs, de configurations et de rapports de test. Pourtant, la diversité des utilisateurs, des systèmes et des configurations dans la nature, y compris le système d'exploitation, le navigateur, les plug-ins, les paramètres réseau, les logiciels antivirus et autres applications installées localement, peut être légèrement plus décourageante.

Dans le cas de Mail.ru, l'étape suivante consiste à déployer la fonctionnalité dans une interface en direct, derrière un drapeau, et à envoyer un e-mail à ce segment plus large d'utilisateurs actifs, en présentant la nouvelle fonctionnalité et en les invitant à l'activer sur leur propre dans l'interface, généralement avec un bouton brillant "Mettre à jour". Pour mesurer la valeur de la fonctionnalité pour les utilisateurs réels, l'équipe utilise à nouveau un système de vote, avec quelques invites ici et là, demandant essentiellement aux utilisateurs s'ils trouvent la fonctionnalité utile ou utile. Notez que la différence entre ce niveau et le niveau précédent est que l'opt-in manuel implique un public beaucoup plus large - dont beaucoup ne sont pas du tout techniques, contrairement aux bêta-testeurs.

Ainsi, le timing et la coordination comptent . Vous ne choisiriez probablement pas un jour au hasard pour envoyer l'e-mail aux utilisateurs actifs, car vous souhaiterez que l'équipe de support client et les développeurs soient disponibles lorsque le flux de rapports de bogues commencera à arriver. C'est pourquoi l'e-mail est envoyé à le début de la semaine, lorsque tous (ou la plupart) des développeurs sont disponibles et que l'équipe de support est prête à passer à l'action, après avoir été informée et activement connectée avec les développeurs via Skype ou Slack. Dans une petite entreprise, vous pouvez même demander aux développeurs de s'asseoir pendant quelques heures aux bureaux d'assistance pour s'attaquer plus rapidement au cœur d'un problème en s'adressant directement aux clients.

6. Split-Test et vérification de la rétention

Dans les étapes jusqu'à présent, à l'exception des tests d'utilisabilité, tous les testeurs ont utilisé la nouvelle fonctionnalité volontairement. Cependant, si vous activez la fonctionnalité par défaut, les utilisateurs devront soudainement l'utiliser, et il s'agit d'un type de groupe très différent, que nous n'avons pas du tout testé.

Pour vous assurer de ne pas briser les habitudes des utilisateurs passifs, vous pouvez effectuer un test fractionné avec trois petits segments d'utilisateurs et mesurer la rétention . Après tout, vous voulez vous assurer qu'une nouvelle version fonctionne au moins aussi bien que la précédente. Identifiez l'activité la plus importante dans l'interface et mesurez non seulement le temps que les utilisateurs y consacrent avant et après le déploiement, mais également le temps qui s'écoule jusqu'à leur retour. Dans le cas de Mail.ru, la rétention implique que les utilisateurs vérifient leur courrier électronique et rédigent un message. Plus un utilisateur revient souvent, plus la rétention est élevée, ce qui est un indicateur d'une meilleure UX.

Chaque segment obtient une vue légèrement différente , ce qui nous permet de tester ultérieurement comment afficher la nouvelle fonctionnalité à tous les utilisateurs. Pour le premier segment, nous ajoutons la nouvelle fonctionnalité et fournissons un tutoriel sur la façon de l'utiliser. Pour le deuxième segment, nous ajoutons simplement la nouvelle fonctionnalité. Pour le troisième segment, nous pourrions laisser la fonctionnalité telle quelle. Pour tous ces segments, nous pourrions mettre en œuvre le changement en même temps, sélectionner un délai raisonnable pour exécuter le test, mesurer la rétention, puis comparer les résultats. Plus la rétention d'un segment est élevée, plus il est probable que la conception sera promue à tous les utilisateurs par la suite.

7. Relâchez lentement et progressivement

Si une fonctionnalité a atteint ce stade, elle fonctionne probablement déjà bien pour un large segment de l'audience. C'est à ce moment-là que vous pouvez le déployer progressivement à tous les utilisateurs - avec une invite de vote pour recueillir des commentaires. Si les commentaires sont généralement positifs, vous pouvez continuer à déployer la fonctionnalité et elle finira par devenir une partie intégrante de l'interface. Sinon, vous évalueriez les commentaires et reviendriez au laboratoire pour la prochaine itération.

Cependant, déployer la fonctionnalité ne suffit pas : elle doit être communiquée aux utilisateurs. Une façon courante de le faire est d'utiliser le courrier électronique et les médias sociaux. Néanmoins, un didacticiel rapide expliquant la valeur de la fonctionnalité dans des scénarios réels pourrait également être utile. N'oubliez pas non plus d'intégrer une boîte à suggestions pour recueillir des commentaires immédiatement.

8. Mesurez les conséquences

Une fois la fonctionnalité déployée, nous pouvons surveiller ses performances et essayer différentes méthodes pour attirer l'attention sur elle, afin que les utilisateurs puissent effectuer leurs tâches plus efficacement. Vous pouvez suivre les tâches les plus courantes ou les pages les plus visitées, puis afficher une petite note en ligne recommandant à l'utilisateur un moyen légèrement plus intelligent et plus rapide d'atteindre son objectif, puis mesurer si l'utilisateur préfère cette nouvelle fonctionnalité ou la méthode habituelle.

N'oubliez pas de faire part de vos commentaires à toute l'équipe, pas seulement aux développeurs ou aux concepteurs, afin qu'ils soient motivés et engagés et qu'ils voient comment les gens utilisent une fonctionnalité qui n'était au départ qu'une idée approximative. Rien n'est plus motivant que de voir des personnes heureuses et ravies utiliser une application exactement comme vous l'aviez imaginé, ou de manière totalement différente. Cela nourrira également la croissance des fonctionnalités ultérieures de l'équipe.

Le processus d'examen semble complexe et approfondi, mais parfois, seuls le temps et un large réseau de tests utilisateurs permettront de découvrir un problème. Par exemple, si une modification affecte l'apparence de la vue d'ensemble des messages entrants, aucun test unitaire ne peut révéler les difficultés que les utilisateurs de logiciels d'assistance pourraient rencontrer. Dans une interface de messagerie, que voulez-vous que le dispositif d'accessibilité lise en premier : la date, l'expéditeur, la ligne d'objet ou le message lui-même ? La façon dont vous réorganisez les colonnes dans la vue d'ensemble peut modifier la façon dont les utilisateurs choisissent d'accéder aux informations ; donc, leur permettre de désactiver la nouvelle fonctionnalité serait également critique.

Conclusion

Alors, à quoi ressemble une stratégie de déploiement ? Vous pouvez commencer par explorer le graphique des dépendances pour comprendre l'ampleur de votre changement. Ensuite, vous pouvez tester la fonctionnalité avec des développeurs et avec de vrais utilisateurs dans un environnement contrôlé. Ensuite, vous pouvez demander à des collègues d'examiner la fonctionnalité avant de l'envoyer à un groupe sélectionné de bêta-testeurs. Enfin, vous pouvez rendre la fonctionnalité disponible en option pour les utilisateurs. Et, avant d'activer la fonctionnalité pour tout le monde, vous pouvez exécuter un test fractionné pour déterminer la meilleure façon d'introduire la fonctionnalité, puis mesurer les taux de rétention pour les tâches critiques.

Évidemment, le déploiement n'est pas un processus linéaire . Tout au long du processus, vous devrez peut-être reculer de deux pas pour avancer d'un pas - jusqu'à ce que vous ayez enfin un candidat à la publication. Le flux de travail décrit ci-dessus peut sembler assez lent et pas particulièrement agile, mais vous minimisez considérablement le risque que les utilisateurs soient soudainement confrontés à un problème inattendu et aient une expérience inférieure en conséquence. Dans certaines situations, cela peut en valoir la peine.