Nul besoin de s’attarder sur les mille avantages d’avoir un bon Design System. Cohérence, ré-utilisabilité, amélioration de l’expérience utilisateur… Comment ne pas avoir envie de se lancer, et surtout de faire cela bien ?
Lors de sa mini-conférence donnée lors du dernier Paris-Web, la designeuse Cécile Freyd-Foucault nous a livré son petit guide pratique pour commencer son Design System. Elle nous y partage ses astuces pour réussir son Design System (DS), que ce soit de l’identification des composants, jusqu’à l’implémentation du composant «ambassadeur».
J’ai beaucoup apprécié son entrée en matière avec la métaphore de la barrière de corail. Tel un écosystème vivant, un DS est un ensemble dynamique issu d’une coévolution entre des éléments, qui interagissent avec leur environnement. On y retrouve tout un tas de textures, de lumières, de typo, qui cohabitent et qui donnent une direction.
Voici donc un petit résumé de mes Key Learnings de cette intervention.
Convaincre les parties prenantes de l’intérêt du projet
Il s’agit d’un projet d’équipe. Il est indispensable d’embarquer toute son équipe et de ne pas faire cavalier seul. L’implication de chacun est primordiale. La charge de travail est importante et il faut que l’équipe comprenne l’intérêt du projet. Soyez pédagogue, appuyez votre argumentaire en présentant des exemples de Design System existants. Pourquoi également ne pas assister à des évènements autour du Design System. On ne fait pas un Design System pour en faire un. On doit se demander surtout pourquoi le faire et l’équipe doit partager ce sentiment. Pourquoi ne pas organiser un atelier pour définir ensemble l’objectif, les axes et les valeurs du projet, et faire un petit focus sur l’accessibilité. En amont de cet atelier vous devrez identifier et comprendre qui sont les utilisateurs (et parties prenantes) de votre Design System. On parle ici de votre équipe (les utilisateurs directs), du marketing et la communication, mais aussi les utilisateurs finaux et d’autres potentiels Stakeholders. Pensez notamment à bien inclure l’équipe des développeurs lors de cette phase de conception.
Faire un état des lieux
Vous pouvez commencer par identifier les composants, en réalisant par exemple un atelier en équipe afin d’obtenir une vision globale du produit. Vous pourrez capturer les différents écrans et parcours. Si vous n’avez pas tout pas de panique, l’idée n’est pas d’avoir une vision exhaustive. Répertoriez les différents éléments à l’aide d’un **tableau d’identification (**classification, famille d’élément, nom, états, récurrences fonctionnelles, nombre de styles, DS parent, problèmes relevés etc.).
Prioriser
Plusieurs outils pourront vous permettre de hiérarchiser vos sujets. La matrice Métier vs Fréquence, peut vous permettre d’identifier les éléments à faible/forte valeur, versus les éléments dont la fréquence est importante/rare. En effet certains composants sont uniques mais très importants (comme le header par exemple) et méritent qu’on s’y attarde. Identifiez également les éléments qui peuvent être critiques, en évaluant leur utilisabilité, accessibilité et complexité. Si le composant le plus redondant et important n’a pas de « gros » soucis, peut-être qu’il est moins prioritaire. Une autre matrice à prendre en compte met en lumière la complexité de développement de l’élément vs son implémentation.
Mettre en place la doc
On doit y retrouver les composants, les styles, les parcours, la marque, l’iconographie, le contenu, les guidelines de la documentation, les infos sur l’accessibilité et enfin une aide technique pour l’installation. Cette doc sera donc aussi fonctionnelle que technique.
La documentation d’un élément doit être à la fois simple, pragmatique, évolutive et utile. Prenez le recul nécessaire sur votre doc en la partageant avec le reste de l’équipe pour récolter un max de feedbacks.
Enfin posez-vous la question du choix du lieu de centralisation de votre Design System. L’important est que la solution réponde aux besoins de votre projet, que vous choisissiez un espace dédié (avec Zeroheight, Specify ou Storybook), un espace « Maison », ou un espace détourné un Wiki, Confluence ou Notion. Gardez juste toujours en tête d’avoir une vision long terme, pour ne pas réinventer la roue…
Vous pouvez hiérarchiser votre contenu en utilisant la méthode du Tri de carte avec vos utilisateurs pour construire l’arborescence la plus en adéquation avec la manière de voir de vos utilisateurs.
Pensez également à mettre en place des règles de nommage avec l’équipe de développement. Vous pouvez partir du composant ambassadeur pour définir vos règles.
Si votre DS ne répond pas aux besoin de vos utilisateurs, il ne sera pas utilisé et ce serait bien dommage. Pensez donc à inclure l’équipe en réalisant par exemple des ateliers « composant » pour définir ensemble son fonctionnement (structure html, semantique HTML, Dos et Don’ts etc.).
Créer de l’engagement
Trouvez un petit nom à votre Design System, il doit exister par lui-même en tant que produit. C’est très important pour son appropriation et la communication qui va en découler. Vous pourrez ainsi évangéliser sa bonne parole et le présenter au « reste du monde ». On parle ici des équipes internes, des autres filiales ou d’autres intervenants externes, qui seront à même de l’utiliser, et même de contribuer à son évolution. Ce sera donc très important de communiquer régulièrement sur les actualités de votre DS, que ce soit via Slack, Teams ou une adresse email dédiée. En effet votre DS va évoluer, et grandir au fil du temps. Il peut être également intéressant d’utiliser la méthode de gestion sémantique de version, pour marquer les grandes évolutions et changements du DS, et bien dialoguer avec les développeurs.
Et vous, quelle est votre expérience en termes de Design System ?
Avez-vous déjà participé à un projet de Design System ? Si oui quels seraient vos conseils pour assurer le succès d’un Design System ? Ou peut-être que vous êtes designer, mais que tout comme moi, vous n’avez pas encore participé à la conception d’un Design System ? En ce qui me concerne j’ai essentiellement travaillé pour des grands comptes qui avaient un Design System déjà existant.
Mais sans avoir à être en charge d’un tel projet, pourquoi ne pas utiliser cette méthodologie en partie pour se créer une librairie de composants qui pourra être utilisée sur votre projet ou dans votre Feature Team ? En effet sur de grands projets on peut être amené à travailler en équipe sur de nombreux parcours, et cela peut-être très utile de se constituer une librairie avec les éléments les plus utilisés, pour garder une cohérence entre les parcours et gagner du temps.
En tout cas grâce au guide créé par Cécile Freyd-Foucault, je comprends mieux les enjeux de ce fameux écosystème. A mon sens voici les principales notions clés à retenir : approche user-centric, co-création, travail d’équipe, engagement, et bien sûr évangélisation.
