Design system pour débutant : composants, règles et méthode de prise en main

Un design system est un référentiel partagé qui réunit des fondations visuelles, des composants réutilisables, leurs règles d’usage et leur traduction technique. Pour débuter, inutile de cataloguer toute une interface. Partez d’un problème réel, observez ce qui existe, documentez quelques décisions et testez trois composants courants dans un écran complet.

Ce qu’un design system contient vraiment

Une bibliothèque de boutons dans Figma ne constitue pas, à elle seule, un design system. Le système relie plusieurs niveaux de décision. Les fondations fixent les couleurs, la typographie, les espacements ou encore les rayons. Les composants assemblent ces choix. La documentation explique quand les utiliser, comment ils réagissent et qui peut les faire évoluer.

Cette définition rejoint celle du Système de Design de l’État : des composants réutilisables guidés par des standards et une gouvernance. Le DSFR est réservé aux services de l’État, mais sa documentation publique montre bien la différence entre un stock de fichiers et un système exploitable.

Niveau	Exemples	Question à résoudre
Fondations	Couleurs, textes, espacements, grille, icônes	Quelles valeurs communes employer ?
Composants	Bouton, champ, alerte, carte, onglet	Comment l’élément fonctionne-t-il ?
Modèles	Formulaire, en-tête, recherche, page de détail	Comment combiner les composants ?
Règles	Usage, contenu, accessibilité, contribution	Quand choisir ou modifier chaque solution ?

Le guide de Figma consacré aux bases des design systems distingue lui aussi les fondations, les bibliothèques de composants et les modèles d’interaction. Cette hiérarchie est utile, à condition de ne pas la transformer en programme rigide : chaque produit n’a pas besoin de la même profondeur.

Avant les composants, choisissez un problème précis

Le piège classique consiste à ouvrir un fichier vierge, fabriquer une palette idéale puis dessiner des dizaines de composants sans savoir qui les utilisera. Le résultat peut être propre et pourtant inutile.

Commencez plutôt avec un périmètre observable : un formulaire d’inscription incohérent, plusieurs boutons presque identiques ou des cartes dont le contenu casse sur mobile. Rassemblez les écrans concernés et notez les écarts. Quels styles se répètent ? Quels comportements se contredisent ? Quels choix ralentissent le passage de la maquette au code ?

Ce travail demande des compétences proches de celles mobilisées en UX design : comprendre la tâche, hiérarchiser l’information, prototyper et confronter une solution à son usage. Il évite surtout de normaliser une mauvaise réponse simplement parce qu’elle apparaît déjà partout.

À la fin de ce premier inventaire, formulez un objectif concret. Par exemple : « harmoniser les champs et les messages d’erreur du parcours de création de compte ». Ce cadre suffit pour commencer. Le menu général, les graphiques et le mode sombre pourront attendre.

Comment décrire un composant sans oublier l’essentiel

Prenons un bouton. Son rectangle coloré n’est que sa forme la plus visible. Un composant réutilisable doit aussi préciser sa fonction, son libellé, ses variantes, ses états et son comportement. La même logique vaut pour un champ de saisie, une alerte ou une fenêtre modale.

La fiche minimale d’un composant

Rôle : l’action ou l’information portée par le composant.
Quand l’utiliser : les situations adaptées, avec un contre-exemple si le choix prête à confusion.
Anatomie : texte, icône, zone interactive, aide ou message associé.
Variantes : uniquement les différences répondant à des besoins identifiés.
États : repos, survol, focus, actif, désactivé, chargement, erreur ou succès selon le cas.
Contenu : longueur attendue, vocabulaire, capitalisation et comportement avec un texte long.
Adaptation : rendu sur petit écran, avec zoom ou lorsque certaines données manquent.
Accessibilité : ordre de tabulation, focus visible, nom accessible, contraste et annonce des changements.

Ne dessinez pas seulement le cas parfait. Essayez un libellé long, une erreur, une donnée absente et une largeur étroite. Ce sont souvent ces situations qui révèlent si le composant est réellement réutilisable. Pour approfondir cette dimension, le guide ADE University sur l’accessibilité numérique en UX design replace les tests et la transmission aux développeurs dans le déroulement du projet.

Les critères des WCAG 2.2 proposés par le W3C donnent un cadre de vérification fiable. Ils couvrent notamment l’usage au clavier, la lisibilité, la prévisibilité des interfaces et l’aide à la correction des erreurs. Une maquette ne peut toutefois pas valider seule le HTML, la gestion du focus ou le fonctionnement avec une technologie d’assistance.

Fondations et tokens : fixer des rôles plutôt qu’une liste de valeurs

Les fondations limitent les décisions improvisées. Une échelle d’espacement évite d’inventer 14, 15 puis 17 pixels selon les écrans. Des styles typographiques donnent une hiérarchie stable. Pour ce dernier sujet, la méthode pour choisir une typographie de projet aide à arbitrer entre lisibilité, personnalité, hiérarchie et licence.

