Intégrer l’UX dans une approche Agile : retour d’expérience

Quand je suis arrivée dans mon entreprise actuelle pour y intégrer un poste d’ergonome / UX designer, j’ai tout de suite eu un excellent feeling avec le Scrum Master de la boite. Au milieu de tous ces développeurs le nez plongé dans leur code, lui me parlait de se concentrer sur les besoins utilisateurs, de raisonner en « User Stories » pour définir les priorités (« En tant qu’utilisateur·trice, je veux… afin de… ») et d’apporter de la valeur pour l’usager·e. Nos objectifs semblaient simples à concilier, et j’ai très vite adhéré à l’approche Scrum.

D’ailleurs, d’après un article que j’ai lu récemment, l’UX et l’agilité sont parfaitement complémentaires : les principaux inconvénients de l’UX seraient compensés par les avantages procurés par l’agilité, et réciproquement. Néanmoins, mon expérience a montré que la mise en pratique est plus compliquée qu’elle n’en a l’air.

Rappelons d’abord en quelques mots ce que sont l’UX et l’agilité.

L’UX design, pour User eXperience design, consiste à essayer d’optimiser l’expérience que vivra l’usager·e lors de l’utilisation du produit développé par l’équipe. S’appuyant sur les sciences humaines et la démarche ergonomique, l’UX designer a pour but de créer des expériences d’utilisation notables, afin de donner envie à l’utilisateur·trice de revenir utiliser le service, d’en parler autour de lui ou elle, etc. Pour cela, on implique au maximum l’utilisateur·trice au travers d’interviews, d’observations en situation de travail, de tests, etc.

L’agilité est une approche permettant de réduire les risques grâce à l’échange et la transparence avec le client, afin de permettre un ajustement permanent et une relation gagnant-gagnant. Pour cela, l’équipe de développement produit et livre de manière itérative des versions fonctionnelles avec de plus en plus de valeur, en adoptant une stratégie d’amélioration continue (à la fois du produit et de l’équipe).1

Intégrer l’UX dans une approche Agile permet de concevoir un produit qui apportera satisfaction au client et à l’utilisateur·trice cible.

C’est également là que cela se complique. Car le ou la Product Owner (la personne qui est responsable du produit livré, et notamment de prioriser les choses à faire) aura tendance à favoriser le fonctionnel, pour répondre aux besoins du client qui fait le chèque en fin d’année : ajouter un moteur de recherche, ajouter ceci, ajouter cela. Le client a payé pour ces fonctionnalités, et notre entreprise a le devoir de remplir son contrat. Et il sera souvent compliqué pour l’UX designer de défendre le point de vue selon lequel un message d’erreur ici ou une animation de transition là a plus de valeur qu’une nouvelle fonctionnalité demandée ou attendue par le client. Et pourtant…

Pourtant, si l’on souhaite que l’utilisateur·trice cible utilise le service, si l’on souhaite qu’il ou elle revienne, et même si l’on souhaite uniquement qu’il ou elle aille au bout de sa démarche sans abandonner en cours de route par manque de compréhension ou par agacement, ce message d’erreur et cette animation sont cruciaux. Lors des tests utilisateurs, les gens sont de bonne volonté, ils·elles cherchent, et finissent par trouver. Dans la vraie vie, si l’utilisateur·trice ne comprend pas en quelques secondes, il ou elle va voir ailleurs. Et en termes de retour sur l’investissement, la perte d’un·e usager·e peut coûter plus cher que ce qu’apporterait une fonctionnalité supplémentaire.

Alors comment intégrer vraiment l’UX dans les projets Agiles ?

Trois éléments clés :

1. Dissocier en UX comme pour le reste, le « must have » dont l’absence génère des abandons du « nice to have ».

Pour moi, le « must have » correspond à tout ce qui est nécessaire et suffisant pour que la personne utilisant notre produit comprenne intuitivement où elle est, ce qu’elle fait, et pourquoi cela ne fonctionne pas le cas échéant. Pour m’aider à avoir les idées claires sur ce point là, j’ai récemment créé un tableau Excel avec une ligne par fonctionnalité, et des colonnes par type d’éléments, classés selon les critères de Bastien et Scapin2. J’ai ainsi des colonnes pour le guidage (tooltip, message d’aide, feedback minimal, feedback sympa), pour la gestion des erreurs, le contrôle et l’adaptabilité. J’ai ensuite expliqué à ma Product Owner les colonnes qui, selon moi, sont indispensables pour que l’utilisateur·trice ne se perde pas.

