Quand vous avez vraiment besoin d’un design system

On pose généralement la question comme si un design system était une étape — quelque chose qu’une entreprise atteint une fois devenue assez sérieuse. Ce n’en est pas une. C’est un coût, payé d’avance, qui achète une chose précise : la capacité de changer d’avis sur l’apparence du produit sans le modifier à quarante endroits.

La question n’est donc pas de savoir si vous êtes assez grand. C’est de savoir si vous payez déjà pour son absence.

Ce qu’il achète réellement

Pas la cohérence pour elle-même, et surtout pas la beauté. Trois choses, par ordre d’importance :

1. 01Le changement devient bon marché. Ajuster un rayon d’angle, une nuance de gris ou un anneau de focus devient une modification au lieu d’une recherche. C’est tout le retour sur investissement ; le reste en découle.
2. 02La même décision cesse d’être reprise sans cesse. Chaque bouton redessiné de zéro rejuge de petites questions tranchées il y a des mois, par quelqu’un qui ignore peut-être qu’elles l’étaient.
3. 03Les nouveaux arrivants ont raison par défaut. Quelqu’un qui arrive n’a pas à absorber le goût maison par osmose pour produire un travail qui s’intègre.

Notez ce qui manque à cette liste : la vitesse. Un design system ne rend pas franchement la première version de quoi que ce soit plus rapide. Il rend la cinquième moins coûteuse — bénéfice différent et moins visible, et la principale raison pour laquelle il est difficile à financer.

L’argument contraire, pris au sérieux

Construit trop tôt, un design system est un impôt sur un produit dont la forme se discute encore. Deux coûts bien réels :

• Vous systématiserez les mauvaises choses. Abstraire un composant avant d’en avoir trois usages réellement différents produit un objet paramétrable qui ne convient à aucun. Le troisième usage est celui où le motif apparaît vraiment ; avant, on le devine.
• Cela renchérit l’exploration. Quand ajouter un cas particulier impose une discussion sur son appartenance au système, les gens cessent d’en ajouter — y compris ceux qui se seraient révélés être la bonne idée.

Un produit de huit écrans avec un seul designer n’a pas de problème de cohérence. Il a le goût d’une personne, ce qui est le design system le moins cher qui soit et ne demande aucune documentation.

Les signaux qu’il est temps

Ce sont les symptômes d’un coût déjà payé, ce qui les rend plus utiles que l’effectif comme déclencheur :

• Deux personnes ont construit le même composant différemment, la même semaine, sans le savoir. Le signal le plus clair qui soit.
• Un designer est en train de redessiner un bouton. Pas d’en concevoir un : de redessiner l’existant, faute de fichier où le récupérer.
• Vous ne pouvez pas répondre à « c’est quel gris ? » sans ouvrir un fichier et utiliser une pipette.
• Quelqu’un a proposé un changement et l’estimation était « quelques semaines » pour quelque chose de visuellement trivial. Ce chiffre est le coût de l’absence de système, énoncé à voix haute.
• Le même bug revient à un nouvel endroit — l’état de focus, l’état désactivé, ce qui casse avec un libellé long.
• La première contribution d’un nouvel arrivant détonne subtilement, et la relecture porte sur le goût plutôt que sur la justesse.

Commencez par les décisions, pas par les composants

L’échec courant consiste à démarrer par une bibliothèque de composants — un mois de travail pour vingt composants dont la plupart ne servent qu’une fois. L’ordre le moins coûteux est l’inverse.

Les jetons d’abord

Couleur, espacement, échelle typographique, rayons, ombres, durées d’animation. Ce sont de petites choses, ce sont les plus souvent incohérentes, et les nommer apporte à soi seul l’essentiel du bénéfice « changer coûte peu ». Un produit avec des jetons nommés et sans bibliothèque de composants est déjà en bien meilleure forme que l’inverse.

Puis seulement ce qui est vraiment réutilisé

Promouvez un composant à son troisième usage réel, pas au premier. Deux usages, c’est une coïncidence ; trois, c’est un motif — et à ce stade on voit quelles parties varient réellement.

Écrivez le pourquoi, pas seulement le quoi

Une bibliothèque de composants n’est pas un design system. Le système, ce sont les décisions : quand employer ceci plutôt que cela, ce que signifient les variantes, ce qui n’est délibérément pas proposé. Sans cela, on lit la liste de composants comme un menu et on choisit à l’apparence : l’incohérence réapparaît un cran au-dessus.

Faites que le système refuse ce qui ne va pas

Un design system tenu par la seule convention se dégrade, parce que la convention perd face aux délais. Ce qui survit, ce sont les parties que l’outillage rend pénibles à contourner : des noms de variantes typés, pour qu’une variante supprimée devienne une erreur de compilation plutôt qu’un composant affiché sans styles ; des jetons comme seul moyen d’obtenir une couleur ; des règles de lint pour la poignée de choses qui méritent un refus net.

C’est le même argument, développé plus longuement, que dans TypeScript avant de passer à l’échelle : la propriété utile n’est pas d’attraper les erreurs, c’est de connaître toute l’étendue d’un changement avant de le faire.

La réponse courte

Construisez-en un quand changer d’avis est devenu coûteux, et pas avant. Si vous ne pouvez pas citer un changement que vous avez voulu faire et renoncé à faire à cause de son coût, il est trop tôt — et le bon geste est de nommer vos jetons, de laisser le goût d’une personne décider, et d’attendre le troisième usage.

Si vous pesez cette question pour un produit déjà en vol, dites-nous ce que vous construisez.