La plupart des équipes pensent qu'un système de design est un fichier Figma et une bibliothèque de composants. Ce sont des artefacts d'un système de design, pas le système lui-même. Le système réel est l'ensemble des décisions — échelle d'espacement, logique des couleurs, règles de mouvement, quand utiliser quel motif — qui permettent à un produit de rester cohérent à mesure que plus de personnes, dans plus d'équipes, y touchent.
Le mode d'échec que nous observons le plus souvent n'est pas une bibliothèque de composants manquante. Ce sont des composants qui existent mais dont les décisions sous-jacentes n'ont jamais été consignées, si bien que chaque nouveau contributeur réinvente le raisonnement à partir de zéro, et le système dérive un peu à chaque ajout.
Ce que nous construisons pour nos clients à la place, c'est un petit ensemble de primitives assorties de règles explicites — pas seulement à quoi ressemble le bouton, mais quand utiliser un bouton plutôt qu'un lien texte plutôt qu'un CTA magnétisé, et pourquoi. Les composants comptent moins que les règles qui les ont générés, parce que les règles se généralisent à des cas que personne n'avait conçus.
Le test d'un bon système de design n'est pas de savoir s'il paraît soigné dans le fichier. C'est de savoir si un nouvel ingénieur, six mois plus tard, peut construire un écran que personne n'a conçu et le faire paraître naturel.