Guidage Gestion des erreurs Contrôle Adaptabilité
Fonction d’upload
  • Message d’aide lors du premier upload
  • Info sur les formats acceptés
  • Loader animé pendant le chargement
Messages d’erreur spécifiques explicitant si le format est inadapté ou s’il s’agit d’un problème serveur (« Oups, nous ne sommes pas capable de charger votre fichier, veuillez réessayer dans quelques instants ») Possibilité d’annuler si le chargement est trop long Possibilité de faire un upload en cliquant sur un bouton ou par drag & drop sur la page web

Exemple d’une ligne d’un tableau de fonctionnalités. J’estime ici que seule la colonne Adaptabilité peut être traitée dans une version ultérieure de la fonctionnalité, les 3 autres étant indispensables pour une bonne expérience utilisateur.

2. Intégrer ces éléments dans les Users Stories, idéalement dans la définition de Done.

Un item du Backlog produit ne devrait pas être considéré comme terminé tant que les développements permettant de répondre aux besoins « must have » n’ont pas été réalisés. C’est la partie difficile. Lorsque l’on réalise que l’on n’aura pas le temps de tout terminer dans le Sprint, on a souvent tendance à réduire en priorité le cadre des grosses User Stories ayant beaucoup d’éléments UX, en enlevant ces derniers. Avec la logique du dilemme initial : est-ce qu’il n’est pas plus important de livrer telle autre fonctionnalité plutôt que de gérer les erreurs dans ce cas bien particulier ? C’est là qu’il faut être fort·e. Soit dire non en insistant sur le fait que la User Story ne sera pas réellement terminée sans ses éléments UX, soit accepter le compromis d’une V1 pas optimale, créer une nouvelle User Story avec l’élément UX manquant et insister pour qu’elle soit traitée dans le Sprint suivant.

3. Faire des tests utilisateurs régulièrement sur de petits échantillons.

En agilité, les cycles sont courts : deux ou trois semaines en général. On n’a clairement pas le temps de réunir vingt-cinq usager·e·s dans la cible pour tester notre produit. Il faut donc se contenter de quelques tests utilisateurs : trois à cinq sujets permettent souvent de relever de gros problèmes d’UX qu’il est préférable de traiter avant de faire de nouveaux tests3. Si besoin, filmez les tests pour pouvoir montrer la réalité : le sujet ne comprend pas, il veut abandonner. Ce genre de démonstration apporte un argument très fort à un·e PO ou à un·e client·e un peu frileux·se à apporter autant d’importance à l’UX qu’au fonctionnel.

Et concrètement, dans l’équipe…

Pour appliquer correctement le deuxième point, il est indispensable de spécifier précisément les différents « détails » UX avant le début du développement. Pendant l’année et demie suivant mon intégration à l’équipe, nous avons essayé plusieurs stratégies de travail.

1. UX design en amont :

Sur certains projets, j’ai fait des maquettes très détaillées très en amont.

Avantage : ça laisse le temps de réfléchir tranquillement et de mûrir un projet.

Inconvénient : il manque souvent du liant avec les développeurs, et le jour où la fonctionnalité est implémentée, le contexte a souvent eu le temps de changer, ce qui m’oblige à revoir beaucoup de choses.

2. UX design en aval :

Je ne le recommande pas, mais cela arrive parfois avec les équipes dans lesquelles je ne suis pas bien intégrée. Généralement, c’est le pendant du point précédent : j’ai fait une maquette il y a 6 mois (ou pas), les développeurs s’en inspirent un peu (ou pas), et viennent me voir en fin de Sprint (ou pas) pour me demander mon avis. Dans tous les cas, je donne des directives pour améliorer l’UX qui n’est jamais parfaite du premier coup. S’ils ont le temps, les développeurs en tiennent compte directement dans le Sprint. Dans le cas contraire, des User Stories sont créées dans le Backlog du projet (et sont souvent reléguées en bas de pile).

Avantage : gain de temps pour l’UX designer. ^^

Inconvénient : perte de temps pour les développeurs qui doivent faire des modifications dans leur code, et risque de ne jamais corriger les problèmes ergonomiques car le fonctionnel semblera souvent plus prioritaire.

3. UX intégré dans l’équipe :

