Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

A l'heure où l'expérience utilisateur se retrouve au cour des enjeux dans la plupart des projets web, Scrum est l'une des méthodes de travail qui permet de réinventer le rôle du designer. Voici mon retour d'expérience.

1 - Le designer ne fait pas que du beau

La phase de démarrage de projet (qu’on appelle “cadrage”) s’étale entre 1 à 4 semaines. Le designer joue un rôle clé dans cette phase qui précède les sprints de réalisation. Avec le reste de l’équipe, il anime les ateliers et entretiens utilisateurs, challenge la vision produit du client et conçoit la meilleure réponse fonctionnelle possible pour répondre aux différents enjeux (business, utilisateurs et techniques). Les parcours utilisateurs conçus en atelier deviennent la pierre angulaire du projet, et se matérialisent par des user stories, qui viennent ensuite constituer le backlog produit. Ainsi, le designer n'exécute pas simplement un cahier des charges en formalisant des wireframes. Il participe activement à la construction de la vision produit, dans une démarche de co-construction avec le PO et les développeurs.

Contrairement aux schémas classiques de réalisation type cycle en V où toute la conception est formalisée avant les développements, le designer agile s’inscrit dans la logique itérative du cadre Scrum.

Il doit donc pendant la phase de cadrage définir les grands contours de l’expérience utilisateur du projet sur lequel il travaille, mais s’affranchir des détails et du besoin d’exhaustivité auxquels certains peuvent encore être attachés.

Pour lancer le premier sprint, le designer travaille avec l’équipe sur le backlog, un prototype en wireframes animé sur Invision qui incarne les parcours clé, et une première maquette graphique qui définit les fondamentaux UI du produit (entre autres livrables). Une fois que le début du product backlog est prêt pour démarrer les sprints, la phase de réalisation est lancée.

2 - L’importance des sprints goals pour le designer

La roadmap de réalisation des produits s’illustre le plus souvent à travers des sprint goals, soit les grands objectifs de chaque sprint répartis dans le temps et par ordre d’importance.

Cette roadmap donne de la visibilité à un instant t sur les prochains chantiers sur lesquels le designer doit se pencher. Car le designer travaille toujours en avance de phase des développements. Il travaille au sprint _n _les user stories qui seront développées au sprint n+1 (ou n+2).

Comment cela s’organise-t-il concrètement?

Ce schéma est un exemple de roadmap par sprints d’une plateforme de suivi de projets. Il s’agit d’une projection à un instant t qui peut évoluer au fil des sprints. Les sprints goals sont les grandes épics qui doivent être développées. On constate que l’epic “J’extrais les données projets” arrive en fin de course, bien qu’elle constitue un enjeu business majeur. Mais pour extraire des données il faut d’abord que celles-ci soient disponibles dans l’outil.

Ensuite, les users stories correspondant à ces epics sont ordonnées selon cette priorisation. Le backlog étant mouvant, ces éléments peuvent évoluer dans le temps, mais l’idée est encore une fois d’avoir une projection sur le ou les prochains sprints. Les user stories qui correspondent au prochain sprint goal passent par la case design, afin d’être prêtes pour le développement.

Le designer a lui aussi des tâches sur notre board Scrum et Jira qui lui sont assignées pour pouvoir suivre son avancée.

Sur ce board, nous avons à gauche le backlog produit complet. Au centre les stories sont à l’étape de conception, à droite elles sont en cours de développement. Une user story est ainsi planifiée au sprint planning pour le développement si elle est “prête”, d’un point de vue design notamment.

3 - Le dialogue, clé de la réussite

En plus des cérémoniaux Scrum, le designer échange presque quotidiennement avec le PO, au sujet des avancées du projet. Il a souvent une bonne connaissance des contraintes techniques éventuelles qui auront un impact sur la complexité d’une user story.

Les sessions de backlog grooming sont un moment clé pour le designer. Planifiée à mi-sprint, c’est une session de travail au cours de laquelle le PO travaille sur son backlog avec (une partie de) l’équipe de développement, designer compris. Cette session de travail s’appuie souvent sur les maquettes ou wireframes réalisés par le designer, qui incarnent la réponse fonctionnelle aux besoins utilisateurs décrits dans les user stories.

Ainsi, le designer avance sur le design du produit, parallèlement à son développement, en intégrant les éventuels retour des sessions de grooming.

