Un design system qui tient dans le temps

Un design system meurt presque toujours de la même façon : il devient un fichier que plus personne n'ouvre. Six mois après sa livraison, l'interface réelle contient onze nuances de gris, quatre tailles de bouton et trois façons d'afficher une erreur — et la maquette, elle, en montre toujours une seule.

Ce qui fait vivre un système, c'est le code

Un système tient quand il est plus facile de l'utiliser que de le contourner. Concrètement : les couleurs, les espacements et les tailles de texte sont déclarés à un seul endroit, et une page ne peut pas écrire une couleur à la main. Sur nos projets, ce n'est pas une consigne d'équipe — c'est un test qui échoue si un fichier contient un code hexadécimal en dur. Une règle qu'on peut oublier n'est pas une règle, c'est un vœu.

Commencez petit et laissez-le grossir

Les systèmes construits d'un bloc, avec quatre-vingts composants prévus « pour plus tard », sont ceux qu'on abandonne : la moitié ne servira jamais, et l'autre moitié ne correspondra pas au besoin réel le jour où il arrivera.

Un système utile commence avec ce que vos pages utilisent déjà — boutons, champs, cartes, titres. On ajoute un composant quand un troisième écran en a besoin, pas au deuxième : à deux, on ne sait pas encore ce qui est réellement commun et ce qui se ressemble par hasard.

Nommez par le rôle, jamais par l'apparence

Une couleur appelée vert devient un mensonge le jour où la marque change. La même couleur appelée accent reste vraie. Idem pour bouton-grand, qui ne dit pas à quoi il sert, face à action-principale, qui le dit.

Ce détail de vocabulaire décide de la durée de vie du système. Nommé par l'apparence, il faut le refaire à chaque changement de charte. Nommé par le rôle, il traverse les refontes en ne changeant que ses valeurs — et c'est exactement ce qu'on lui demande.