C’est le fonctionnement que l’on a souvent utilisé. Je spécifiais grossièrement en début de Sprint, et les développeurs me posaient des questions lorsqu’un point n’était pas traité dans mes spécifications. Il arrivait souvent que l’on se rende compte que certaines choses manquaient ou ne fonctionnaient pas pendant le développement.

Avantage : beaucoup d’interactions avec l’équipe, une vraie émulation lorsque les idées se rencontrent.

Inconvénient : pas le temps de terminer si les specs arrivent trop tard par manque de consensus entre l’UX designer et le ou la PO. Parfois, les développeurs peuvent être frustrés de perdre du temps lorsque les specs changent pendant le développement. Enfin, l’évaluation de la durée d’une User Story en Sprint Planning est très difficile si le contour de celle-ci n’est pas claire, ce qui détériore la transparence, un élément clé de Scrum.

4. UX intégré dans l’équipe travaillant en avance de phase :

C’est ce qu’on essaie de mettre en place en ce moment : travailler un Sprint en amont sur le design des écrans et des interactions pour les fonctionnalités qui seront développées lors du prochain Sprint. Cela ne m’empêche pas d’interagir avec les développeurs pendant le Sprint, pour échanger sur leurs éventuelles propositions ou trouver des solutions à des problèmes que je n’avais pas identifiés.

Avantage : un peu plus de temps pour réfléchir et mûrir chaque fonctionnalité donc moins de risque de modification pendant le Sprint, des specs claires et précises avant le début du Sprint donc plus de facilité à évaluer la durée de la User Story en Sprint Planning (meilleure transparence).

Inconvénient : le ou la PO doit être capable d’anticiper sur 2 Sprints : pour préparer celui qui vient, il faut qu’il ou elle ait la visibilité sur le Sprint suivant.

Conclusion

L’agilité et l’UX sont très complémentaires, j’en suis convaincue. Cela n’en fait pas pour autant des approches simples à concilier. Après un an et demi d’expérience sur le sujet, je pense que la meilleure stratégie à adopter est d’intégrer le « must have » de l’UX dans le développement des fonctionnalités en spécifiant clairement les différents comportements indispensables dans le descriptif des User Stories. Ainsi, chaque fonctionnalité est directement livrée avec un système de guidage minimum, une gestion des erreurs et un minimum de contrôle pour l’usager·e (possibilité d’annuler). Si c’est trop tard ou trop dur, il faudra s’appuyer sur les tests utilisateurs pour mettre en évidence l’aspect indispensable de ces éléments, et mettre en balance l’ajout de fonctionnalités avec la perte d’utilisateurs/trices. En terme d’organisation pratique, il me semble que l’idéal est d’intégrer les UX designers dans les équipes, en les faisant travailler un Sprint en amont sur les fonctionnalités du Sprint suivant.

Ensuite, pour créer réellement une expérience utilisateur hors du commun, il faudra adresser les autres colonnes du tableau : du guidage niveau 2 (transitions qui claquent), de l’adaptabilité, etc. Mais cela doit cette fois réellement être priorisé au regard des fonctionnalités qui ont été vendues au client. En gardant néanmoins en tête qu’une amélioration de l’expérience pourra parfois coûter beaucoup moins cher que certaines grosses fonctionnalités, et « acheter du temps » en convainquant le client qu’on lui développe un produit qui fait vraiment la différence.

Notes

  1. Pour plus de détails sur l’agilité, vous pouvez lire mon article sur mes premiers pas en tant que Scrum Master.
  2. Pour plus de détails sur les critères de Bastien et Scapin, vous pouvez lire mon article Bases d’ergo : notions à connaître et à appliquer.
  3. À ne pas confondre avec l’idée reçue qu’on entend parfois selon laquelle 5 utilisateurs suffiraient à trouver 85% des problèmes d’ergonomie : c’est globalement faux. Pour en savoir plus, vous pouvez lire l’article de Raphaël Yharrassarry sur ce sujet.

