Design system

Un design system est un ensemble structuré et documenté de composants, de règles visuelles et de principes d’usage, partagé entre designers et développeurs pour garantir la cohérence d’un produit digital. Typographies, couleurs, espacements, composants d’interface et bonnes pratiques y sont réunis au même endroit.

Les couches d’un design system

On le comprend mieux en le découpant du plus abstrait au plus concret :

1. Les principes. Ce que le produit cherche à être (simple, accessible, rassurant) et les règles de décision qui en découlent.
2. Les fondations. Couleurs, typographies, espacements, ombres, stockés sous forme de design tokens : des valeurs nommées, utilisables à la fois dans le design et dans le code.
3. Les composants. Boutons, champs, cartes, menus, avec leurs états et leurs variantes. C’est la partie qui ressemble à un UI kit.
4. Les modèles d’assemblage. Des combinaisons de composants qui reviennent : un formulaire de connexion, un tableau filtrable, un en-tête de page.
5. La documentation. Pour chaque élément : quand l’utiliser, quand l’éviter, comment le rendre accessible, comment l’intégrer.
6. La gouvernance. Qui décide d’ajouter ou de modifier un composant, comment on propose un changement, comment les versions sont publiées.

Beaucoup d’équipes organisent les composants selon l’atomic design, une méthode qui les range par niveaux, des plus simples aux plus complexes.

À quoi ça sert

• La cohérence. Un même bouton se comporte de la même façon partout, sans que chaque équipe le redessine.
• La vitesse. On assemble des écrans à partir de briques existantes au lieu de repartir de zéro.
• La qualité par défaut. L’accessibilité (contrastes, focus clavier) se règle une seule fois dans le composant, et profite à tous les écrans qui l’utilisent.
• Un langage commun. Designers et développeurs parlent des mêmes objets, avec les mêmes noms, ce qui réduit les écarts entre la maquette et le produit livré.
• Une intégration plus rapide des nouveaux arrivants : ils trouvent un référentiel au lieu de deviner.

Quand en a-t-on besoin ?

Pas toujours. Pour un site de quelques pages, une bibliothèque de composants bien nommés suffit largement. Un design system devient utile quand plusieurs signaux s’accumulent :

• plusieurs produits, sites ou équipes qui construisent des interfaces en parallèle ;
• des écrans qui divergent peu à peu, avec des boutons et des couleurs qui varient ;
• du temps perdu à redessiner ou à recoder les mêmes éléments ;
• une refonte à venir qu’on veut pouvoir faire évoluer sans tout reprendre.

Le piège inverse existe aussi : construire un système trop tôt, avant d’avoir compris ce que le produit utilise vraiment. La pente raisonnable consiste à partir d’un inventaire de l’existant, à bâtir un UI kit, puis à le faire grandir vers un système quand les besoins le justifient.

Des exemples publics à étudier

Plusieurs design systems sont publiés en ligne et se lisent comme des manuels : Material Design de Google, Carbon d’IBM, Polaris de Shopify, ou, en France, le Système de design de l’État (DSFR), conçu pour les sites et services en ligne de l’administration. Ils montrent comment structurer la documentation, formuler les règles d’accessibilité et présenter les composants. Ce ne sont pas des modèles à copier tels quels : ils répondent aux besoins de leurs organisations.

Un design system sur Webflow

Sur Webflow, un design system s’appuie sur trois briques : des variables pour les couleurs, les typographies et les espacements, des classes nommées selon une convention claire, et des components réutilisables sur tout le site. Les bibliothèques partagées permettent désormais de les diffuser entre plusieurs sites d’un même espace de travail, comme nous le décrivons dans notre article sur les shared libraries de Webflow. Côté design, notre guide pour structurer un design system dans Figma montre comment préparer les composants pour que le développement suive.

Mesurer son efficacité

Un design system se pilote avec quelques indicateurs simples :

• la part des écrans construits avec des composants du système, par opposition aux éléments faits à la main ;
• le temps nécessaire pour livrer une nouvelle page ou un nouvel écran, avant et après ;
• le nombre de doublons repérés (trois boutons presque identiques, deux grilles concurrentes) ;
• les demandes de changement reçues : trop peu signale un système ignoré, trop beaucoup un système inadapté.

Le faire adopter

Un design system qui n’est pas utilisé ne vaut rien. Quatre habitudes aident :

• nommer une personne ou une petite équipe responsable de son évolution ;
• le documenter avec des exemples réels, pas seulement des captures de composants ;
• faciliter les demandes de changement : si proposer un ajout est pénible, les équipes contournent le système ;
• garder le design et le code synchronisés, faute de quoi la maquette et le site finissent par dire deux choses différentes.

Mazette.co construit des design systems, avec guide typographique et UI kit, dans son offre UX/UI et Product design.