"Votre mission si vous l'acceptez est de construire notre Design System, sachant que nous n'en n'avons pas et que tous nos designs sont sur XD."
Mission impossible ? Non, challenge relevé !
C'était (presque) le brief que j'ai reçu en arrivant chez Metroscope, cette start-up incubée par EDF et désireuse d'avoir sa propre identité. Pour faire bref, cette entreprise développe un logiciel SaaS à destination des industriels tels que les centrales nucléaires, les centrales thermiques (au charbon par exemple) pour que ces derniers puissent surveiller les éventuelles fuites dans certains de leurs circuits de production d'énergie.
Et donc faire des économies de CO2 (et donc d'€). Le projet est donc un projet qui a du sens puisqu'il vise à réduire les émissions de CO2 et donc préserver notre environnement ou du moins éviter de trop l'abîmer. Nota bene : nous ne jugerons pas ici les impacts du nucléaire sur les circuits d'eau ou encore la gestion des déchets nucléaires 😇.
Revenons à nos moutons ou plutôt nos atomes (double jeu de mots puisque nous parlons nucléaire mais aussi atomic design).
Me voilà donc lancée dans la construction du DS de Metroscope. Comme les URL sont soumises à mot de passe, je n'ai pas pu utiliser le plugin HTML to Design qui aurait pu me permettre d'avoir directement les pages (et donc les composants de cette page) directement dans Figma. J'ai appris a posteriori que j'aurai pu demander à mettre une branche du site en libre accès pour pouvoir lier cette page à Figma mais c'était déjà trop tard et il y aurait peut-être eu des questions de sécurité (même avec un environnement de test).
La deuxième "contrainte" de la mission était d'intégrer l'univers de la brand et les couleurs de l'identité visuelle. La charte graphique ayant été faite par l'agence Bruno, beaucoup d'info étaient présentes dedans. Notamment les couleurs 🎨.
Super ! Quoi de mieux que de se baser sur de l'existant pour créer les couleurs d'un DS ?
Il existait 4 couleurs dans cette identité visuelle. Trop peur pour un DS. J'ai donc utilisé le pluggin Figma Color scale generator. Très simple d'utilisation, vous sélectionnez une couleur et vous demandez au pluggin de sortir une échelle de couleur de tant de nuances. J'ai choisi de partir sur 10 nuances différentes ( de la plus foncée à la plus claire). Nous regarderons plus tard si toutes les couleurs seraient nécessaire à notre usage.
Ensuite, j'ai décidé de nommer ces couleurs. En effet, les codes hexadécimaux ne sont pas idéaux dans ces cas-là.
Quelle nomenclature utiliser ? Après un petit benchmark, j'ai décidé en accord avec le PM et les développeurs d'utiliser la classification de codes couleurs CPK. En effet, les différentes versions de notre logiciel suivaient la classification du tableau périodique des éléments (vous vous souvenez de vos cours de chimie du collège ou du lycée ?). C'était donc un petit clin d'œil à cette classification puisque la classification CPK a donné leurs couleurs aux atomes en plastiques utilisés en cours de chimie (par exemple, sur l'image ci-dessous, vous pouvez voir 1 molécule d'oxygène qui est rouge et 2 molécules blanches d'hydrogène. Nous aurons donc, dans notre DS, les nuances de rouge qui se déclineront sous le nom d'"oxygen" et le blanc qui sera nommé "hydrogen").
À ce stade, je décide de décliner l'échelle chromatique assez simplement avec des nuances allant de 900 à 100 de la plus foncée à la plus claire.
Mais pendant cette mission, les parties prenantes vont un peu bouger et un développeur front va prendre le sujet côté tech. Nous décidons d'un commun accord d'utiliser un système de tokens et de couleurs signifiantes pour faciliter le travail côté dev.
Par exemple, nous avons les couleurs signifiantes pour les actions de validation, ou une couleur signifiante pour les erreurs. Au niveau du développement, cela implique que si les couleurs changent pour les erreurs par exemple, il y a une variable qui peut changer la couleur des erreurs partout où elle sont utilisées au lieu de le faire au cas par cas.
Voilà pour ce qui est des couleurs qui a été un morceau assez conséquent de ce DS et qui ont signé un changement important pour Metroscope, c'est-à-dire une meilleure collaboration entre designer(s) et développeurs mais aussi une rationalisation du reposetory.
Il faudra par la suite créer une échelle typographique, les icônes (nous avons décidé de partir sur la bibliothèque Remix Icon qui est assez complète et correspond à nos besoins), les illustrations.
Viendront ensuite la construction des atomes avec des éléments comme des badges, des checkbox, des boutons...
Un grand besoin d'harmonisation pour ces composants-là puisque notre plateforme contient certaines incohérences niveau UI.
Suivront les molécules, les organismes, organismes puis des templates de pages puisque notre plateforme est construite de telle sorte que les pages ont (presque) toutes les mêmes structures.
Cette mission de DS m'a permis de découvrir un super plugin qui venait juste de sortir au moment où on en avait le plus besoin !
Cet incroyable plugin, c'est EightShapes Specs qui permet sortir en 2 secondes chrono les specs techniques de votre élément.
Grâce à cela, les devs ne sont pas obligés d'aller voir dans le mode inspect (ou le nouveau mode "dev" de Figma) pour récupérer les infos pertinentes pour le développement de l'élément. Et ça permet au designer de ne pas passer trop de temps à expliciter les specs (temps perdu, risque de se tromper, non uniformisation des specs...).
Donc merci aux équipes de Eight Shapes pour ce plugin parce qu'il a été un réel game changer pour nous !
Zeroheight, Notion (oui, oui), j'avais soulevé plusieurs idées. J'avais commencé la doc sur Notion pour des questions de coûts mais aussi pour son côté pratique et son utilisation déjà bien avancée chez Metroscope.
Avec l'arrivée du responsable du DS côté dev, nous avons finalement opté pour Storybook. Très pratique puisqu'une console permet de "jouer" avec le composant et de voir "en vrai" comment il réagit, quelle taille iil peut avoir etc.
Et voilà, le DS de Metroscope a fini par être "live" et par pouvoir être utilisé ! Alors bien sûr, pour qu'un DS soit réellement utile dans une entreprise pour laquelle il y a dû y avoir un peu d'évangélisation en interne, il faut qu'il soit vu comme un produit à part entière, qu'un exercice de vérification entre le DS et la prod régulièrement mais il ne faut surtout pas hésiter à challenger ce DS, à le faire évoluer. Parce que ce qui est pertinent à un instant T, ne l'est pas forcément à T+2 ou +3. Il faut savoir refaire des composants sur lesquels on a passé du temps, ou se rendre compte qu'on n'est pas allé dans la direction optimale pour certains aspects.
Un DS est donc un mélange de souplesse et de rigidité.
Souplesse par cette gymnastique constante qu'il faut faire pour modifier les composants, les améliorer sans cesse.
Rigidité par la rigueur qu'il faut avoir pour s'en occuper, se fixer des points réguliers dans son agenda pour suivre l'avancée des choses, vérifier si tous les composants sont pertinents, voir si la documentation est compréhensible par toutes et tous, etc.
Mais une fois que cela est mis en place, c'est un gros soulagement pour les équipes (design, dev et PM). Vous réduisez grandement les pain point pour vos équipes et donc, in fine, pour vos utilisateurs.
J'espère que cet article vous aura donné envie de mettre en place votre propre DS ou à challenger les usages internes !
.png)
