LES TOKENS QUI SURVIVENT
Construisez un système de tokens de design qui dépasse le prochain rafraîchissement visuel. Structure à trois niveaux, nommage sémantique, modèles du monde réel.
Pourquoi la plupart des systèmes de tokens ne survivent pas aux refontes
La plupart des systèmes de tokens de design sont abandonnés dans les deux ans parce qu'ils codifient les valeurs visuelles du moment plutôt que l'intention sémantique derrière elles. Un token nommé blue-500 est verrouillé à une valeur bleue à jamais ; un token nommé accent-primary dépasse tout changement de couleur parce que le designer suivant le mappe à la couleur bleue équivalente du nouveau système.
L'unique règle qui sépare les systèmes de tokens qui survivent de ceux qui meurent : nommez les tokens par leur utilité, pas par leur apparence. accent-primary, surface-base, text-secondary, danger-bg. Jamais blue-500, gray-900, red-light. Le nom sémantique est le contrat ; la valeur est le détail d'implémentation.
L'architecture à trois niveaux
Couche 1 : les primitives. Valeurs brutes de couleur, espacement, typographie. blue-50, blue-100, blue-200..., blue-900. space-1, space-2..., space-12. Celles-ci existent en tant qu'échelle sous-jacente et changent rarement.
Couche 2 : sémantique. Des tokens nommés selon leur fonction qui mappent aux primitives. accent-primary mappe à blue-500, accent-hover mappe à blue-600, surface-base mappe à gray-50, text-primary mappe à gray-900. Les composants y font référence, jamais aux primitives directement.
Couche 3 : à l'échelle du composant. Des tokens par composant qui mappent aux tokens sémantiques. button-primary-bg mappe à accent-primary, card-border mappe à border-subtle, nav-active-bg mappe à accent-emphasis. Les composants les consomment.
Quand le refresh de la marque se produit, vous modifiez l'échelle primitive et éventuellement le mapping sémantique-à-primitive. Les tokens à l'échelle du composant s'écoulent sans changement. La refonte se déploie en jours plutôt qu'en mois.
Quoi encoder et quoi laisser en dur
Encoder : couleur, espacement, typographie (familles de polices, tailles, poids, hauteurs de ligne), border-radius, ombre, durée et accélération du mouvement, largeurs des points de rupture.
Ne pas encoder : les valeurs spécifiques à la mise en page (max-width de 1280 sur le modèle d'article), les décalages de positionnement ponctuels, l'orchestration d'animation qui est unique à un seul composant. Ceux-ci doivent rester en ligne ; les encoder crée un système qui s'oppose à lui-même.
Le test de référence : un autre composant pourrait-il plausiblement utiliser cette même valeur ? Si oui, encodez-la. Si non, codez-la en dur.
Implémentation dans toute la pile
Des propriétés personnalisées CSS à la limite du token. Définissez les primitives et les sémantiques dans :root, substituez dans [data-theme="dark"]. Les composants font référence aux tokens sémantiques, jamais aux primitives.
Des tokens accessibles en JS via un fichier TypeScript généré à partir de la même source. Des outils comme Style Dictionary, Theo, ou un petit générateur personnalisé produisent à la fois des variables CSS et des exports TS à partir d'une source JSON ou YAML unique. La source unique signifie que les animations JS et les styled components restent synchronisés avec les feuilles de style.
Documentez le système sur une seule page (une page Storybook ou une page /design sur le site lui-même) afin que les futurs contributeurs la trouvent. Les systèmes de tokens qui ne sont pas découvrables sont contournés en quelques mois par des gens qui ignorent leur existence.