Design system : une librairie de composants, ou un produit à part entière
Vous voulez un design system livré avec vos écrans, et vous vous demandez ce que ça change ?
Notre métier, c'est le design : des composants avec leurs différents états et leur comportement responsive (via l'auto layout de Figma), des variables et une logique de nommage, le tout dans un fichier de travail propre. Deux livrables sont possibles, la librairie de composants ou le design system, et le choix peut se décider tard, une fois les maquettes avancées. C'est la suite de notre travail d'UI design.
Quand on nous sollicite
La demande arrive le plus souvent au bout d'un projet d'interface.
- Vous commandez de l'UX et de l'UI, et vous voulez un design system dans les livrables. C'est de loin la demande la plus fréquente.
- Vos développeurs vont devoir décliner des écrans qui n'ont pas été maquettés, et il leur faut de quoi le faire sans composer eux-mêmes ce qui manque.
- Votre identité change et vous ne voulez pas refaire tout le site. Pour Tytl, la nouvelle direction artistique a été l'occasion de reposer un design system et de variabiliser les composants existants.
- Plusieurs plateformes doivent partager les mêmes composants pour rester cohérentes entre elles.
Un design system n'est pas un design kit
Une librairie de composants sert à une chose : donner à vos développeurs un handoff unique (le fichier de passage de relais entre le design et le développement), pour intégrer les maquettes prévues et décliner celles qui ne l'ont pas été. Un design system, c'est un produit dans le produit, avec son cycle de vie, sa maintenance, sa gouvernance et donc ses arbitrages. Ça demande des moyens et des bras, de notre côté comme du vôtre, et chez vous une équipe dédiée, garante de la cohérence entre vos produits. Comme on l'écrit sur notre page UI : tout le monde veut un design system mais peu ont les moyens de le produire et de le faire vivre.
Comment on procède
On part des écrans qu'on conçoit
Les composants, les design patterns, les gabarits et la logique de variabilisation, on les produit dès le départ, sur le périmètre des maquettes pour lesquelles vous nous avez sollicités.
Chaque composant et ses différents états
Un composant se construit avec ses différents états possibles (hover, disabled, focus…) et son comportement responsive. C'est ce travail qui permet ensuite de décliner sans repartir de zéro.
On anticipe un peu la suite
Les maquettes ne couvrent pas toujours toutes les pages. Pour celles qu'on identifie avec vous, on décline les composants au-delà des écrans déjà conçus, pour que rien de critique ne manque au moment d'intégrer. On ne cherche pas l'exhaustivité.
On parle à vos développeurs
Certifiés Qualité Web Opquast et formés au langage et aux contraintes du développement front, on sait ce dont les intégrateurs ont besoin pour passer de la maquette au code sans deviner.
Le choix n'a pas à se faire tout de suite
Les composants et les gabarits sont là depuis le début. Étendre le travail à une logique de tokenisation alignée sur votre framework front (l'outil sur lequel vos développeurs construisent l'interface) est un chantier plus lourd, qui peut se décider presque à la dernière minute.
Les freins à l'adoption, on les nomme
Un design system vit s'il est adopté, et ce qui freine l'adoption est connu : le manque de temps face aux priorités courtes, les habitudes ancrées, des outils et des processus non harmonisés, des responsabilités floues, des équipes peu informées. Ce sont les freins que pointe la formation au design system que nous avons suivie, et ceux qu'on peut ouvrir avec vous au moment du cadrage.
Ce que vous obtenez
Une librairie de composants
Tous les composants prévus, dans leurs différents états, avec les design patterns et les gabarits. Une logique de nommage simple, faite pour un handoff unique à vos développeurs.
Ou un design system
Le même travail, plus l'effort supplémentaire qui en fait un produit interne : toutes les variables, la tokenisation dans le nommage, un fichier de travail extrêmement propre, à destination de vos designers comme de vos développeurs.
Un fichier prêt pour le passage de relais
Figma propose dans son espace de handoff une conversion en code, que des plugins traduisent dans différents frameworks front. C'est du code généré automatiquement. Nous, on fait le design, pas le développement, et on ne livre pas le code.
Ce qui fait varier l'effort
L'effort supplémentaire que demande le design system dépend du nombre de composants et d'états, des tokens, de la documentation et du temps d'échange avec vos développeurs. C'est un effort distinct du reste du projet.
Une nouvelle identité sans refaire tout le site
Addland devient Tytl, et la nouvelle direction artistique aide les développeurs à s'approprier les règles graphiques de la refonte. C'est l'occasion de reposer un design system propre, de repenser la construction des composants et de les variabiliser. Remettre à plat le design system permet de retravailler de petits éléments qui ont un impact global, tout en conservant la structure des anciens composants pour éviter de refaire le site en entier.
Lire l'étude de casUn site et un outil, une plateforme de mandats, des composants mutualisés
Neosigna : le cycle de vie de milliers de contrats devenu collaboratif
Lire l'étude de cas
Quand l'audit d'impact social devient une plateforme outillée
Lire l'étude de casQuestions fréquentes
Pour que vos écrans restent cohérents quand le produit grandit et que le passage de relais entre le design et le développement se fasse sans deviner. Quand le besoin s'arrête là, une librairie de composants y répond déjà : le design system ajoute la logique de produit interne, avec sa maintenance et ses arbitrages.
On part des écrans conçus et de vos composants existants. On construit chaque composant et chacun de ses états, on pose les variables et la convention de nommage, on étend un peu le périmètre pour les pages identifiées avec vous, et on prépare le fichier pour le handoff à vos développeurs.
Les définitions détaillées sont dans notre glossaire. En pratique, ce qui vous concerne : une librairie de composants sert à intégrer et à décliner vos maquettes, un design system est un produit interne, avec son cycle de vie et sa gouvernance, et il demande des moyens.
Quand ce que vous livrez a vocation à être repris, étendu et maintenu par plusieurs personnes, et que vous avez les moyens de le faire vivre : du temps, des personnes, des arbitrages. Sans ces moyens, la librairie de composants y répond le plus souvent.
Oui. Les composants, les gabarits et la variabilisation du périmètre commandé sont produits dès le départ. La tokenisation alignée sur votre framework est un chantier distinct, qui peut se décider presque à la dernière minute.
Un design system n'est jamais fini : c'est un produit vivant. Le faire vivre, c'est collecter les retours des designers, des développeurs et des équipes produit, prioriser les évolutions dans une feuille de route, et garder des responsabilités claires. Ce sont les principes de la formation au design system que nous avons suivie, et on peut vous aider à en poser les grandes lignes au moment du cadrage. L'animation au quotidien, elle, reste chez vous.