Vous êtes graphiste, ou UI Designer comme on dit ces jours-ci, dans une équipe produit Scrum et vous avez du mal à savoir comment vous intégrer dans le processus de développement du produit ?
Ce n’est pas une question simple si on veut suivre les principes de l’agilité. Je vous propose une vision que je partage assez.
Note pour la lecture : je vais utiliser dans cet article le terme de “graphiste”, afin d’éviter la confusion avec le “designer”, qui regroupe trop de choses aujourd’hui. Tout le monde veut être designer (UX Designer, Solution Designer…).
Seconde note : j’ai été pendant de nombreuses années indépendant, réalisant graphisme et développement de sites (entre autre). J’ai donc une certaine expérience du travail de création visuelle.
Le réflexe du graphiste : le waterfall
Le premier réflexe que vous avez peut-être eu en tant que graphiste, c’est un dérivé du waterfall. C’est à dire que vous travaillez avec une phase d’avance :
=> au sprint N, vous concevez les visuels nécessaires au travail à faire dans le sprint N+1 ou N+2 (voire plus).
C’est. Du. Waterfall.
Ce n’est pas grave que ce soit du waterfall, mais n’appelez pas ça “agilité”.
Un travail de réflexion
Les raisons évoquées pour avoir ce sprint de décalage sont généralement de l’ordre du “un design, ça se réfléchit, on ne fait pas ça comme ça”.
Si c’est ce que vous pensez en tant que graphiste, je vous invite à demander à un développeur s’il ou elle code sans réfléchir, sans penser à ce qu’il fait, sans architecture en tête, si le code lui vient comme par magie quand il commence à taper au clavier.
Vous voyez, je suppose, où je veux en venir => Ce n’est pas le cas !
Donc cet argument de la réflexion ne convient pas. Chaque développeur travaille, dans son sprint, en réfléchissant aux étapes, à ce qu’il doit faire. Alors pourquoi un(e) graphiste n’en serait pas capable ?
Le graphisme influence le code
Un autre argument est que les développeurs (dans le sens codeurs) doivent avoir les visuels pour savoir ce qu’il vont devoir développer, ou pour estimer la tâche à faire.
En effet, un design compliqué va mettre plus de temps à être codé. C’est logique.
Mais… pourquoi faire compliqué ? Un des points fort de l’agilité étant l’adaptation et l’empirisme, pourquoi ce type de construction ne pourrait pas convenir au graphisme ?
La solution : l’émergence
Les développeurs connaissent généralement le TDD (Test Driven Development). Dans cette pratique — que vous devriez vouloir connaître un peu en tant que membre de l’équipe — on code de façon incrémental et même empirique.
C’est à dire qu’on part d’un code simple, pas forcément le plus optimisé, mais qui fonctionne. Une fois qu’il fonctionne, on peut l’optimiser, en vérifiant à chaque fois que ça fonctionne toujours.
Pour le design, le graphisme, c’est aussi possible d’utiliser la même approche, c’est même ce que je conseille. On fait quelque chose de simple, sans animation, mais qui fonctionne et ensuite on améliore, on corrige, si possible grâce aux retours d’utilisateurs ou de data (comme l’A/B Testing).
Je fais quoi pendant le sprint ?
Donc vous, graphiste, artiste, que faites vous pendant le sprint ? Sur quoi travaillez-vous ? Et bien comme les développeurs, vous travaillez sur l’objectif du sprint.
Les éléments prit dans le backlog de sprint auront besoin de vos talents de graphiste, vous pouvez les identifier pendant le sprint planning.
Pendant que les développeurs commencent à réfléchir à l’architecture de leur code, vous participez (oui, oui, vous participez à la phase de conception du sprint !) en donnant votre point de vue et votre vision, ou même vos exigences.
Par exemple, si un nouveau composant doit être créé, pendant que les développeurs travaillent sur le back, de votre côté, vous réfléchissez au visuel et à son intégration dans le reste de l’application.
Si vous pensez que vous n’aurez pas le temps de concevoir une maquette en quelques heures, c’est certainement que vous faites de l’over-conception et qu’il faudrait mieux découper la story, ou vos envies.
Rien ne vous empêche de faire d’abord un visuel simple, mais fonctionnel, qui sera amélioré par la suite. Au moins, vous aurez des retours utilisateurs plus rapidement et pourrez vous adapter.
Travail en binôme
Pour plus de performance et une meilleure qualité, les devs se regroupent souvent en binôme ou mob programming. C’est à dire — grossièrement — que l’un ou l’une d’entre eux a un clavier et, tous ensemble, travaillent sur le même code.
Vous pouvez (devez) participer ! Vous pourrez alors donner son avis sur le visuel des éléments et leur intégration dans le reste du produit, en direct. Et oui, on va donc entendre au début des “un peu plus à gauche… non, encore 2 pixels. Encore 1. Revient 3 pixels avant… Oui, très bien.”, mais plus le temps va passer, plus les développeurs apprendront à travailler avec vous.
Vous travaillerez tous bien plus vite en connaissant l’autre. Vous vous rendrez comptes des difficultés de certains développeurs pour juste comprendre l’intérêt du pixel perfect et vous pourrez les aider à grandir à ce niveau là (On peut même s’entraîner avec le site sympas : https://cantunsee.space/).
De votre côté, vous comprendrez aussi mieux les difficultés d’intégration de certains visuel à cause des limitations du CSS et des navigateurs, vous serez un(e) meilleur(e) graphiste en les prenant en compte.
Design system
Et le mieux, c’est quand on arrive à construire un Design System.
C’est une sorte de librairie d’éléments graphiques. Par exemple, si un développeur doit poser un bouton, il ne doit pas avoir besoin d’une maquette pour ça. Il va chercher le bouton dans la bibliothèque et place le composant en toute autonomie.
Certaines équipes s’organisent autour de ce Design System, il y a par exemple une équipe dédiée, qui maintient la librairie à jour et parfois développe même le code (un mix de graphistes et d’intégrateurs). Pour leur projet, les développeurs appellent alors simplement les composants comme des dépendances, qui sont mises à jour par l’équipe UI en toute autonomie.
Pfff, mais pourquoi ? C’est plus simple de travailler avec un sprint de décalage, arrête de nous embêter !
Demandez-vous, en tant qu’équipe Scrum, pourquoi vous travaillez en sprint. Demandez-vous pourquoi vous faites une revue avec des utilisateurs et une démonstration de l’incrément à chaque sprint.
Pour avoir du feedback ; du retour utilisateurs ou clients et pour pouvoir vous adapter !
Que se passe-t-il en faisant le graphisme avec un sprint de décalage ?
Sprint N : Vous préparez la maquette du prochain sprint, le sprint P => revue du sprint N, la priorité change ! Votre design est obsolète ou à faire plus tard, que faites-vous pour répondre au nouveau besoin ?
1/ Vous travaillez dans le sprint avec les dev en urgence, mais vous ne savez pas le faire, c’est chaotique.
2/ Vous décalez la fonctionnalité, le temps de faire une nouvelle maquette en Sprint N+1, le dev sera fait en Sprint N+2.
Autre possibilité, vous faites la maquette en Sprint N, elle est codée en Sprint N+1. En revue du sprint N+1, les retours montrent que ça ne va pas, vous dépenser 2 nouveau sprints pour avoir un retour.
Résultat, vous doublez (au mieux), le retour utilisateur et donc votre capacité à réagir au changement. Un des travers du waterfall.
Et la vélocité ?
Votre design, il agit comment sur la vélocité ? Si votre fonctionnalité est divisée en 2 (1 sprint maquette + 1 sprint dev), alors vous avez 2 estimations, non ?
Il y a des chances que non. Le graphisme n’est généralement pas compté dans l’estimation, puisque celle-ci est faite en fonction de la maquette. Moi, j’appelle ça de la Shadow-Velocité (https://const.fr/blog/agile/guide-shadow-velocity-pour-scrum-masters/)
Une partie du travail pour réaliser un élément de backlog est tout simplement passée sous silence.
Je pense qu’au contraire, l’estimation et le découpage d’une tâche doivent prendre en compte le design.
Par exemple, on pourrait découper fonctionnellement une tâche, par les éléments graphiques. Les choses très avancées (animation, réponses en temps réel, etc.) pouvant être apportées plus tard.
C’est parti !
Sauf cas exceptionnel, c’est à vous, graphiste, de faire le premier pas dans ce sens. Essayez, si vous n’êtes pas convaincu.
Je ne vous dis pas que ça sera parfait tout de suite, mais déjà, vous serez beaucoup plus dans la collaboration avec le reste de l’équipe. Au fil des itérations, ça sera de plus en plus agréable et dans quelques semaines, vous vous demanderez comment vous faisiez avant.
Du coup, vous commencez quand ?
Vous pouvez retrouver un épisode de Scrum Life sur le sujet, et qui en plus explique bien le Design System (https://www.youtube.com/watch?v=VqdHm8imxIM).
Vous pouvez aussi lire mon avis sur les dangers du sprint 0 : https://const.fr/blog/agile/sprint-zero-cest-du-waterfall/ et de préparer trop en avance.
Voici aussi la page Wikipedia sur le TDD (https://fr.wikipedia.org/wiki/Test_driven_development) et celle sur la programmation en binôme (https://fr.wikipedia.org/wiki/Programmation_en_bin%C3%B4me).
Photo by Studio Republic on Unsplash