Atelier - Prioriser les composants de votre design system
→ If you want to read this article in English, follow this link
Cette année, j’ai eu la chance de travailler sur de nombreux design systems et j’ai encore appris énormément de choses sur les erreurs à ne pas commettre et les bonnes pratiques pour bien commencer…
Et aujourd’hui, nous allons parler priorisation !
Imaginons que vous avez récemment commencé votre démarche design system. Vous avez identifié les composants les plus transverses à vos différents produits digitaux et vous les avez sans doute déjà reproduits dans une magnifique librairie Sketch. Mais vous le savez maintenant : un design system ne prend réellement tout son sens que lorsqu’il contient également des composants codés… Alors lesquels faut-il développer en premier ? Qu’est-ce qui créera une valeur ajoutée directe pour votre design system ?
Afin de répondre à cette question, nous avons imaginé un atelier simple à mettre en place et qui fonctionne très bien : l’atelier de priorisation des composants.
Objectif
Classer les composants par priorité (les plus fréquents et faciles à développer en premier) afin de définir un backlog et d’organiser ensuite les sprints de développement.
Durée : 1h30
Personnes à inviter : designers, developers et product owners, de l’équipe garante du design system mais également des équipes projets pilotes.
Matériel nécessaire :
- Un tableau blanc
- Des marqueurs
- Une version imprimée des composants de votre système
- Des versions imprimées ou dessinées de la “matrice” de priorisation
- Des post-it
- Stylos, feuilles blanches
Préparation
Avant l’atelier, imprimez tous les composants de votre système, avec leurs noms au-dessus. Affichez-les au mur en vous assurant qu’ils seront accessibles par tous les participants et à tout instant.
Étapes
- Créez des groupes multi-profils et multi-projets. Distribuez à chacun un exemplaire vierge de la matrice et donnez-leur les consignes (10 min).
- Chaque groupe discute et se met d’accord pour placer les composants sur la matrice : les plus fréquemment utilisés et faciles à développer en bas à gauche, les plus rares et complexes à développer en haut à droite (45 min).
- Affichez ensuite toutes les matrices les unes à côté des autres et re-dessinez une matrice sur le tableau blanc. Le facilitateur reprend alors chaque composants et les place sur une matrice « finale » en essayant de comprendre les éventuelles différences entre les groupes.
Par exemple : « pourquoi le groupe A considère ce composant comme simple à développer alors que le groupe B le trouve complexe ? » (45 min).
À la fin de l’exercice, les composants qui se retrouvent dans la zone P1 (priorité 1) seront alors développés en premier. Suivront les P2 puis les P3. Les composants dont l’utilisation est très rare ou spécifique à un seul produit ne seront sans doute jamais développés pour le système.
Si vous avez beaucoup de composants en P1, il est possible de refaire un tour de vote en fin d’exercice pour ne garder qu’une dizaine de composants prioritaires.
Astuces
- Définissez avec vos développeurs en début d’exercice ce que “simple” et “complexe” signifient. Par exemple, “simple” peut représenter moins de 3 jours de développement et complexe plus de 6 jours.
- Sélectionnez des composants de base de votre système (boutons, éléments de formulaires…), mais pensez également aux composants plus “métiers” qui sont propres à votre entreprise (Par exemple, une vignette de programme pour une application de programme télé).
- Préparez d’avance les post-its avec les noms des composants. Cela évitera à chaque groupe de devoir les réécrire et vous fera gagner un temps précieux.
- Garder quelques post-it vierges et encouragez xles participants à noter les éventuels composants manquants.
Cet exercice peut être mené régulièrement, afin de vérifier que la priorisation des sprints est toujours pertinente (notamment après l’arrivée de nouveaux projets pilotes).
Retrouvez cet atelier et pleins d’autres encore dans le livre que j’ai écrit avec l’agence Idean sur le sujet :