Un token est un nom partagé associé à une valeur. Le nom color-action-primary exprime un rôle, là où blue-600 décrit surtout une teinte. Cette distinction facilite une évolution de marque ou l’ajout d’un thème : les composants utilisent une fonction stable, tandis que la valeur peut changer à un endroit contrôlé.

Pour une première version, restez sobre : couleurs de texte, de fond, d’action, de bordure et d’état ; niveaux de titres et de texte courant ; petite échelle d’espacements ; rayons réellement présents. Chaque token doit répondre à un usage observé. Une collection abondante « au cas où » déplace le désordre au lieu de le réduire.

Une méthode de prise en main en six étapes

Délimitez un parcours. Choisissez une partie du produit assez petite pour être examinée et assez fréquente pour que l’effort soit utile.
Faites l’inventaire. Capturez les écrans, regroupez les éléments similaires et relevez les écarts de style, de contenu et de comportement.
Décidez des fondations nécessaires. Conservez les choix déjà cohérents. Corrigez uniquement les divergences qui gênent l’usage ou la production.
Construisez trois composants prioritaires. Un bouton, un champ et une alerte forment un bon exercice si votre périmètre contient un formulaire. Votre produit peut appeler un autre trio.
Recomposez un vrai écran. Testez les composants ensemble avec du contenu réaliste, plusieurs largeurs et les états critiques. Vérifiez ensuite leur implémentation dans le navigateur, pas uniquement dans l’outil de design.
Documentez puis attribuez la maintenance. Pour chaque composant, publiez les règles, exemples et limites. Désignez la personne ou le groupe qui examine les changements et explique comment proposer une contribution.

La documentation peut rester légère. Une page par composant avec une démonstration, les propriétés, les exemples d’usage et les points d’accessibilité vaut mieux qu’un long document séparé du code. Les outils de documentation de Storybook, par exemple, rapprochent les exemples exécutables et les consignes. Storybook n’est pourtant pas obligatoire : le bon support est celui que l’équipe consulte et sait maintenir.

Prendre en main un design system existant

Si vous rejoignez un projet déjà équipé, ne commencez pas par parcourir tous les composants. Prenez un écran simple à reproduire et remontez de l’usage vers les règles.

Identifiez les composants présents et retrouvez leur documentation.
Repérez les tokens utilisés au lieu de prélever les couleurs et dimensions à l’œil.
Comparez la maquette, le composant codé et son rendu en production.
Essayez les états au clavier, les erreurs, le texte long et la largeur mobile.
Notez une règle ambiguë et posez une question ciblée à la personne responsable.

Cette petite reconstruction révèle vite la logique de nommage, le niveau de flexibilité autorisé et les écarts entre design et développement. Si votre besoin n’est pas couvert, vérifiez d’abord qu’une combinaison existante convient. Une exception locale peut être légitime ; elle doit simplement être visible, argumentée et réévaluée avant de devenir un nouveau composant.

Les erreurs qui transforment le système en musée

La première est de confondre cohérence et uniformité. Un composant commun doit résoudre des usages communs, pas forcer des parcours différents à se ressembler. La deuxième est de multiplier les variantes pour satisfaire chaque demande. Trop d’options rendent le composant difficile à comprendre, à tester et à maintenir.

Autre erreur fréquente : laisser le fichier de design et le code évoluer séparément. Un état dessiné mais jamais développé n’aide personne. À l’inverse, une correction technique invisible dans la documentation crée une référence trompeuse. Une revue courte entre design et développement, menée sur le composant réellement exécuté, limite ce décalage.

Enfin, un design system sans responsable vieillit rapidement. Il faut pouvoir signaler un problème, proposer une évolution, annoncer une rupture et retirer une variante obsolète. Commencer petit n’empêche pas cette gouvernance. Cela la rend plus simple à apprendre.

Questions fréquentes sur les design systems

Quels composants faut-il créer en premier ?

Ceux qui sont à la fois fréquents, incohérents et importants dans le parcours choisi. Pour un formulaire, il s’agit souvent des boutons, champs et messages. Pour un catalogue, les cartes, filtres et états de résultat peuvent être prioritaires. L’inventaire doit décider, pas une liste universelle.

Faut-il maîtriser Figma pour comprendre un design system ?

Non. Un outil de maquettage facilite la création et le partage des composants visuels, mais les compétences centrales sont l’analyse des usages, la structuration des règles, l’accessibilité, la documentation et la collaboration avec le développement.

Quelle différence entre un UI kit et un design system ?

Un UI kit fournit surtout des éléments visuels réutilisables. Un design system ajoute des fondations, des comportements, des règles de contenu et d’accessibilité, une correspondance avec le code ainsi qu’un processus de maintenance. Le UI kit peut donc être une partie du système, mais il n’en couvre pas toute la logique.

Votre premier design system n’a pas besoin d’être impressionnant. Il doit permettre à une autre personne de choisir un composant, de comprendre ses limites et de produire un écran cohérent sans deviner les règles. Si ce test fonctionne sur un parcours réel, vous disposez déjà d’une base utile à étendre.

Camille Renaud, signature éditoriale d’ADE University