Un design system se démarre par les fondations, pas par les composants : tokens de couleur, typographie, espacement, rayons et durées, puis une douzaine de composants qui couvrent la majorité des écrans, nommés de la même façon dans Figma et dans le code. La documentation et la gouvernance viennent ensuite, à partir des écrans réels.
Avant de commencer : trois questions
- Qui va le faire vivre ? Un système sans responsable identifié meurt en six mois. Nommez quelqu'un, même à 20 % de son temps.
- Pour quelle équipe ? Un système pour quatre personnes n'a rien à voir avec un système pour quarante. Dimensionnez.
- Quel produit existe déjà ? Un système ne se construit pas en chambre. Il part de l'inventaire des écrans réels.
Étape 1 : l'inventaire
Avant de dessiner le moindre token, faites l'inventaire de l'existant. Capturez tous les boutons, tous les champs, toutes les couleurs, toutes les tailles de texte utilisées dans le produit. Vous trouverez probablement quatre boutons primaires, onze gris et sept tailles de corps de texte.
Cet inventaire a deux usages : il montre l'ampleur du problème aux décideurs, et il fournit la liste des composants réellement nécessaires.
Étape 2 : les tokens
Les tokens sont les décisions de design les plus petites et les plus stables. Je les pose dans cet ordre.
| Famille | Contenu | Conseil |
|---|---|---|
| Couleur primitive | La palette brute : gris, accent, états | Peu de teintes, une échelle régulière |
| Couleur sémantique | Fond, surface, texte, accent, succès, erreur, avertissement | C'est elle que les composants utilisent, jamais les primitives |
| Typographie | Familles, échelle fluide, graisses, interlignages | Une échelle de six à huit tailles suffit |
| Espacement | Échelle de 4 ou 8 pixels | Toutes les marges et tous les paddings en découlent |
| Rayons, ombres, bordures | Trois rayons, trois ombres, deux bordures | Au-delà, personne ne sait lequel choisir |
| Mouvement | Trois durées, deux courbes | Le mouvement est une décision de système |
Les tokens sémantiques sont ce qui permet un mode sombre, une marque blanche ou un changement de charte sans toucher aux composants.
Étape 3 : les douze premiers composants
Construisez-les dans l'ordre d'usage, chacun avec ses variantes et ses états (repos, survol, focus, actif, désactivé, erreur, chargement) :
- Bouton
- Champ de saisie
- Sélecteur
- Case et interrupteur
- Tableau
- Carte
- Navigation
- Onglets
- Modale
- Notification
- Badge
- Avatar
Résistez à la tentation d'en faire plus. Un composant entre dans le système quand un besoin se présente une deuxième fois.
Étape 4 : Figma et code, mêmes noms
L'écart entre le fichier Figma et le code tue la plupart des systèmes. Décidez une convention de nommage unique, et appliquez-la des deux côtés :
- Variable Figma
color/surface/raisedégale propriété CSS--color-surface-raised. - Composant Figma
Buttonavec propriététoneégale composant<Button tone="…">. - Style de texte
text/body/mdégale tokentext-body-md.
Si l'équipe utilise Code Connect ou une couche de tokens exportée en JSON, outillez le lien. Sinon, documentez-le et vérifiez-le à chaque revue. Le sujet est développé dans la page front-end et intégration.
Étape 5 : la documentation minimale
Une page par composant, quatre rubriques :
- Quand l'utiliser.
- Quand ne pas l'utiliser, et quoi utiliser à la place.
- Un exemple tiré du produit.
- Un anti-exemple tiré du produit.
C'est tout. La documentation s'écrit à partir des écrans réels, après usage. Écrire la documentation avant d'avoir utilisé le composant produit des pages que personne ne lit.
Étape 6 : la gouvernance
Trois règles suffisent au départ :
- Un canal unique pour les demandes de composants et les signalements d'incohérence.
- Un responsable qui arbitre et publie les versions.
- Une règle d'exception : une dérogation est autorisée si elle est tracée ; si elle revient deux fois, elle devient un composant.
Les cinq erreurs les plus coûteuses
- Commencer par les composants : tout est à refaire au premier changement de marque.
- Copier un grand système (Material, Carbon) : il résout d'autres problèmes que les vôtres.
- Vouloir couvrir tous les cas : le système couvre les cas fréquents et tolère les exceptions.
- Documenter avant d'utiliser : la documentation sert à ceux qui ont déjà le besoin.
- Ne pas nommer de responsable : voir la question numéro un.
Un exemple vécu
Sur Climeet, le système Figma a été posé en trois semaines à partir des wireframes : tokens, typographie, une quinzaine de composants. Quand le client a demandé une version simplifiée du calculateur, les fondations n'ont pas bougé. Seuls les écrans ont changé. Le même système a ensuite servi au site vitrine. C'est exactement ce qu'un design system doit permettre.
Pour un accompagnement, voir la page design system.