9 commentaires sur “Intégrer l’UX dans une approche Agile : retour d’expérience

  1. Kevin Py, le mardi 8 décembre 2015 à 09:37

    Article intéressant sur le fond, comme sur la forme. Il est vrai qu’il faut encore bien expliquer l’UX, car certains pensent encore qu’il s’agit de design. Mélanger l’UX et l’Agilité coule de source, car cela permet de garder une cohérence des besoins dans l’équipe, et sur les tâches de chacun. Beaucoup de comprennent pas l’intérêt crucial de l’UX, et je pense que sans méthodologie de travail (Agile, SCRUM, Kanban), cette discipline ne peut s’exercer correctement.
    Merci d’avoir rappelé l’intérêt de lier les 2 ensembles, cela éclairera peut être certaines personnes.

  2. Rachel, le mardi 8 décembre 2015 à 14:07

    Merci pour cet article bien intéressant.
    Je n’ai ni UX designer (ni Scrum manager, ni PO) dans ma mini agence de 4 personnes. Néanmoins ton article m’apporte des pistes afin de mieux intégrer les enjeux de l’UX dans notre contexte de production et pas seulement en amont du développement.

  3. Corentin, le jeudi 10 décembre 2015 à 10:55

    « Au milieu de tous ces développeurs le nez plongé dans leur code » : ça serait cool d’arrêter de véhiculer cette image des devs …

  4. Margaux Perrin, le jeudi 10 décembre 2015 à 15:45

    @Corentin : tu as raison, c’est une idée reçue sur cette profession, mais c’est à tort celle que j’avais en arrivant dans ce milieu dont j’ignorais tout : un très faible intérêt pour mon approche (et c’est uniquement cela que j’entendais dans cette phrase). Mais en réalité, alors que certains développeurs ne comprenaient pas du tout la valeur ajoutée de ma présence parmi eux et ne voyaient que la charge de travail supplémentaire qu’engendraient mes recommandations, d’autres m’ont tout de suite renvoyé des feedbacks très positifs sur mon travail et ont montré leur satisfaction d’avoir une personne référente sur les questions d’UX.

    @Kevin Py, @Rachel : Merci ! :)

  5. Céline, le vendredi 11 décembre 2015 à 11:01

    « Lorsque l’on réalise que l’on n’aura pas le temps de tout terminer dans le Sprint, on a souvent tendance à réduire en priorité le cadre des grosses User Stories ayant beaucoup d’éléments UX, en enlevant ces derniers. »
    En tant que PO, il me semble qu’à partir du moment où une US est embarquée dans le sprint, personne ne peut la réduire, lui supprimer des « parties » (je travaille en Scrum…).
    Pour moi, l’UX fait partie de mon US à part entière, c’est à l’équipe d’estimer l’US et de dire au PO si celle ci sera trop grosse, avant le lancement du sprint, charge au PO de la redécouper la plus finement possible. Bien entendu les tests d’acceptation de l’US doivent embarquer par partie UX.

  6. Margaux Perrin, le lundi 14 décembre 2015 à 14:22

    Dans ce que j’ai compris de Scrum (je ne connais et pratique que depuis un an et demi), l’adaptation de la portée de l’US est la seule marge de manœuvre qu’on ait quand on se rend compte en cours de sprint que « ça va pas le faire ». Hors de question de transiger sur la qualité, et la date de fin de sprint ne doit surtout pas changer. Par contre, on peut aller voir le ou la PO et décider avec lui ou elle de réduire la portée d’une US. Sachant les contraintes de qualité et de délai, le ou la PO doit choisir entre « faire moins » sur une US ou « ne pas faire du tout » une autre. C’est une question souvent délicate.
    Exemples : « Est-ce que dans une V1 on pourrait faire la recherche sur les titres uniquement, et on cherchera dans le contenu en v2 ? » > Si la fonctionnalité a du sens dans cette V1, pourquoi pas.
    « Est-ce qu’en V1 on peut zapper la transition d’ouverture ? » > C’est du guidage, j’ai envie de répondre non, mais est-ce qu’il n’est pas plus urgent d’avoir une autre fonctionnalité que d’avoir cet élément de guidage sur cette fonctionnalité ? Dur à dire. C’est un boulot de PO.

  7. Yann Fressignaud, le mardi 15 décembre 2015 à 12:09

    Article très complet, merci pour le retour d’expérience !

  8. Goub, le mercredi 13 janvier 2016 à 11:31

    Sur la forme, écrire en masculin·féminin (fort·e…) rend très pénible la lecture. J’ai arrêté de lire l’article à cause de ça. Bad UX ;).

  9. Aurore, le mercredi 20 juillet 2016 à 10:05

    Lire un texte (intéressant) écrit en inclusif, un bonheur, merci.
    J’espère que vous n’arrêterez pas cette forme d’écriture à cause de quelques mascu qui essaient d’instrumentaliser l’UX pour invisibiliser les genres qui ne sont pas le leur.

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter l'auteur de l'article, les autres participants à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.