Comment travaillez-vous avec les designers et comment empêchez-vous un design system de dériver par rapport au code ?

Faites de la couche de tokens la source de vérité unique : couleurs, espacements, typographie et rayons vivent comme des tokens nommés que l'outil de design et le CSS consomment tous les deux, donc un changement se fait une seule fois. Construisez les composants sur des tokens plutôt que sur des valeurs brutes, traitez les nouvelles valeurs ponctuelles comme de la dette de design en revue, et publiez la bibliothèque de composants avec des props documentées pour que les équipes produit composent au lieu de forker.

Ce qui garde vraiment la synchronisation, c'est d'avoir une seule source pour les primitives. Les couleurs, les espacements, l'échelle typographique et les rayons vivent comme des tokens, exportés en propriétés personnalisées CSS pour le code et consommés comme variables dans l'outil de design, donc quand une couleur de marque change elle change à un seul endroit et tout la reprend. Les composants ne référencent alors que des tokens, jamais des valeurs hexadécimales brutes, et nos règles de lint signalent une couleur en dur dans une pull request. Quand une maquette introduit une valeur qui n'existe pas, c'est une conversation plutôt qu'un ajout silencieux : en général c'était involontaire, et de temps en temps c'est un vrai manque et on l'ajoute délibérément. Pour les composants, je tiens une bibliothèque documentée avec les props et les états visibles, pour que les équipes produit voient ce qui existe avant de le reconstruire, et il y a un chemin clair pour contribuer en retour quand il faut une variante. Le mode d'échec que j'ai vécu, c'est un système que personne ne trouvait, donc quatre équipes ont chacune livré leur propre bouton, et à ce stade la consolidation représentait un trimestre de travail.