Le designer maquette le produit progressivement et ne maquette que les écrans qui auront de la valeur à court terme. Il ne maquette pas pléthore d’écrans secondaires qui ne seront potentiellement pas développés (si à faible valeur). De cette façon, l’équipe est toujours en train de travailler sur ce qui a le plus de valeur pour le produit : le client et ses cibles.

4 - Un référentiel UI pour garder le cap

Afin de s’assurer que les interfaces construites progressivement restent homogènes et forment un tout cohérent, le designer construit systématiquement en parallèle un UI kit (ou styleguide).

Ce référentiel UI se constitue progressivement, au fur et à mesure des sprints et des nouveaux composants. Ce référentiel UI a plusieurs utilités :

• Pour les utilisateurs finaux, il permet d’assurer de façon indirecte une expérience cohérente et fluide durant tout son parcours de navigation;
• Pour le designer, il permet de s’assurer que tous les écrans suivent bien un même modèle cohérent de composants, sans glissement de l’UI dans le temps;
• Pour les développeurs, il permet d'accélérer les développements Front en fournissant un fichier unique de référence facilement consultable;
• Lorsque des changements d’équipe peuvent survenir, le style guide permet d’avoir un guide de référence sur les règles graphiques à respecter et donc de gagner du temps sur la prise en main du projet;

Contrairement aux chartes web PDF à l’ancienne, compliquées à consulter et non exploitables, ce référentiel sert tous les corps de métiers. Ce document est construit au fil des sprints par le designer. Nous utilisons Zeplin pour le partager avec les développeurs.

À la façon de l’Atomic Design, le designer ne conçoit non plus des pages, mais un système de composants cohérents; où un objet donné est représenté de la même façon sur tous les écrans du site où il est appelé à figurer.

Quelques rapides aperçus de ce à quoi ressemblent nos UI kit projets. Synchronisés sur Zeplin, les développeurs Front construisent à partir de cet inventaire l’équivalent sous forme de composants développés.

5 - “A clean UI to a designer is like clean code to a developer”

L’un des grands avantages à travailler en même temps que les développeurs sur le même projet est que le designer peut suivre les développements pendant qu’ils ont lieu sans devoir switcher d’un projet à l’autre.

Sur mes premiers projets web, je travaillais en chambre, et recevais les retours du chef de projet ou du directeur de création sur mon travail. Les développeurs étaient des prestataires qui réceptionnaient mes fichiers de travail. J’avais ensuite très peu de marge de manoeuvre pour suivre les développements, et j’étais de toute façon occupée sur de nouveaux projets.

Avec le Scrum, le designer est (comme les développeurs) concentré sur le projet en cours et peut discuter en direct sur les features en train d’être développées. Il peut tester et répondre aux questions facilement.

L’un des points de frustration pour les designers avec le Scrum consiste dans le fait que les petits ajustements UI sont rarement considérés comme prioritaires. Et que la priorité est donnée aux features clé. Pourtant, de la même façon qu’un code bien construit est important d’un point de vue qualité du produit livré, la qualité de l’UI l’est tout autant.

Le pair programming ne doit pas seulement s’appliquer entre développeurs. Joyce Pang Vargas en parle dans son article Maintaining UI integrity within the agile framework.

Le pair programming designer/developer permet selon elle de gagner en efficacité, et d’intégrer les petits ajustements d’interface qui ne sont sinon jamais priorisés lors d’un projet Scrum.

Ces ajustements se font ainsi en live, sans avoir besoin de maquetter ou de rédiger de longs mails de retours suite à une grosse phase de recette, quand la communication directe suffit. Les échanges sont ainsi facilités pour tout le monde et, en travaillant main dans la main, les développeurs se sensibilisent progressivement aux enjeux UI et front.

Changement de perspective

Il est vrai qu’il peut sembler difficile pour un designer de passer du design d’un produit complet, à cette approche itérative par sprints. Se concentrer sur des briques isolées du produit peut sembler empiéter sur le besoin d’harmonie globale. C’est l’objet de notre phase de cadrage que Damon Dimmick nomme “sprint zero” dans son article de 2012, que de définir les grands fondamentaux UX qui assureront un produit cohérent. Ces grands principes seront ensuite précisés et déclinés pendant la réalisation. Et c’est aussi la fonction de l’UI kit que de définir les grandes règles UI qui permettront de produire un site cohérent.