Design system : définition, composants et exemples

Design system : la définition en clair

Un design system est un ensemble structuré de règles visuelles, de composants réutilisables et de documentation. Il sert de référence unique pour concevoir les interfaces d'un produit numérique. Ce n'est ni un fichier de maquettes ni une énième charte graphique, mais un outil de travail partagé que l'équipe design et l'équipe technique ouvrent chaque jour.

Prenez un bouton. Le système décrit son apparence, les cas où l'utiliser, sa réaction au survol et la façon dont il est codé. Un champ de formulaire, une carte produit ou une fenêtre modale reçoivent le même traitement. Chaque élément existe une seule fois, au même endroit, et tout le monde s'y réfère.

Venu de l'anglais, le terme s'emploie tel quel en français. Les lusophones disent aussi sistema de design, les hispanophones sistema de diseño. D'une langue à l'autre, l'idée reste la même : une seule source de vérité pour le design d'un produit.

Style guide vs design system : ce qui les sépare

Le style guide (ou guide de style) fixe l'identité visuelle : logo, palette, polices, ton éditorial. Il dit ce qu'il faut respecter sans fournir de pièces prêtes à l'emploi. Bien souvent, il dort dans un PDF statique que peu de monde ouvre.

Le design system englobe ce guide et va beaucoup plus loin. Il y ajoute les composants codés, les patterns d'usage, les règles d'accessibilité et un process pour faire évoluer l'ensemble. Autrement dit ? Le style guide décrit une marque, alors que le design system la rend utilisable dans un site, un logiciel ou une application.

• Style guide : des règles d'apparence, peu reliées au code.
• Design system : des règles, des composants prêts à servir, une documentation vivante et une gouvernance.
• Charte graphique : la base de votre branding, qui nourrit l'un comme l'autre.

À quoi sert un design system pour une entreprise

D'abord, la cohérence visuelle. Quand trois prestataires ont touché à votre site en cinq ans, on trouve souvent quatre nuances de bleu et six styles de boutons (je l'ai constaté plus d'une fois). Le visiteur ne saurait pas toujours dire pourquoi. Il perçoit pourtant un site moins fiable.

Vient ensuite la vitesse. Une nouvelle landing page s'assemble avec des composants déjà validés, sans repartir d'une page blanche. Le temps gagné va au contenu et à la conversion plutôt qu'au réglage d'une marge.

L'expérience utilisateur y gagne aussi. Testés une fois puis réutilisés partout, les composants donnent une interface intuitive, accessible et prévisible : votre client retrouve les mêmes repères sur la page d'accueil, dans le tunnel de commande et dans son espace personnel. C'est le terrain commun de l'UX et de l'UI, enfin traité comme un seul sujet.

Dernier atout, et pas le moindre : moins de dette technique. Vous corrigez un composant à un seul endroit, et la correction se répercute sur toutes les pages. Sans design system ? Il faut reprendre à la main chaque copie du bouton.

Les composants d'un design system

D'un design system à l'autre, l'allure change, mais on retrouve presque toujours les mêmes couches. Elles vont du plus abstrait (une valeur de couleur) au plus concret, un écran complet.

Les fondations : couleurs, typographie et espacements

Couleurs, typographie, espacements, ombres, arrondis, grille : c'est ce que fixent les fondations. On y trouve aussi les règles de contraste, utiles pour respecter l'accessibilité web et le RGAA. Icônes et illustrations y ont également leur place, avec leur style et leurs conditions d'usage.

Les design tokens

Ces choix visuels sont stockés dans les design tokens, des variables nommées. Au lieu d'écrire un code couleur en dur, on utilise un nom comme couleur-action-principale. La marque évolue ? Vous changez la valeur une fois, et le site, l'application et les maquettes suivent.

À mon sens, c'est la pièce qui relie vraiment le design et le développement. Le même token existe dans Figma sous forme de variable et dans le code sous forme de variable CSS ou de fichier de configuration. Les deux mondes parlent enfin le même langage.

Les composants et les patterns

Bouton, champ, case à cocher, menu, carte, alerte, pagination : ce sont les composants, les éléments d'interface réutilisables. Chacun est livré avec ses variantes et ses états (survol, focus, désactivé, erreur). On parle souvent de building blocks, les briques de construction du produit.

Les patterns vont un cran plus loin. Ils montrent comment combiner ces briques pour régler un problème récurrent, qu'il s'agisse d'un formulaire de contact, d'une recherche avec filtres ou d'un parcours d'inscription. Le composant dit quoi. Le pattern dit comment.

La documentation et les guidelines

Sans documentation, un design system n'est qu'une bibliothèque de fichiers. Les guidelines indiquent quand utiliser chaque composant, quand l'éviter et avec quels textes, exemples et contre-exemples à l'appui. Grâce à elles, un nouveau développeur ou une agence extérieure s'y retrouve sans réunion.

