La plupart des design systems échouent pour la même raison : ils sont construits comme un exercice à part, admirés pendant une semaine, puis discrètement abandonnés dès qu’arrive la première échéance. Le fichier se voit greffer une page "Composants" que personne n’ouvre pendant que les vrais écrans du produit sont remplis d’instances détachées et de codes hexadécimaux mis une seule fois.
Voici la version que j’utilise sur de vrais projets clients : assez petite pour être construite en quelques jours, assez stricte pour tenir encore trois mois plus tard, et structurée de sorte qu’un développeur puisse la faire correspondre à Tailwind ou à une bibliothèque de composants sans deviner.
Commencez par un audit, pas par un fichier vierge
Avant de définir quoi que ce soit, prenez les écrans qui existent déjà et extrayez chaque couleur, chaque style de texte et chaque valeur d’espacement utilisée. Sur un produit qui a été conçu par plus d’une personne, le résultat, c’est généralement onze gris, sept tailles de police qui diffèrent d’un ou deux pixels et trois hauteurs de bouton. Cet inventaire est le brief du système. Vous n’inventez pas une échelle à partir de rien ; vous décidez lesquelles des valeurs existantes survivent.
Fusionnez sans pitié. Deux gris qui diffèrent de deux pour cent de luminosité ne font qu’un seul gris. Une taille de corps de 15px et une de 16px ne font qu’une seule taille de corps. Chaque valeur que vous conservez est une décision que quelqu’un devra reprendre sur chaque écran à venir, donc plus l’ensemble est réduit, plus le système est rapide à utiliser, et la rapidité d’utilisation est la seule chose qui détermine si les gens s’en servent vraiment.
Notez les valeurs qui survivent sous forme de liste à plat avant de toucher aux variables de Figma. Si vous ne pouvez pas justifier une valeur à voix haute en une phrase, elle n’entre pas.
Trois niveaux de tokens, pas plus
Les variables de Figma donnent envie de construire un graphe de tokens élaboré. Résistez. Trois niveaux couvrent presque tous les produits : les primitives, les sémantiques et le petit nombre d’overrides au niveau du composant que vous ne pouvez vraiment pas exprimer de façon sémantique.
Les primitives sont des valeurs brutes aux noms dénués de sens : de grey/100 à grey/900, blue/500, space/4. Les sémantiques décrivent l’intention et pointent vers les primitives : surface/default, surface/raised, text/primary, text/muted, border/subtle, action/primary. Les composants ne reçoivent leur propre token que lorsqu’une valeur est vraiment locale, comme la hauteur précise de la cellule de votre date-picker.
La raison d’être du niveau intermédiaire, ce sont les thèmes. Quand un client demande le dark mode, vous ajoutez un second mode sur la collection sémantique et vous le remappez vers d’autres primitives. Rien dans la bibliothèque de composants ne change, parce qu’aucun composant ne référence jamais grey/800 directement ; il référence surface/raised. Si vos composants pointent vers des primitives, le dark mode devient une reconstruction plutôt qu’un remappage.
Nommez les tokens dans l’ordre catégorie/rôle/variante, tout en minuscules, avec des barres obliques pour le regroupement. Cela se lit bien dans la barre latérale de Figma et se convertit proprement en objets imbriqués qu’attend un thème Tailwind ou un fichier de propriétés personnalisées CSS.
Des échelles de typographie et d’espacement que vous pouvez défendre
Une échelle typographique de six à huit paliers suffit pour la plupart des interfaces : display, niveaux de titre un à trois, body, small et caption. Chaque palier devrait être visiblement différent de celui d’à côté. Si vous devez plisser les yeux pour distinguer deux tailles, l’une des deux est de la décoration, pas de la hiérarchie.
Définissez la hauteur de ligne comme partie intégrante du style, pas comme un override par instance. Le texte long veut environ 1.5 à 1.6 ; les titres veulent 1.05 à 1.2. Intégrez aussi le tracking dans les grandes tailles : la typographie display a presque toujours besoin d’un espacement des lettres négatif dont le texte courant n’a pas besoin.
Pour l’espacement, choisissez une base de 4px et utilisez une échelle limitée : 4, 8, 12, 16, 24, 32, 48, 64. Cela correspond au un pour un avec l’espacement par défaut de Tailwind, ce qui veut dire qu’un développeur n’a jamais à écrire une valeur arbitraire comme p-[13px]. Si une mise en page ne fonctionne qu’à 13px, le problème, c’est généralement la mise en page.
Une règle qui évite plus de débats que n’importe quelle autre : l’espacement communique le regroupement. Les éléments qui vont ensemble ont moins d’espace entre eux que l’écart qui les sépare du groupe suivant. La plupart des interfaces "en désordre" ne sont pas mal stylées, elles sont juste espacées de façon uniforme.
Composants : des propriétés plutôt qu’un mur de variantes
Un bouton avec quarante variantes pour chaque combinaison de taille, de style, d’icône et d’état est un composant dans lequel personne ne trouve rien. Utilisez plutôt les propriétés de composant : une propriété de variante pour le style, une autre pour la taille, des propriétés booléennes pour les slots d’icône et des propriétés d’instance swap pour les icônes elles-mêmes. Quatre propriétés décrivent ces mêmes quarante combinaisons tout en restant lisibles.
Nommez ces propriétés comme le front-end nommera ses props : size, variant, state, disabled, leadingIcon. Quand le panneau de propriétés de Figma et la signature des props de React utilisent les mêmes mots, les conversations de handoff cessent d’être un travail de traduction. Cela ne coûte rien au moment du build et ça paie sur chaque ticket ensuite.
Construisez chaque composant avec auto layout, y compris ceux qui semblent ne pas en avoir besoin, et définissez le comportement de redimensionnement de façon délibérée : fill pour tout ce qui doit s’étirer, hug pour tout ce qui est dimensionné par son contenu. Auto layout est ce que Figma a de plus proche de flexbox, donc un composant bien disposé dans le fichier est un composant qui a déjà répondu aux questions de mise en page du développeur.
Concevez aussi les états qu’on oublie : hover, focus, disabled, loading et la version avec un texte assez long pour passer à la ligne. Un composant qui n’existe que dans son état idéal n’est pas un composant de système, c’en est une illustration.
Une documentation qui vit dans le fichier
Personne ne lit un site de documentation séparé pour une bibliothèque de huit composants. Mettez les consignes là où le travail se fait : remplissez le champ de description de chaque composant et de chaque style, parce qu’il apparaît dans le panneau des assets et dans Dev Mode précisément au moment où quelqu’un décide de ce qu’il va utiliser.
Ajoutez une page de frames appariés montrant ce qu’il faut faire et ne pas faire pour les composants les plus souvent mal utilisés : en général les boutons, les champs de formulaire et les états vides. Une paire de petites captures d’écran tranche une question plus vite qu’un paragraphe.
Gardez une courte page de changelog au début du fichier avec des dates et des entrées d’une ligne. Sur un projet client, c’est aussi votre trace de preuves : quand quelqu’un demande pourquoi une couleur a changé en mars, la réponse prend dix secondes.
Enfin, utilisez le branching pour tout ce qui est structurel. Renommer une collection de variables ou restructurer un composant dans le fichier principal en plein sprint casse les instances en direct dans tous les fichiers produit, et celui qui le découvre est toujours un développeur au pire moment.
Comment savoir si le système fonctionne vraiment
Un système fonctionne si concevoir un nouvel écran donne l’impression d’assembler des blocs existants plutôt que de dessiner de nouvelles formes. Le vrai test arrive deux mois après le lancement : vérifiez combien de composants du fichier sont des instances non détachées, combien de couleurs proviennent de la palette de tokens, et si un nouveau membre de l’équipe peut construire un écran sans demander où trouver le bouton primaire.
Si les réponses sont élevées, le système fait son travail. Sinon, supprimez la moitié des tokens et recommencez.
