Système de design : de la décision au composant

Un système de design est un langage partagé entre produit, design, contenu et code. Il accélère les décisions répétées et rend les exceptions visibles. Ce n’est ni un catalogue de captures d’écran ni une collection de composants isolés.

Les quatre niveaux

1. Principes

Les principes donnent un filtre aux décisions : clarté avant décoration, progression visible, une action principale par zone, accessibilité dès la structure et retour explicite après une action.

2. Tokens

Un token nomme une décision réutilisable : couleur d’accent, surface, texte, espace, rayon, ombre, hauteur de contrôle ou durée de mouvement.

:root {
  --sl-accent: #00d1ff;
  --sl-text-primary: #ffffff;
  --sl-text-secondary: rgba(255, 255, 255, 0.72);
  --sl-space-4: 16px;
  --sl-radius: 12px;
  --sl-control-height: 44px;
}

Un nom sémantique survit mieux à un changement visuel qu’un nom comme --blue-3. Les tokens ne doivent pas devenir une couche d’indirection illisible : chacun doit avoir une intention et un lieu d’usage documentés.

3. Primitives

Une primitive porte un contrat bas niveau : Button, Input, Badge, Card, ProgressBar, Alert, Modal ou Tabs. Elle doit utiliser le bon HTML, exposer les états et accepter seulement les propriétés nécessaires.

4. Patterns

Un pattern assemble des primitives pour un problème récurrent : formulaire de connexion, liste filtrable, session de révision, résumé d’erreurs ou parcours de reprise. Le pattern documente la décision produit ; il ne doit pas masquer des règles différentes derrière le même nom.

Spécifier un composant

Pour chaque composant, écris une fiche courte :

Question	Exemple pour ProgressBar
Quel problème ?	Montrer l’avancement et le reste à faire.
Quel rôle ?	Une progression avec valeur et maximum exposés.
Quelles variantes ?	Indéterminée ou déterminée, selon le contrat.
Quels états ?	Repos, mise à jour, terminé, erreur si le produit le prévoit.
Quel contenu ?	« Carte 3 sur 10 », pas une barre sans contexte.
Quelles contraintes ?	Lisible au zoom, au clavier et avec un texte long.
Comment tester ?	Valeur 0, valeur maximale, changement dynamique et lecteur d’écran.

Une variante ne doit exister que si elle correspond à une intention, un niveau de priorité ou un état vérifiable. Button color="purple" décrit une apparence ; Button variant="primary" décrit une responsabilité.

Les états ne sont pas optionnels

Un composant interactif doit répondre aux questions suivantes :

• comment se voit le repos ?
• comment se voit et se décrit le focus ?
• que se passe-t-il pendant un envoi ou une attente ?
• quel changement confirme le succès ?
• comment l’erreur explique-t-elle la récupération ?
• que voit une personne quand il n’y a aucun résultat ?
• pourquoi l’action est-elle désactivée, et que peut-on faire à la place ?

Le composant peut fournir la mécanique et le style ; le contenu du message reste lié au contexte de la page. Une alerte générique ne doit pas remplacer un message d’erreur qui nomme le champ et la correction attendue.

Accessibilité dans le contrat

L’accessibilité se conçoit avec la primitive :

• bouton natif avant une div cliquable ;
• label visible avant placeholder ;
• aria-describedby pour l’aide et l’erreur ;
• focus-visible lisible ;
• aria-live seulement pour les changements qui doivent être annoncés ;
• tailles tactiles et reflow responsive ;
• mouvement réduit lorsque la préférence système le demande.

Une page ne devrait pas avoir à réparer un composant partagé avec cinq attributs ARIA et un gestionnaire clavier différent. Si elle le doit, le contrat du composant est incomplet.

Documentation et gouvernance

La documentation utile montre :

1. quand utiliser le composant ;
2. quand ne pas l’utiliser ;
3. un exemple minimal et un exemple avec erreur ;
4. les propriétés et leurs valeurs autorisées ;
5. les états clavier et responsive ;
6. les décisions de contenu et d’accessibilité ;
7. le propriétaire, la version et la procédure de modification.

Toute nouvelle primitive passe par une question simple : le problème est-il assez fréquent et assez stable pour mériter un contrat partagé ? Sinon, une composition locale peut être plus honnête.

Faire évoluer sans casser

• Ajoute une variante seulement avec un cas d’usage réel et un test.
• Préfère une migration documentée à un changement silencieux de sens.
• Marque une primitive obsolète et indique son remplacement.
• Vérifie les consommateurs avant de renommer un token.
• Mesure les erreurs d’usage ou de build après une évolution importante.
• Garde les textes et les règles de la locale anglaise alignés avec le français.

Atelier : spécifier une carte de révision

Écris la fiche du composant avant son CSS :

• rôle de la carte et objectif principal ;
• titre, question, réponse et progression ;
• action de révélation et action de réponse ;
• état en cours, validé, erreur et vide ;
• relation entre boutons et contenu ;
• comportement au clavier, au mobile et avec texte long ;
• preuve qui permet de dire « la carte est terminée ».

Une réponse possible

La carte est un <article> nommé par son titre. La question est un titre, la progression est du texte lisible, la réponse est reliée au bouton par aria-controls et son ouverture est exposée par aria-expanded. « En cours », « validée » et « erreur » sont des états accompagnés d’un texte. Les actions restent dans le flux, atteignables au clavier et empilées sur mobile. La carte est terminée lorsqu’une réponse correcte et une preuve de progression sont enregistrées.

Checklist du système

• Chaque token a une intention et un usage connu.
• Chaque composant a un rôle natif, un nom et des états documentés.
• Les variantes correspondent à des décisions, pas à des couleurs libres.
• Les erreurs, états vides et chargements sont représentés.
• Le focus, le clavier, le zoom, le responsive et le mouvement sont testés.
• Les exemples montrent aussi un contenu long et une traduction.
• La procédure de contribution et de retrait est claire.

Sources sérieuses

• GOV.UK Design System — principes, composants et contribution
• Material Design — foundations
• W3C WAI — ARIA Authoring Practices Guide
• US Web Design System — design tokens

Continue avec les règles CSS, puis mets le système à l’épreuve dans le parcours UI/UX interactif.