Comment et pourquoi construire une Contribution Journey ?

Vous travaillez au sein d’un grand groupe et on vous a mis sur un chantier de Design system ? Vous êtes débordé ? Vous devez gérer les demandes incessantes de votre équipe ? Vous ne savez plus où donner de la tête ? Vous avez du mal à suivre les évolutions du Design system ? Et vos collègues aussi ?

Résultat : trop de réunions, pas assez de transparence, et une migraine en prime…

Alors, écoutez bien : j'ai la solution à tous vos problèmes ! Vous devez créer un outil pour gérer votre Contribution Journey !

Le principe est simple: prioriser les chantiers clés et répartir la charge de travail entre les membres de l’équipe.

Comme vous nous êtes sympathiques, je vais vous fournir 2 templates que vous pourrez télécharger gratuitement afin que vous puissiez à votre tour mettre une contribution saine au sein de votre entreprise !

Ah génial ! Mais euh, ça ressemble à quoi une Contribution journey ? Et puis comment on s’en sert ?

Et bien Jamie, c'est très simple ; au cours de mon expérience en tant qu’UI Designer, j’ai construit un tableau Notion pour solutionner ce problème de Contribution journey. Ce dernier permet aujourd’hui à l’entreprise de recueillir les besoins de tous ses Product Designers et de les classer selon différentes catégories.

Construction du template

Le tableau Notion peut être organisé de la façon suivante :

• Reporter : identifier le Designer qui émet le besoin
• Assignee : identifier à qui la demande est destinée
• Resume : espace de rédaction du besoin par le "reporter"
• Use case : explication du use case par rapport au besoin par le reporter
• Product impacted : renseigner le produit impacté par ce besoin
• Priority : indiquer l'urgence et l'importance du besoin
• Impacted Component : type de composants impacté par le besoin
• Request type : renseigner le type d'action à réaliser (modifier un composant existant, créer un nouveau composant, ou supprimer un variant d'un composant)
• DSY task decision : pour que l'équipe UI décide si le besoin va être traité, mis en standby car on a besoin de plus d'informations, ou refusé
• Comments by Ui team : pour que l'équipe UI explique en commentaire les raisons de ses choix si elle a mis un besoin en stand by ou en not to do
• ChangeLog aligned : pour que le Product Manager vérifie si le Changelog a été traité par le besoin
• Already dev : pour que le Product Manager vérifie si le composant a bien été développé par son équipe de Développeurs
• Status design : renseigner le statut de traitement du besoin par l'équipe UI (pas encore commencé, en cours, en revue, ou terminé)

Choisissez les vues qui vous correspondent

Pour faciliter la collaboration et la navigation dans ce tableau, n'hésitez pas à ajouter des filtres :

• Par statut
• Par produit
• Par composant
• Par assigné
• Par reporter

Mais ce n'est pas tout ! Vous allez également pouvoir utiliser un fichier Figma appelé "Contribution Sandbox" pour travailler de manière collaborative sur les nouveaux composants à intégrer au Design system.

Le fichier Contribution Sandbox sur Figma

Ce fichier comprend plusieurs pages réparties dans diverses sections :

La section “🐣 Onboarding” comprend les pages suivantes :

1. La page Getting Started explique comment fonctionne le fichier
2. La page Release note permet d’indiquer quels composants ont été ajoutés, modifiés ou supprimés depuis la dernière mise à jour du fichier.
3. La page Overview fait un état des lieux de l’ensemble des composants présents dans le fichier

• La section “📢 REQUEST” permet aux Product Designers de construire leur composant idéal.
• La section "✍️ IN PROGRESS" permet à l'équipe UI de retravailler le composant en s'inspirant de ce qui a été fait sur la page "Request"
• La section “🔍 IN REVIEW“ est là où le Lead Designer vérifie la version finale du composant produite par l'équipe UI et décide s'il peut être validé ou s'il nécessite d'autres modifications
• La section “🎉 DONE” est là où le composant est validé et prêt à être intégré au Design system
• La section “🗑️ OLD” est là où les anciens composants sont archivés une fois qu'ils ont été intégrés ou refusés.

Les plus fins observateurs d’entre vous auront remarqué que les section request, in progress, done et old avaient à chaque fois 3 sous-pages. C’est parce qu'elles doivent comporter autant de sous-pages que vous avez de produits reliés à votre Design system. Dans cet exemple, je me suis limité à 3 produits mais n’hésitez pas à modifier le fichier selon vos besoins.

Conclusion : Les migraines, c’est terminé !

En utilisant ce template de contribution journey sur Notion et notre fichier Figma "Contribution Sandbox", vous allez pouvoir améliorer la gestion des demandes de vos Product Designers et vous assurer que tous les nouveaux composants qui sont ajoutés au Design system sont conformes aux standards de votre entreprise. Cela vous permettra de travailler de manière plus efficace et de vous concentrer sur les tâches qui ont le plus d'impact pour votre équipe.

Vous souhaitez mettre en place une Contribution Journey dans votre entreprise ?

Je vous invite à télécharger le template Notion et le template Figma que j'ai créé pour vous.

Vous n'aurez plus qu'à personnaliser les colonnes selon vos besoins et à inviter vos collègues à y participer. J'espère que ces deux templates vous aideront à gagner du temps et vous éviteront quelques migraines !