Adapter la recherche aux équipes agiles
Au mieux, la recherche UX fait émerger des idées et facilite l’amélioration d’un produit ; au pire, elle représente un obstacle.
Cet article est une traduction en français de l'article original de Ben Ralph sur Medium : How to Stop UX Research being a Blocker.
Il existe différentes façons d’appréhender la recherche UX, mais celle que j’entends le plus fréquemment est “On n’a pas assez de temps”. Je peux assurément comprendre cette tendance à “seulement faire le boulot”. Avec le passage de projets en cascade micro-managés vers des équipes agiles transverses, il peut être difficile d’octroyer une place adéquate à la recherche au sein d’un quotidien très opérationnel.
Vos responsables UX font-ils partie d’une équipe agile pluridisciplinaire, ou sont-ils tous intégrés dans un service à part dans l’entreprise ?
Comment une équipe peut-elle mener de front la recherche, la conception, la réalisation et les tests d’une même fonctionnalité ?
Comment peut-on décider de ce qu’il faut réaliser, alors qu’on est précisément en train de le réaliser ?
Embarqué, mais bloquant
Un compromis répandu consiste à embarquer la recherche UX dans une équipe agile, mais en faisant en sorte que le chercheur travaille avec quelques sprints d’avance. Solution en apparence sensée, qui a cependant souvent pour conséquence indésirable de créer des tensions entre le chercheur UX et le reste de l’équipe.
Une équipe ne peut avancer qu’au rythme de son processus le plus lent — elle peut ainsi se retrouver bloquée par un responsable UX en s’efforçant de suivre une bonne pratique de conception.
Une autre limite de cette approche, c’est que vous avez tendance à recréer un processus en cascade au sein de votre équipe agile.
Enfin, cela ne fonctionne pas car une bonne recherche prend du temps. Il vous faut du temps pour aller sur le terrain ; il vous faut du temps pour comprendre les utilisateurs ; et il vous faut du temps pour suivre des idées qui aboutissent à des impasses autant de fois que nécessaire, avant de trouver l’idée maîtresse qui rendra le produit génial.
Ce type de recherche ne peut pas se cantonner à seulement un ou deux sprints.
Non bloquant mais abstrait
Une autre option rencontrée consiste à placer les responsables UX dans leur propre département, séparés des équipes agiles qu’ils épaulent, et travaillant souvent des semaines voire des mois en amont des développeurs.
Le problème évident ici c’est que la recherche est la plus performante lorsqu’elle est à jour et pertinente. La recherche utilisateur n’est bénéfique que si elle aboutit à d’excellentes expériences client. Plus les idées émanant de la recherche sont éloignées des usages réels, moins elles auront d’impact.
La plus grande faille de ce modèle est le risque d’être déconnecté du pragmatisme des développeurs et testeurs, les concepteurs pouvant être un peu trop créatifs.
Il en découle un gouffre entre les “expériences idéales” et ce qui peut être réalisé en pratique. Les concepteurs sont frustrés par les développeurs qui disent toujours non, et les développeurs s’usent en échouant constamment à réaliser les rêves fougueux de concepteurs à l’imagination débridée.
Comment embarquer l’UX en tant que double processus
Comme vous l’avez peut-être compris, c’est en tirant le meilleur des deux options que l’on doit concevoir la solution.
Il faut décider quelles activités UX doivent rester embarquées dans la structure de l’équipe agile, et quelles activités il convient de replacer dans leur propre temporalité.
L’UX “parallélisée”
Un bon moyen de visualiser cela est de séparer les activités de recherche en deux postes distincts : recherche fondamentale et recherche directionnelle.
La recherche fondamentale, ce sont les interviews d’utilisateurs et la recherche ethnographique qui créent de solides fondations pour la prise de décision.
La recherche directionnelle, ce sont les expérimentations ciblées sur un périmètre fonctionnel précis, souvent autour de questions d’ergonomie, que vous menez pour répondre à des questions spécifiques afin de dessiner au jour le jour la direction du produit.
La recherche directionnelle
La recherche directionnelle est ciblée et de courte durée. Elle est menée pour répondre à des questions spécifiques d’ergonomie et de désirabilité du produit.
La recherche directionnelle vit dans, et est dirigée par l’équipe agile. Pour que cela fonctionne correctement, les expérimentations doivent rester petites et autonomes. Elles doivent répondre à une question spécifique, ou valider une hypothèse précise.
La recherche directionnelle est communiquée au sein de l’équipe et plus largement dans l’entreprise de manière simple. Le résultat doit constituer en une réponse spécifique (oui ou non) à une réponse donnée, ou une recommandation concrète prête à être implémentée — et non pas un rapport de 14 pages.
Par exemple:
| Question
Le libellé du bouton doit-il être “Valider” ou “Enregistrer et continuer” ? |
Réponse
Nous avons mené un test A/B sur 500 visiteurs, et “Enregistrer et continuer” a montré une performance de 20% supérieure. |
| Question
Y a-t-il des problèmes d’ergonomie avec le design actuel des écrans ? |
Réponse
Nous avons mené un test d’ergonomie avec 6 participants et nous avons identifié 4 problèmes potentiels. Nous recommandons de (1) mettre davantage en évidence le bouton d’inscription, (2) changer le format du champ d’adresse afin qu’il accepte des boîtes postales, (3) bouger le ... |
| Question
Nous pensons qu’en ajoutant une nouvelle fonctionnalité, nos primo-utilisateurs trouveront le produit plus utile et passeront à la version payante. |
Réponse
Nous avons mené un test d’ergonomie sur un prototype et nous avons trouvé que nos primo-utilisateurs étaient noyés par les nouvelles fonctionnalités et ne sont pas passés à la version payante. |
La recherche fondamentale
La recherche fondamentale, ce sont les interviews d’utilisateurs et la recherche ethnographique que vous menez pour comprendre les souhaits, besoins, buts et motivations de vos utilisateurs, dans l’objectif d’obtenir une image bien définie de ceux-ci.
Remarquez que dans le diagramme ci-dessous la valeur de cette recherche fondamentale ne reste pas statique. Vous ne pouvez pas simplement parler avec vos utilisateurs une fois, et considérer que le travail est fait. Le marché change, les tendances technologiques changent, vos utilisateurs changent, et j’espère que votre produit change. Votre recherche devient moins pertinente et s’altère au fur et à mesure qu’elle vieillit.
Cela signifie que la recherche fondamentale doit être permanente. Les idées se construisent avec le temps et vous ne devriez jamais cesser de parler à vos utilisateurs et d’apprendre d’eux.
La recherche fondamentale doit être menée correctement. Les responsables UX doivent aller sur le terrain et observer les comportements des utilisateurs. L’équipe a besoin de poser d’innombrables questions à d’innombrables utilisateurs jusqu’à découvrir l’idée qui sera la pépite d’or à côté de laquelle tant d’entreprises avant vous sont passées.
Exemples
- Exploration ou recherche ethnographique
- Interviews d’utilisateurs
- Personas
- Cartographie du parcours client
- Cartographie d’empathie
- JTBD
Combiner les recherches fondamentale et directionnelle
Ces deux flux de recherche UX peuvent être menés indépendamment l’un de l’autre, ce qui permet aux recherches lentes et rapides de coexister.
Et comment faire pour que cela fonctionne dans mon équipe ?
Si vous êtes un lecteur assidu de Medium et du millier d’articles qui y parlent d’UX et de process produit, vous devriez savoir qu’il n’y a pas de réponse unique. Vous devez trouver ce qui fonctionne pour vous.
Donc à la place, voici 6 astuces qui vont contribuer à vous aider à implémenter vos process UX parallèles :
- Votre équipe agile est toujours la force centrale qui vous montre le cap
Pour que les équipes réussissent dans un environnement agile, elles doivent être réellement auto-gérées et autonomes. La recherche doit les aider à instruire leurs décisions, mais elles ne doivent pas suivre aveuglément les préconisations du responsable UX.
Cela signifie que l’équipe agile doit se sentir habilitée à la fois à démarrer la recherche, et à la mener.
- Soyez malin sur le dimensionnement et la gestion du temps
Tester un utilisateur en début de projet vaut mieux qu’en tester 50 vers la fin.
— Steve Krug
Il peut être tentant de vouloir mener toutes vos recherches dès le début. Il peut être tentant d’avoir les réponses à toutes vos questions avant de produire la moindre ligne de code.
Ce n’est pas réaliste. Vous ne savez jamais “tout” ce qu’il faut savoir sur un sujet spécifique.
Vous avez peut-être remarqué que plus vous en savez sur un sujet, plus vous voyez qu’il y a des choses à apprendre dessus.
Vous devez être capable de découper votre recherche en éléments petits, atteignables, limités dans le temps, et d’utiliser ce que vous avez appris pour en déduire où orienter la suite de votre recherche.
- Utilisez la puissance de l’équipe pour expérimenter
Vous avez une équipe pluridisciplinaire. Il faut qu’elle agisse en tant que telle.
Le meilleur moyen de comprendre les comportements des utilisateurs est de réaliser quelque-chose, le déployer et observer quel usage en font les utilisateurs. Là encore, commencez petit : demandez-vous quelle est la chose la plus élémentaire que vous pouvez fabriquer afin de répondre à la question clé que vous vous posez sur vos utilisateurs.
Les clients vont-ils acheter mon produit ?
Développez une page d’accueil, et observez combien d’utilisateurs cliquent sur “Acheter”.
Les clients vont-ils utiliser cette fonctionnalité ?
Créez un bouton pour cela et voyez s’ils cliquent dessus.
Le bouton doit-il s’appeler “S’inscrire” ou “S’enregistrer” ?
Réalisez un test A/B et trouvez la réponse.
Les développeurs et les testeurs peuvent être les meilleurs amis d’un responsable UX.
Une fois que vos expérimentations sont achevées, assurez-vous de prendre le temps d’apprendre de ce que vous avez découvert, et implémentez-le.
- Ménagez-vous du temps pour la refonte
Les (bons) développeurs prennent constamment le temps de refondre et nettoyer leur code. Nous devrions prendre le temps d’en faire autant avec nos expériences et nos designs d’interface.
Passer du temps à éponger la dette technique rend le code plus fiable et plus durable ; éponger notre dette UX en fait autant avec nos expériences client.
Développeurs, product owners : si vous consacrez un peu de temps à chaque sprint pour régler les problèmes d’interface au lieu d’accumuler toujours plus de nouvelles fonctionnalités, vous verrez que vos designers UX et UI se détendront et commenceront à travailler avec vous plutôt que contre vous.
- L’UX est une compétence et une responsabilité vraiment pluridisciplinaire
C’est trop important pour être limité à un seul membre de l’équipe.
Vous ne pouvez pas juste recruter un “scrum master” et vous décréter entreprise agile. De la même façon, vous ne pouvez pas juste recruter un unique designer UX et vous déclarer centré sur les personnes.
Chacun dans l’équipe doit penser à l’utilisateur. Le designer UX doit être le facilitateur de cet effort. Pas le responsable.
- En cas de doute, adoptez les principes Lean UX
En bref, la recherche UX ne peut être précipitée, mais elle doit aussi être plafonnée.
Certaines activités de recherche prendront plus de temps que d’autres, mais il est très important de distinguer la recherche qui fournit une valeur spécifique sur le moment de la recherche qui porte ses fruits stratégiquement sur le long terme.
Les méthodes de recherche fondamentale vous aideront à décider où vous voulez aller, tandis que les méthodes de recherche directionnelle vous donneront les repères au fil de la navigation pour savoir comment y aller.
