PO, UX/UI design, dev : 10 tips pour bien travailler ensemble dans un projet agile

Ce n’est pas toujours facile d’intégrer le design (UX/UI) dans les projets agiles. Nos lectures récentes nous ont donné envie de questionner nos pratiques pour essayer de les améliorer. Dans ce but, nous avons animé le mois dernier un atelier avec nos collègues de Sogilis* autour des relations entre développeurs, ergonomes/UX designer, UI designer et Product Owner (PO) dans les projets agiles. L’objectif était d’identifier les freins et les pistes d’amélioration pour travailler plus efficacement et réduire les frustrations, en s’appuyant sur les expériences des un.es et des autres dans des missions clients diverses et variées.

Méthodo

Après une brève présentation des objectifs de la séance et des différences entre les rôles de PO et UX, nous avons proposé à nos collègues de prendre 5 minutes en individuel pour répondre aux questions suivantes sous forme d’idées sur des post-its : dans le cadre de vos missions dans une organisation de type agile, qu’est-ce qui s’est bien passé dans les relations avec le ou la PO et l’équipe UX/UI ? Qu’est-ce qui s’est mal passé ?

Nous avons ensuite divisé l’assemblée en 3 petits groupes avec la consigne d’échanger sur les problèmes que chacun avait pu rencontrer dans des missions clients, et de creuser des pistes de solutions pour améliorer les choses. Nous étions trois ergonomes pour animer l’atelier, nous avons donc chacune rejoint un groupe pour écouter les échanges et apporter notre vision.

Après 40 minutes d’échange en petits groupes, nous avons proposé une phase de restitution.

Résultats

Voici les 10 principales bonnes pratiques qui sont ressorties de cet atelier :

1. Découper les user stories en petites user stories : elles seront ainsi plus faciles à décrire et à réaliser dans un sprint.
2. Remettre la valeur métier en avant en début de sprint : c’est plus motivant de savoir pourquoi on développe telle ou telle fonctionnalité, et la compréhension de la valeur réduit le risque de mal comprendre la spec.
3. Faire une revue des maquettes avec les développeurs : pour qu’ils comprennent bien les besoins, qu’ils apportent un point de vue externe, et qu’ils valident la faisabilité technique.
4. Intégrer l’UX lors des séances de story mapping : pour rappeler les usages et motiver les choix de développer telle ou telle fonctionnalité de manière prioritaire par rapport à telle autre au regard des besoins utilisateurs.
5. Valider les maquettes et les specs à travers des tests utilisateurs afin de réduire le risque de modifications post-développement, qui ont un coût bien plus élevé que de modifier des maquettes.
6. Avoir une “Definition of Ready” : une liste de critères permettant de décider si une user story peut ou non entrer dans un sprint de développement (exemples : les critères d’acceptation sont rédigés, une maquette explicite le design attendu, l’estimation a été réalisée et elle est inférieure à 2 jours…).
7. Définir précisément les rôles et périmètres de chaque membre (PO, UX, UI) dans le projet : pour ne pas se marcher dessus, et savoir qui prend quelle type de décision.
8. Mettre en place des créneaux réguliers entre l’équipe de dev, le PO et l’équipe ux-ui : les intégrer lors du daily meeting par exemple et/ou faire des séances de backlog grooming .
9. Sensibiliser nos clients à l’agilité : tous n’ont pas une culture très forte de la philosophie agile et des process Scrum que nous aimons utiliser.
10. Impliquer le scrum-master : c’est son rôle de s’assurer que les problèmes sont adressés, s’il y a des difficultés à travailler ensemble cette personne doit être une ressource pour faciliter la recherche de solutions.

Analyse

À notre niveau, ces éléments impliquent un travail de l’équipe UX/UI en avance de phase sur le dev. C’est une évidence pour nous : pour éviter les frustrations qu’une spec “pas claire” peut provoquer et les nombreuses modifications en dev qui sont très coûteuses, il faut que les comportements et le design d’une fonctionnalité soient fixés avant le début de son développement.

Pour cela, il est nécessaire que l’équipe UX/UI ait un à deux sprints d’avance sur le dev, afin de se laisser le temps de questionner les besoins, réaliser des maquettes basse et haute fidélité, tester les maquettes auprès des utilisateurs, valider la faisabilité technique auprès des développeurs, éventuellement revoir sa copie et refaire des maquettes, décrire tous les détails des comportements (ce que nous appelons communément “les specs” : comment le site, l’appli ou le logiciel doit se comporter lorsqu’une erreur se produit, si l’utilisateur veut annuler, si le texte est trop long, si aucun élément n’est présent ? Ya-t-il des cas particuliers à traiter ? Quelles sont les valeurs par défaut ? Etc.) et enfin les valider auprès de notre client.

L’autre élément fondamental est la communication entre les différents membres de l’équipe. En particulier, l’UX et le PO ont tout intérêt à diffuser leur compréhension des besoins utilisateurs auprès de l’UI designer et des devs. Cela conforte nos réflexions précédentes, dont nous parlions ici. C’est la raison pour laquelle nous testons actuellement la co-écriture des specs avec les développeurs, et l’explicitation systématique des parcours utilisateurs en insistant sur la valeur métier lors de la présentation des maquettes.

Proposition d’un process

À partir de cela, nous avons décidé de profiter du démarrage d’un nouveau projet client pour proposer un process que nous allons tester les prochaines semaines.

Lors de l’émergence d’un nouveau besoin fonctionnel, celui-ci sera priorisé par rapport aux autres dans le backlog par le Product Owner (ou la proxy Product Owner : une personne chez nous qui gère le backlog à la place du client). S’il arrive en haut du backlog, ce besoin entrera en phase de conception :

• création de maquettes,
• validation des maquettes : faisabilité technique avec les devs, adéquation aux besoins via des tests utilisateurs et validation client,
• co-écriture des spécifications avec les développeurs lors d’une session de backlog grooming,
• validation des specs auprès de notre client.

Une fois ces étapes effectuées, la user story pourra être considérée comme “prête” pour le dev.

Viendra alors la phase de développement, lors de laquelle l’équipe UX/UI validera les comportements et le design en parallèle de l’étape de revue de code.

Ce process n’a rien de révolutionnaire par rapport à nos pratiques habituelles, la nouveauté réside surtout dans la co-écriture des specs avec les développeurs que nous allons tester, et le fait de valider en parallèle le développement d’un point de vue technique (code review) fonctionnel (revue par l’ergonome et la proxy-PO) et design (revue par l’UI designer). RDV dans quelques mois pour un retour d’expérience sur ce process !

*Vous l’ignoriez ? uxShadow est une marque créée par l’équipe UX-UI de Sogilis. Sogilis est une société de service du numérique dont la vision est de faire évoluer l’industrie du logiciel vers le “zéro défaut” sans concession sur l’efficience. Pour atteindre cet objectif, intégrer des compétences en ergonomie, ux et ui est fondamental. Tous les deux mois, Sogilis organise un Sogiday : une journée de partage et d’échanges entre tous les membres de la société. C’est dans ce cadre que nous avons animé cet atelier avec une dizaine de collègues développeurs.