Un design system est un ensemble de décisions de design réutilisables : tokens (couleurs, typographie, espacement), composants avec leurs variantes et leurs états, règles d'usage et documentation, partagés entre les designers et les développeurs. Il sert à livrer plus vite, plus cohérent et plus accessible.
Ce que je construis
Je dimensionne le système à l'équipe qui va le faire vivre. Un système trop ambitieux pour une équipe de quatre personnes finit abandonné. Un système trop léger pour une équipe de quarante se fragmente.
Fondations
- Tokens : couleurs sémantiques (fond, surface, texte, accent, état), échelle typographique fluide, échelle d'espacement, rayons, ombres, durées d'animation.
- Thèmes : clair et sombre, marque blanche quand le produit est revendu à des clients qui veulent leur identité.
- Grille et mise en page : conteneurs, colonnes, points de rupture, règles de densité.
Composants
Une douzaine de composants couvrent 80 % des écrans d'un SaaS : bouton, champ, sélecteur, case, interrupteur, tableau, carte, navigation, onglets, modale, notification, badge. Chacun est livré avec ses variantes, ses états (repos, survol, focus, actif, désactivé, erreur, chargement) et ses règles d'accessibilité.
Documentation et gouvernance
- Une page par composant : quand l'utiliser, quand ne pas l'utiliser, exemples, anti-exemples.
- Un processus de contribution : qui propose, qui valide, comment une exception devient un composant.
- Un journal des versions lisible par toute l'équipe.
Figma et code, même langage
Le point de rupture de la plupart des systèmes est l'écart entre le fichier Figma et le code. Je le réduis à la source :
| Dans Figma | Dans le code | Pourquoi |
|---|---|---|
Variables de couleur color/surface/raised |
Propriété CSS --color-surface-raised |
Même nom, aucune traduction mentale |
Composant Button avec propriété tone |
Composant <Button tone="primary"> |
Les variantes correspondent aux props |
Styles de texte text/body/md |
Classe ou token text-body-md |
L'échelle typographique est unique |
| Mode clair / sombre | Attribut data-theme |
Le thème est une donnée, pas une duplication |
Quand l'équipe le souhaite, je rédige les fichiers Code Connect ou la couche de tokens (JSON, CSS) pour que le lien soit outillé plutôt que documenté.
Cas réels
- Climeet : design system Figma complet pour une application de mesure carbone, avec tokens, composants, variantes et une bibliothèque réutilisée sur le site vitrine. Le système a permis de reconstruire le calculateur en version simplifiée sans redessiner les fondations.
- Reformer Society : système sombre avec marque blanche par studio, accent couleur surchargé par le client, mêmes composants sur trois espaces (public, studio, super-admin).
- WeeFizz : design system du SaaS PRO et du widget e-commerce, avec un système i18n en onze espaces de noms et des composants partagés entre quatre intégrations CMS.
Les erreurs que j'évite
- Commencer par les composants au lieu des tokens : tout est à refaire au premier changement de marque.
- Copier le système d'un grand acteur : il résout ses problèmes, pas les vôtres.
- Documenter avant d'utiliser : la documentation s'écrit à partir des écrans réels.
- Vouloir couvrir tous les cas : un système couvre les cas fréquents et autorise les exceptions tracées.
Le détail de la méthode de démarrage est dans l'article Design system : par où commencer.
Formats d'intervention
- Audit de l'existant (une à deux semaines) : inventaire des composants réels, écarts Figma/code, plan de consolidation.
- Fondations (trois à six semaines) : tokens, composants de base, documentation initiale, passation.
- Accompagnement (quelques jours par mois) : revue des contributions, arbitrages, évolution du système.
