Créer un design system : par où commencer quand on part de zéro
Un design system ne commence pas par une bibliothèque de 80 composants. Il commence par un inventaire honnête de ce qui existe, quelques décisions, et un premier composant qui sert vraiment. Voici l’ordre qui marche, de la startup au grand groupe.
Avez-vous besoin d’un design system ?
Pas forcément tout de suite. Un design system coûte du temps à créer et à entretenir. Il devient rentable quand la même interface est construite par plusieurs personnes, sur plusieurs produits ou pendant longtemps.
- Plusieurs designers ou plusieurs équipes de développement travaillent sur le même produit.
- Vous avez plusieurs produits, ou un site et une application, qui doivent se ressembler.
- Chaque nouvelle page prend du temps à cause de décisions déjà prises ailleurs.
- Une refonte de marque arrive, et vous savez déjà qu’elle prendra des mois à se propager.
Commencer par l’audit
Avant de dessiner quoi que ce soit, faites l’inventaire de l’existant : captures des boutons, des champs, des cartes, des couleurs et des rayons réellement utilisés. L’exercice est souvent spectaculaire. Sur ce site, l’audit a trouvé treize rayons d’arrondi différents et vingt couleurs écrites à la main.
L’audit sert à deux choses : décider ce qu’on garde, et convaincre. Une planche avec quinze boutons différents fait plus pour le budget d’un design system qu’une présentation.
Les fondations avant les composants
Les fondations, ce sont les design tokens : couleurs, typographie, espacements, rayons, ombres, durées d’animation. Ce sont elles qui rendent les composants cohérents entre eux. Organisez-les en trois niveaux (référence, système, composant) dès le départ : c’est ce qui permettra d’ajouter un thème sombre ou une deuxième marque sans tout refaire.
Les premiers composants
Commencez par les composants qui reviennent sur chaque écran, et finissez-en un de bout en bout (Figma, code, documentation) avant d’attaquer le suivant.
- Le bouton : variantes, tailles, états. C’est le composant le plus utilisé et celui qui révèle le plus d’écarts.
- Le champ de formulaire : libellé, aide, erreur, désactivé.
- La carte, le badge, le lien : les briques de la plupart des pages.
- La mise en page : grille, conteneurs, rythme vertical des sections.
Un nommage clair dès le départ évite les renommages douloureux. La convention BEM (bloc, élément, modificateur) marche bien côté code : .ds-button, .ds-button__icon, .ds-button--primary.
Documenter au fil de l’eau
La documentation n’est pas une phase finale. Chaque composant publié arrive avec trois choses : à quoi il sert, quand ne pas l’utiliser, et un exemple vivant. Une page par composant suffit au début. Un journal des versions dit à tout le monde ce qui a changé.
Une gouvernance minimale
- Qui décide : une personne ou une petite équipe tranche, même si tout le monde peut proposer.
- Comment contribuer : un process écrit, court, pour proposer un composant ou une modification.
- Comment publier : des versions numérotées, un journal, et une règle pour les changements qui cassent.
Mesurer, même un peu
Trois chiffres suffisent pour piloter : la part des écrans qui utilisent le système, le nombre de composants recréés à la main, et la satisfaction des designers et des développeurs. Mesurés chaque trimestre, ils disent où mettre l’effort.
Les erreurs qui coûtent cher
- Construire en vase clos pendant six mois, puis « lancer » un système que personne n’a demandé.
- Copier le design system d’une grande entreprise au lieu de partir de ses propres besoins.
- Faire le système dans Figma sans le brancher au code, ou l’inverse.
- Ne prévoir personne pour l’entretenir après le lancement.
Je crée et fais adopter des design systems, de l’audit à la gouvernance. Si vous voulez savoir par où commencer chez vous, un appel de cadrage suffit.