Tous les articles
Un design system, ce n'est pas qu'une bibliothèque de composants. C'est un langage commun entre le design et le développement, un référentiel unique où chaque couleur, chaque typographie et chaque interaction sont définies une seule fois, de manière cohérente, puis réutilisées partout.
Sans lui, les problèmes s'accumulent rapidement : des composants recréés d'un écran à l'autre avec de
légères variations, des incohérences visuelles qui apparaissent au fil des mises à jour, ou encore
des développeurs contraints d'interpréter les maquettes faute de référence claire. Avec un design
system, on gagne en rapidité d'exécution, en cohérence et en qualité de collaboration.
La méthode que j'applique s'adapte au contexte du projet : créer un design system dès le départ ou
structurer un produit qui existe déjà.
Construire un design system de zéro
1. Poser les fondations visuelles
Tout commence par les éléments identitaires du client : ses couleurs, ses typographies et son univers graphique. À partir de là, je définis trois couleurs principales :
-
Une couleur primaire : la couleur dominante de la marque, présente sur les éléments clés de l'interface,
-
Une couleur secondaire : complémentaire, utilisée pour structurer l'interface,
-
Une couleur d'accent : plus marquée, réservée aux éléments que l'on souhaite mettre en avant (CTA, badges, alertes...).
Pour la typographie, je travaille avec deux à trois familles de caractères maximum. Au-delà, la cohérence visuelle devient plus difficile à maintenir.
Une fois ces fondations définies, je crée les variables et les styles dans Figma selon un ordre précis :
-
Couleurs,
-
Typographies,
-
Espacements : définis en multiple de 8,
-
Effets : définition des ombres, des bordures et des rayons d'arrondi (radius).
Je constitue également une bibliothèque de visuels (illustrations, photos, icônes) qui viendra enrichir le projet au fil de sa conception.
Pourquoi une base de 8 ?
J'utilise un système où 1 rem correspond à 16 px. Cette base simplifie les choix d'espacement, crée une cohérence visuelle sur toute l'interface et s'aligne avec le système utilisé côté front-end. Designers et développeurs manipulent ainsi les mêmes valeurs et parlent le même langage.>
2. Construire les composants
Une fois les fondations définies, je construis les composants dans l'ordre des besoins, en commençant par les plus fondamentaux :
-
Éléments de base : boutons, barre de navigation, hiérarchie typographique (H1, H2, H3, texte courant...),
-
Composants d'interface : checkboxes, toolbars, filtres, menus déroulants,
-
Éléments de formulaire : champs de saisie, placeholders, messages d'aide et messages d'erreur.
-
Cards : ajoutées progressivement selon les besoins qui émergent.
3. Les booleans : gérer la structure du composant
Chaque composant est conçu avec des booleans permettant d'afficher ou de masquer certains éléments selon le contexte d'utilisation. Une card peut ainsi comporter un visuel, un badge ou un bouton d'action ou non, selon la variante souhaitée. Un seul composant couvre ainsi de nombreux cas d'usage sans duplication.
Booleans : rapidité et efficacité
Un composant bien pensé avec des booleans évite de créer des dizaines de variantes quasi identiques. C'est l'un des plus grands gains de temps en production : au lieu de chercher le bon composant, il suffit de paramétrer celui qui existe déjà.
4. Les variantes : gérer les états visuels et les micro-interactions
En complément des booleans, j'utilise les variantes de Figma pour définir les différents états
interactifs de chaque composant.
Pour un bouton, une checkbox, une toolbar ou un filtre, je définis systématiquement :
-
Default : l'état de repos,
-
Hover : l'apparence au survol,
-
Active / Selected : l'état sélectionné,
-
Disabled : l'état inactif.
Ces variantes permettent aux développeurs de visualiser précisément le comportement attendu pour chaque état, sans avoir à l'interpréter.
Booleans et variantes : deux outils complémentaires
Les booleans gèrent le contenu du composant (afficher ou masquer un élément), tandis que les variantes définissent son comportement lorsqu'un utilisateur interagit avec lui. Utilisés ensemble, ils permettent de couvrir l'ensemble des cas d'usage de manière propre, flexible et maintenable.
Faire évoluer un design system existant
Lorsqu'un produit existe déjà, la démarche est différente. Il ne s'agit plus de créer, mais de comprendre, d'analyser puis de reconstruire sur des bases solides.
1. Auditer avant toute modification
Avant de modifier la moindre couleur ou le moindre composant, je réalise un audit. Même lorsqu'il n'est pas explicitement demandé, cette étape me semble indispensable. Elle me permet de comprendre la structure du produit, d'identifier les incohérences existantes et de définir les priorités avant toute intervention.
Pourquoi réaliser un audit ?
Même informel, un audit réalisé en amont évite souvent de refaire deux fois le travail. C'est également un excellent outil de pédagogie avec le client : plutôt que d'affirmer qu'une interface manque de cohérence, on le démontre à travers des exemples concrets et des pistes d'amélioration.
2. Répertorier l'existant
Après l'audit, je réalise un inventaire complet des éléments présents : couleurs utilisées (y compris les variantes non intentionnelles), typographies, espacements, composants et styles. L'objectif n'est pas de tout conserver, mais de disposer d'une vision globale avant de prendre des décisions.
3. Travailler avec le client
Avant de reconstruire le design system, j'explique au client les bonnes pratiques et les raisons qui les motivent.
-
Trois couleurs principales maximum afin de conserver une identité visuelle cohérente,
-
Deux à trois typographies maximum pour assurer une hiérarchie claire,
-
Des espacements définis sur une base de 1 rem (16 px) afin d'assurer une cohérence visuelle et une meilleure correspondance avec l'intégration front-end,
-
Des radius, bordures et ombres harmonisés sur l'ensemble de l'interface.
Il ne s'agit pas d'imposer des règles, mais de les expliquer. Lorsqu'un client comprend leur intérêt, leur adoption devient beaucoup plus naturelle.
Une fois ce cadre validé, je construis ou restructure les composants selon la même méthode que pour un projet créé de zéro : boutons, menus, formulaires, cards, avec leurs booleans et leurs variantes.
Organisation dans Figma
Je structure systématiquement mes fichiers Figma en trois pages distinctes :
-
Design System : toutes les fondations (variables, styles et composants).
-
Wireframes : la phase exploratoire et les structures d'écrans.
-
Prototype : les écrans finalisés servant de référence.
Cette organisation évite les confusions entre les éléments en cours d'exploration et ceux qui font réellement référence, aussi bien pour moi que pour les développeurs.
La collaboration avec les développeurs
Un design system n'a de valeur que s'il est réellement utilisé par les équipes de développement. C'est pourquoi j'intègre les développeurs tout au long du projet, et pas uniquement lors de la livraison.
Nous échangeons régulièrement sur l'avancement du projet. Lorsqu'un composant évolue, même légèrement, je laisse une note directement dans Figma afin d'expliquer le changement et son objectif (par exemple, l'augmentation de la taille d'un texte pour améliorer sa lisibilité ou l'ajustement d'un radius pour harmoniser plusieurs composants).
Les développeurs travaillent directement à partir du fichier Figma, tandis que je centralise mes retours sur les éventuels écarts avec la maquette dans un document annexe sur Notion. Cette documentation facilite le suivi des corrections, permet de conserver un historique des remarques et fluidifie les échanges tout au long du développement.
Documenter les détails fait gagner du temps
Une différence de 2 px ou une ombre légèrement différente peut sembler anodine. Pourtant, ce sont ces détails qui font la différence entre une interface fidèle à la maquette et une interface qui s'en éloigne progressivement. Documenter ces ajustements prend quelques secondes, corriger leurs conséquences en production peut en demander beaucoup plus.
Un design system bien construit n'est pas un livrable que l'on remet à la fin d'un projet. C'est un outil vivant qui évolue avec le produit, s'enrichit de nouveaux composants au fil des besoins et accompagne les équipes dans la durée.
Au-delà des composants, il constitue avant tout un outil de collaboration entre designers, développeurs et clients. Le soin apporté aux fondations (variables, styles, booleans et variantes) conditionne directement la qualité, la cohérence et la rapidité de tout ce qui sera conçu par la suite.
