En tant qu’UX Designer et Researcher, j’accompagne régulièrement des équipes pour structurer la création de leurs produits numériques. S’il y a bien un sujet qui revient sans cesse, c’est celui de la cohérence et de l’efficacité. C’est là qu’entre en scène le Design System.
Mais qu’est-ce que c’est, au juste ? Un Design System, ce n’est pas juste une « bibliothèque de composants » ou un « guide de style ». C’est l’unique source de vérité qui rassemble les principes, les composants réutilisables, et la documentation nécessaires pour concevoir et développer un produit numérique de manière cohérente et à grande échelle.
Si vous vous demandez : « Comment faire un Design System ?« , cet article est pour vous ! Nous allons explorer les étapes clés, de la stratégie initiale à son développement, pour en faire un outil vivant et performant.
Réfléchir son Design System : poser les fondations
Avant de vous lancer tête baissée dans la création de boutons et de cartes, il est crucial de définir la stratégie de votre Design System. Sans elle, vous risquez de créer un bel outil… que personne n’utilisera ou qui ne répondra à aucun besoin réel.
Les questions essentielles à se poser :
- Pour qui est-il fait ? S’adresse-t-il uniquement aux designers et développeurs ? Aux équipes marketing ? Aux rédacteurs ?
➜ Définir votre audience interne est le premier pas. - Quel problème résout-il ? Manque de cohérence entre les produits ? Temps de développement trop long ? Forte dette technique et visuelle ?
➜ Le Design System doit être la solution à une ou plusieurs de ces douleurs. - Quelles sont les priorités business ? Vise-t-on l’accélération du time-to-market ? La réduction des coûts de maintenance ? L’amélioration de la marque perçue ?
➜ Le Design System doit servir les objectifs de l’entreprise.
Les enjeux et les KPI à mettre en place :
Votre Design System doit prouver sa valeur ! Voici quelques exemples de KPI (Key Performance Indicators) que vous pouvez suivre :
- Taux d’adoption : Combien de projets ou d’équipes utilisent activement le Design System ?
- Vitesse de conception/développement : Le temps pour créer une nouvelle page ou fonctionnalité est-il réduit ? (Exemple : mesurer le temps nécessaire pour développer un composant réutilisable vs. le recréer de zéro).
- Réduction de la dette design/technique : Combien de composants redondants ou incohérents ont été retirés ou unifiés ?
- Amélioration de la cohérence : Mesurer le niveau de variation entre les différents produits (cela peut être qualitatif au début, puis s’affiner).
Considérez votre Design System comme un produit à part entière. Il a ses propres utilisateurs (vos collègues), sa propre feuille de route et ses objectifs business.
Par quoi commencer ? De la petite victoire à la structuration complète
L’idée de concevoir un Design System complet peut être intimidante, et le risque est de ne jamais le lancer. C’est pourquoi je vous encourage à adopter une approche « commencer petit pour grandir » aussi appelée la « méthode des petits pas ». Le but est de créer un élan positif en livrant rapidement des éléments qui apportent une aide concrète aux équipes.
Lancer la machine : les « Quick Wins »
Pour vos débuts, concentrez-vous sur le Design System Minimum Viable (DSMV). Ce n’est pas nécessaire de tout refaire de zéro ! Votre première version doit se concentrer sur les éléments les plus utilisés ou les plus problématiques de vos produits existants.
Et pour savoir par quoi commencer, pas de surprise, il va falloir enquêter avec :
L’audit de l’existant : Faites l’inventaire des composants déjà en place. Identifiez les 5-10 composants les plus courants (boutons, champs de formulaire, liens) et les 2-3 couleurs principales. Vous trouverez souvent une dizaine de nuances de gris différentes !
Cibler les « utilitaires » : Commencez par définir et documenter les éléments qui simplifient la vie immédiatement :
Tokens de Design : La palette de couleurs unifiée, les typographies, et la grille d’espacement. Ce sont des décisions rapides qui ont un impact visible partout.
Les composants de base : Boutons primaires et secondaires, les champs d’entrée (inputs).
Le succès de ce lancement initial réside dans l’adoption rapide. En fournissant ces « quick wins » et en résolvant quelques points de friction évidents, vous prouvez la valeur du Design System et vous vous assurez que les équipes sont prêtes à investir dans sa croissance.
Faire grandir le Design System en fonction des besoins
Une fois que ces fondations sont posées, votre Design System doit devenir un reflet des besoins réels de vos produits.
Priorisez par l’usage : Ne construisez pas de composants « au cas où ». Priorisez les éléments que vous réutiliserez immédiatement dans les prochains sprints de développement ou de refonte.
Intégrez du feedback : Discutez avec les développeurs et les designers. Quels composants leur font perdre du temps ? Lesquelles sont le plus souvent modifiées d’un projet à l’autre ? Ces éléments sont les prochains candidats à l’intégration dans votre Design System.
C’est un processus organique : vous construisez ce dont vous avez besoin, quand vous en avez besoin.
Structurer avec l’Atomic Design
Au fur et à mesure que votre bibliothèque s’étoffe, elle gagne en complexité. Pour garder les idées claires, vous pouvez adopter la méthodologie de l’Atomic Design de Brad Frost. Elle permet de structurer votre Design System du plus petit au plus grand :
Atomes : Les éléments fondamentaux qui ne peuvent être décomposés (une couleur, une police, une icône, un bouton simple).
Molécules : Des groupes d’atomes assemblés pour former une unité fonctionnelle simple (un champ de recherche composé d’un input et d’un bouton).
Organismes : Des groupes de molécules et/ou d’atomes formant une section plus complexe de l’interface (l’en-tête de votre site, la navigation principale).
Templates et Pages : L’assemblage des organismes pour créer des mises en page complètes, puis des pages avec le contenu final.
Cette approche vous offre une vision claire de la dépendance entre les éléments et facilite grandement la maintenance et l’évolution de votre Design System.
L’itération : un outil vivant et changeant
Un Design System n’est pas un document figé qu’on range dans un tiroir. C’est un outil vivant qui doit évoluer au rythme de votre produit et des besoins de vos utilisateurs.
Tester, ajuster, recommencer
En tant qu’UX Researcher, je ne peux qu’insister sur l’importance du test. Vous devez tester les éléments du Design System, non seulement auprès de vos utilisateurs finaux (sont-ils accessibles ? compréhensibles ?), mais aussi auprès de ses utilisateurs internes (vos designers et développeurs).
Test des usages internes : Le Design System est-il facile à naviguer ? La documentation est-elle claire ? Les développeurs trouvent-ils rapidement le code du composant ?
Tests utilisateurs finaux : Une nouvelle variation de bouton améliore-t-elle le taux de clic ? Une nouvelle navigation est-elle mieux comprise ?
N’ayez jamais peur de recommencer ou d’abandonner un composant qui ne fonctionne pas. L’itération est la clé pour atteindre la maturité. Un Design System qui ne change jamais est un Design System qui est déjà obsolète.
Le développement : de la maquette au code
C’est ici que le Design System prend tout son sens. Un Design System qui n’est qu’une maquette dans Figma ou Sketch n’est pas 100% fonctionnel.
Le lien entre Design et Dev : La double-vérité
Pour être efficace, un Design System doit exister sous une double-vérité :
La vérité Design : La bibliothèque de composants dans l’outil de design (Figma, Sketch, Adobe XD, Penpot).
La vérité Code : La bibliothèque de composants réels et fonctionnels, prêts à être importés dans les projets (React, Vue, Angular, etc.).
L’enjeu est de maintenir la synchronisation entre ces deux vérités.
Si le composant n’est pas développé, ou s’il est développé « à la main » par chaque équipe de façon isolée, c’est la porte ouverte à la fragmentation. Chacun va re-développer à sa sauce les éléments, créant ainsi une incohérence et une dette technique et visuelle gigantesque. Le moindre changement (changer la couleur principale, par exemple) devient un cauchemar.
Un Design System pleinement fonctionnel est un Design System développé. Il permet aux développeurs de bénéficier d’une mise à jour fluide et centralisée des composants, assurant que tout l’écosystème reste cohérent sans effort colossal.
Finalement… Design System ou Framework ? À vous de choisir !
Créer un Design System est un investissement stratégique qui paye sur le long terme en termes de qualité, de rapidité et de sérénité pour les équipes. De la stratégie initiale (KPI, audience) à l’itération constante (tests, ajustements), en passant par sa concrétisation en code, chaque étape est essentielle.
Mais une question demeure pour démarrer un nouveau produit : faut-il toujours créer son propre Design System, ou peut-on s’appuyer sur des Frameworks existants (comme Bootstrap, Material Design, Tailwind CSS, etc.) ?
Les Frameworks sont rapides à implémenter et apportent une solution « prête à l’emploi », mais peuvent manquer de singularité. Le Design System apporte une cohérence et une identité de marque fortes, mais demande un investissement initial plus important.
Et vous, pour vos projets, privilégiez-vous l’identité forte d’un Design System fait maison, ou la rapidité d’un Framework ? Quel est votre retour d’expérience sur l’utilisation des Design Systems dans vos équipes ? Discutons-en !
