Système de design
Un système de design est l'ensemble des décisions partagées à partir desquelles les interfaces d'un produit sont construites — couleur, typographie, espacement, composants et les règles qui les gouvernent — auquel s'ajoute ce qui fait tenir ces décisions. Les artefacts en sont la moitié visible. La moitié que l'on peut faire respecter est ce qui sépare un système d'un document, car une règle que personne ne vérifie n'est qu'une suggestion, et une suggestion qui ne fait silencieusement rien est pire que de ne l'avoir jamais écrite.
Ce qui existe vraiment et ce qui n'est que dans le document
La plupart des descriptions d'un système de design sont une liste d'artefacts : jetons, composants, motifs, documentation. La liste est exacte et légèrement trompeuse, car elle décrit ce que vous produisez et non ce qui le fait fonctionner. Chaque couche existe en deux versions : celle qui est écrite et celle que quelque chose vous empêchera réellement de casser.
- Les jetons — des valeurs nommées pour la couleur, la typographie, l'espacement et le rayon. Sans mise en application, ils deviennent une palette dans laquelle on copie des codes hexadécimaux.
- Les composants — l'unique implémentation d'un élément qui se répète. Sans mise en application, un dossier d'exemples posé à côté d'une douzaine de variantes faites à la main.
- Les motifs — la façon dont les composants se combinent pour une tâche récurrente, comme un en-tête de page ou un état vide. Sans mise en application, chaque page résout le même problème autrement.
- La documentation — le raisonnement, et les cas où une règle ne s'applique délibérément pas. Sans mise en application, un site que plus personne n'ouvre après la première semaine.
La distinction mord le plus fort dans les petites équipes, où le système est en général la mémoire d'une seule personne. La mémoire ne tombe pas en panne bruyamment. Elle tombe en panne sous forme de dérive — le même titre en cinq tailles, le même bouton en trois graisses — et chaque cas pris isolément paraît défendable.
L'échec que personne ne repère : une règle inerte
En voici un tiré de notre propre produit, et c'est la raison d'être de cette entrée. Notre police d'affichage est livrée avec exactement une graisse. Une règle globale mettait tous les titres en graisse 500, et elle ne faisait strictement rien, parce que la correspondance de graisses en CSS ramène une demande de 500 vers la seule graisse que la police possède réellement. La déclaration était présente, plausible et inerte. Ce qui a coûté cher, c'est le contournement : environ 180 des 223 endroits utilisant cette police avaient fini par écrire à la main une graisse de 400 pour réparer une déclaration qui n'avait jamais pris effet, et la même surface avait dérivé vers 44 tailles de police distinctes.
Rien de tout cela n'est visible pour un vérificateur de types, car chacune de ces variantes est un objet de style valide. Ce n'est guère plus visible en revue : chaque diff fait une ligne, et chaque ligne est défendable. La réparation a été structurelle et non cosmétique — un composant est devenu le seul endroit où la taille d'un titre de page peut s'écrire, et un test fait désormais échouer la compilation quand une page fabrique la sienne à la main. Ce test est le système de design. Les jetons n'en ont jamais été qu'une description.
Ce dont une petite équipe a réellement besoin
- Partez de la répétition, pas d'un gabarit. Les primitives qui méritent un nom sont celles que vous avez déjà retapées trois fois. Le reste est un stock que vous entretiendrez sans jamais l'utiliser.
- Placez la règle là où elle s'applique, pas là où elle se lit. Un composant partagé, une règle de lint ou un test qui échoue valent mieux qu'une page de wiki, car un seul de ces trois survit à un vendredi pressé.
- Jugez les changements en composition, jamais isolément. Une graisse ou une taille semble correcte seule et devient fausse à côté d'un badge, d'un en-tête de tableau et d'un passage en gras. Affichez l'écran réel avec tout cela en même temps.
- Méfiez-vous des déclarations incapables d'agir. Un jeton qui pointe vers quelque chose que votre police, votre framework ou votre politique de sécurité du contenu ne peuvent pas honorer est pire qu'un jeton absent, parce qu'il se lit comme résolu.
- Laissez le système s'arrêter à la frontière de votre produit. Les pages marketing et l'interface produit veulent souvent des typographies différentes ; restreindre une exception à l'une des deux est une décision, retourner par accident la valeur globale n'en est pas une.
Si c'est une IA qui écrit vos interfaces, cela compte davantage et non l'inverse : un modèle tend vers la médiane tant que rien ne le resserre, et c'est exactement l'écart que des paquets de règles de design comme UI UX Pro Max cherchent à combler. La cohérence est aussi la forme de crédibilité la moins chère sur les pages où quelqu'un est en train de décider — la même raison pour laquelle les Core Web Vitals et le travail de conversion arrivent souvent le même mois.
FAQ
- Ai-je besoin d'un système de design pour un produit d'une seule page ?
- Non, et en construire un d'abord est une manière éprouvée de passer une semaine sur rien. À cette taille, il vous faut une cohérence qui tient dans votre tête et un fichier partagé de valeurs de couleur, de typographie et d'espacement. Le système commence à valoir son coût au moment où vous retapez des décisions, ou bien où une deuxième personne les prend sans vous.
- Un système de design, est-ce la même chose qu'une bibliothèque de composants ?
- Une bibliothèque de composants en est une couche : les pièces implémentées. Un système de design porte en plus les valeurs dans lesquelles ces pièces puisent, les motifs qui disent quelle pièce employer pour une tâche récurrente, et ce qui empêche une cinquième variante d'apparaître discrètement. Une bibliothèque sans cela est un dossier de composants qui dérivera comme n'importe quoi d'autre.
- Faut-il adopter un système tout fait ?
- Le plus souvent oui au début, pour la même raison que vous utilisez un framework : quelqu'un a déjà résolu les états de focus, le contraste et le mode sombre. Le coût arrive plus tard, quand votre marque doit ressembler à elle-même et que vous vous retrouvez à surcharger le système à cinquante endroits. Adoptez-en un, mais gardez vos propres décisions de couleur et de typographie dans une couche qui vous appartient.
- Comment l'empêcher de dériver ?
- Faites en sorte que le chemin partagé soit le plus rapide et que l'alternative échoue. Si attraper le composant va plus vite que de le refaire à la main, la dérive s'arrête presque d'elle-même ; si c'est plus lent, aucune quantité de documentation ne la retiendra. Un test qui échoue devant une variante faite à la main vaut mieux qu'un guide de style que personne ne rouvre.
- Un système de design aide-t-il la conversion ?
- Indirectement, et pas de la façon dont on le vend d'ordinaire. Il ne rendra pas une page persuasive. Il supprime les petites incohérences — des graisses qui jurent, trois styles de bouton, un formulaire qui semble à moitié fini — qui font hésiter un visiteur sur la réalité du produit, et l'hésitation coûte cher précisément sur les pages où quelqu'un est proche de décider.
An AI growth team that runs this for you
AgentCeres is a managed AI marketing team — you approve what ships. 14-day free trial, from $39/month.