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).¹

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 Scapin². 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 tests³. 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.