La gouvernance et la contribution

Pour rester évolutif, un design system a besoin de règles du jeu. Qui valide un nouveau composant ? Comment signaler un besoin, et à quel rythme publier les mises à jour ? Ce modèle de contribution évite deux dérives : d'un côté le système figé que plus personne n'utilise, de l'autre celui qui, ouvert à tous, se remplit de doublons.

Comment ça marche : l'atomic design et les outils

Pour structurer un design system, la méthode la plus citée est l'atomic design, formalisée par Brad Frost. Elle emprunte son vocabulaire à la chimie et découpe l'interface en cinq niveaux. C'est une manière de penser, pas une norme obligatoire.

• Atomes : les plus petits éléments, comme un libellé, un champ ou un bouton.
• Molécules : quelques atomes assemblés, par exemple un champ de recherche et son bouton.
• Organismes : des blocs complets, tels qu'un en-tête de site ou une grille de produits.
• Templates : la structure d'une page, sans le contenu définitif.
• Pages : le template rempli de vrais textes et de vraies images.

Cette logique pousse à concevoir du plus simple vers le plus complexe. Elle colle bien au travail par wireframe, puis maquette, puis intégration. Autre avantage : on voit tout de suite ce qui doit être réutilisé et ce qui peut rester propre à une page.

Le design system dans Figma

Pour les maquettes, Figma s'est imposé comme l'outil de référence pour héberger la partie visuelle. Ses bibliothèques partagées diffusent les composants dans tous les fichiers de l'équipe. Quant à ses variables, elles stockent les design tokens et gèrent par exemple un thème clair et un thème sombre.

Kits d'interface, gabarits pour les réseaux sociaux, fichiers de démarrage de design system : la communauté Figma partage de nombreuses ressources. Ce sont de bons points de départ, à une condition. Adaptez-les à votre marque au lieu de les copier tels quels !

Le design system dans le code

Dans le code, les composants sont développés avec le framework du projet, que ce soit React, Vue ou tout simplement du HTML et du CSS. Une vitrine de composants, souvent construite avec un outil comme Storybook, permet de les voir et de les tester isolément. Reste à l'équipe la tâche la plus ingrate : garder la maquette et le code alignés.

Exemples de design systems connus

Beaucoup de grandes organisations publient leur système en ligne. Ces exemples montrent à quoi ressemble un design system abouti, même si une PME n'a pas besoin d'une telle ampleur.

Carbon, le design system d'IBM

Carbon est le système open source d'IBM. Fondations, centaines de composants, patterns, documentation très fouillée sur l'accessibilité : tout y est. Il illustre bien l'idée d'un système unique au service de nombreux produits et de nombreuses équipes.

Le DSFR, design system de l'État

Les sites des services publics français s'appuient sur le Système de design de l'État, ou DSFR. Il impose une identité commune, la police Marianne, des composants accessibles et des règles d'usage strictes. Attention : seuls les sites de l'État peuvent l'utiliser. Une entreprise privée ne peut pas reprendre cette identité, mais rien ne l'empêche de s'inspirer de sa documentation.

Atlassian, Airbnb, Google et Apple

Chez Atlassian, le design system unifie des outils comme Jira et Confluence. Airbnb, de son côté, a fait connaître son Design Language System, pensé pour garder une expérience cohérente entre le web et le mobile. Google publie Material Design. Apple publie ses Human Interface Guidelines, qui servent de référence à quiconque conçoit une application pour ses plateformes.

Les erreurs courantes avec un design system

L'outil est rarement en cause. Quand un design system échoue, c'est presque toujours à cause de la façon dont on s'en sert. Quelques pièges reviennent souvent.

• Voir trop grand : vouloir couvrir cent composants avant d'en avoir livré dix. Partez plutôt de ceux qui servent déjà sur le site.
• Prendre un kit Figma pour un design system : sans code ni documentation, ce n'est qu'une bibliothèque de maquettes.
• Faire l'impasse sur la documentation : un composant sans règle d'usage sera détourné à la première occasion.
• Négliger l'accessibilité : contrastes, focus visible et tailles de cible se règlent dans le composant, pas page par page.
• Ne nommer aucun responsable : sans propriétaire, le système se fige ou accumule les variantes inutiles.
• Ignorer le responsive : pensez chaque composant pour le mobile, en lien avec votre approche du responsive design.

Mon conseil : traitez votre design system comme un produit à part entière. Il a ses utilisateurs (les designers et les développeurs), des besoins à recueillir et des versions à publier. C'est cette vision qui le fait durer au-delà du projet qui l'a vu naître.

Questions fréquentes