Faire de l’UX en environnement Agile

Est-ce-que la combinaison des deux fonctionne ? D’expérience : oui, mais je suis peut-être trop formatée 🙂

Même si concevoir l’expérience utilisateur en environnement Agile n’est pas confortable pour l’UX, il a tout à y gagner.

Pourquoi ce n’est pas confortable ?

Parce que la conception d’expérience utilisateur n’est a priori pas alignée sur la même temporalité que le développement.

Parce que le rôle de l’UX est à mi-chemin entre la conception en appui au PO et la production à délivrer aux UI / devs.

Parce qu’il est parfois annonciateur de mauvaises nouvelles.

Pourquoi les UX on tout à y gagner ? Et les autres membres de l’équipe aussi

Parce que si l’on y regarde de plus près, l’avènement des méthodologies UX dans le même temps que celui des frameworks Agiles est logique.

Sans rentrer dans les débats d’école au sein des multiples méthodologies brevetées, on retrouve fondamentalement le même but : créer un produit qui a le plus de valeur possible pour l’utilisateur.

Comment intégrer de manière efficace l’UX en environnement Agile ?

Phase 1 : recherche utilisateur

Chacun « est au monde » de manière différente, porte avec lui l’ensemble de ses déterminismes et de son existence (instant philo 😉). En clair : impossible de se mettre à la place d’un autre.

La meilleure façon connaître les besoins de son utilisateur reste d’aller à sa rencontre. Qui plus est dans le milieu au sein duquel il va utiliser notre produit.

Par exemple, pour avoir déjà conçu une application métier destinée à des mécaniciens auto, il m’aurait été impossible de comprendre comment ils allaient l’utiliser si je n’avais été à leur rencontre en atelier pour expérimenter le contexte d’usage de l’app : bruit, pression managériale, demande de satisfaction client…  Quant au langage de l’application que j’étais censée remplacer : elle s’adressait en ingénieur / informaticien à des mécaniciens. Ce n’était tout simplement pas la même langue.

Même si je suis une UX expérimentée, je n’aurais pu anticiper tout cela derrière mon écran.

Phase 2 : cadrage

Je suis convaincue qu’il faut commencer un projet par une phase de cadrage. Déjà, pour avoir un point de départ. Ensuite, pour pouvoir prendre du recul durant la phase de développement.

Lorsqu’on est perdu dans la forêt, il faut choisir une direction et avancer  tout droit au risque de tourner en rond. Les incréments issus d’une boucle itérative doivent donc garder le cap sur une vision produit. Sans empêcher que cette vision ne pivote suite à de nouvelles découvertes sur le terrain.

La vision doit donc être « grosse maille » et doit surtout assurer que l’on commence par nos hypothèses les plus fiables et à haute valeur : impact mapping, storymapping, Design Sprint…

L’important : ne pas perdre trop de temps / dépenser trop d’argent dans cette phase, sinon on aura du mal à pivoter / jeter. Éliminer les hypothèses invalides le plus tôt possible, surtout si ce sont celles auxquelles on accordait le plus de crédit.

Phase 3 : développement

La difficulté pour l’UX en environnement Agile, c’est qu’il doit garder à l’esprit, en parallèle, une vision produit long terme, et les prochains incréments.

Hypothèses

Déclarer et vérifier des hypothèses, si possible avant le développement, ce qui implique d’avoir :

  • Des hypothèses ! Un persona cible, un but, une façon de valider ou non l’hypothèse avec au choix : feedback qualitatif, quantitatif, changements de KPI…
  • 1 ou 2 sprints d’avance sur le développement (sans sprints, il va falloir jauger le temps nécessaire en fonction du rythme de l’équipe),
  • un process de tests bien huilé avec des keys users fiables et réactifs,
  • identifié les features à haute valeur que l’on va tester (on n’aura pas le temps de TOUT tester).

Echange avec l’équipe & découpage en incréments

L’important est que tout le monde soit au même niveau d’information.

Avec ou sans sprints la meilleure cérémonie reste pour moi le backlog grooming (ou review) pour échanger / co-créer avec l’équipe. Il permet d’avoir un échange à la croisée des visions produit, business, technique et utilisateur.

Grâce à cela on peut découper une vision UX designée pour coller à la vision produit « long terme » en petits incréments. Impossible de faire le mouvement inverse sous peine de perdre en cohérence dans l’architecture de l’info, les flows, le design…

Mais le but du jeu, c’est que lorsqu’on a atteint un incrément qui convient à utilisateur, on arrête de développement sur cette feature. Même si l’on n’a pas atteint la vision UX initiale (les UX sont très mauvais perdants à ce jeu 😀).

Phase 4 : on reprend tout depuis le début

On oublie souvent cette phase une fois que l’on est parti en développement. Pourtant il est nécessaire de prendre du recul (par exemple en fin de MVP, de release…) pour :

  • Tester son produit en conditions réelles (soft launches, pilotes…).
  • Recadrer la vision notamment avec les feedbacks du test (et si changement extérieur : concurrence, etc.).

Ça prend un peu de temps mais cela remet du sens, donne une phase de respiration à l’équipe, évite que les mauvaises habitudes ne reviennent au galop 😌.