Un design system n'est pas une bibliothèque Figma. Ce n'est pas un kit de composants. Ce n'est pas un guide de style. C'est un organisme vivant qui codifie les décisions de design, permet la cohérence à grande échelle et accélère l'ensemble de l'équipe produit. Et la plupart d'entre eux échouent dans les six mois parce qu'ils sont construits avec les mauvaises priorités.
La première erreur est de construire un design system en isolation. Lorsque le design et l'ingénierie travaillent indépendamment sur ce qu'ils pensent que le système devrait être, vous vous retrouvez avec deux sources de vérité qui divergent inévitablement. Notre approche commence par un langage partagé : des design tokens définis une seule fois et consommés à la fois par Figma et par le code.
Les design tokens sont les atomes de votre système : couleurs, espacements, typographie, ombres, rayons de bordure. Nous les définissons dans un format indépendant de la plateforme et générons les styles Figma, la configuration Tailwind et les propriétés personnalisées CSS à partir d'une source unique. Lorsqu'une couleur change, elle se propage partout automatiquement.
L'architecture des composants est aussi importante dans Figma que dans React. Nous construisons les composants avec les mêmes principes : la composition plutôt que la configuration, des valeurs par défaut sensées avec des surcharges explicites, et des conventions de nommage claires. Un composant Button dans Figma doit correspondre exactement au composant React Button, avec les mêmes variantes et propriétés.
La documentation est ce qui distingue un design system d'un simple dépôt de composants. Chaque composant de nos systèmes est accompagné de directives d'utilisation, de notes d'accessibilité et d'exemples à faire et à ne pas faire. Cette documentation cohabite avec le code, et non dans un wiki séparé que personne ne maintient.
Les systèmes qui survivent sont ceux auxquels il est facile de contribuer. Nous établissons une gouvernance claire : comment proposer un nouveau composant, comment modifier un composant existant, et comment déprécier quelque chose qui n'est plus nécessaire. La contribution doit être fluide, pas bureaucratique.
Enfin, mesurez l'adoption. Un design system que personne n'utilise n'est qu'un projet annexe. Nous suivons l'utilisation des composants à travers les produits, mesurons la cohérence entre le design et le code, et auditons régulièrement les dérives. Les métriques vous indiquent où le système fonctionne et où il nécessite de l'attention.