Journal
Un design system utile ne vit pas dans Figma
On réduit souvent un design system à une bibliothèque de composants Figma. C’est la partie visible, et la plus facile à montrer. Mais son vrai test n’est pas là : un design system utile se mesure à l’autonomie qu’il donne aux gens qui ne sont pas designers. La bonne question n’est pas « combien de composants ? » mais « qui peut prendre une bonne décision sans moi ? ».
Voici comment je l’aborde, à partir d’un cas concret livré chez Homair Vacances.
Le vrai test d’un design system : l’autonomie
Sur la refonte Homair, chaque page produit s’ouvre sur une photo qui donne le ton de la page. Avec plusieurs centaines de campings au catalogue et des équipes marketing qui alimentent le site en continu, valider chaque choix photo était impossible — et rester ce point de passage obligé, c’était devenir le goulot d’étranglement de la production.
La réponse n’a pas été un composant de plus, mais une charte de sélection : des critères explicites de cadrage, de lumière et de composition, transmis aux équipes pour choisir en autonomie des visuels cohérents avec la direction artistique. Le design a cessé d’être un validateur pour devenir un cadre. (Le détail : Formaliser une charte visuelle pour les pages produit.)
Rendre le critère vérifiable au moment où l’on publie
Un critère écrit, seul, se dégrade vite : chacun l’interprète. Ce qui le fait tenir, c’est de le rendre vérifiable là où la décision se prend.
À la charte, j’ai donc ajouté des gabarits de recadrage interactifs : ils simulent immédiatement le comportement responsive d’une image, mobile et desktop, et montrent que les zones clés ne seront jamais coupées. Le critère devient vérifiable par celui qui publie, au moment où il publie — pas trois écrans plus loin dans une revue design. C’est ça, un design system qui tient : moins de règles à retenir, plus de décisions rendues évidentes par l’outil.
Un design system, c’est d’abord une traduction
Avant d’être une bibliothèque, un design system est une traduction : passer d’une intention — une direction artistique, une vision — à quelque chose que d’autres peuvent exécuter sans la perdre.
Sur la refonte, la direction visuelle venait d’un directeur artistique freelance. Mon rôle a été de la traduire en un système exploitable par les développeurs et les équipes produit, puis de le maintenir cohérent d’une page à l’autre — au point qu’il a ensuite été réutilisé pour d’autres productions. Un design system n’est pas le livrable d’un designer solitaire ; c’est l’infrastructure qui permet à plusieurs mains de produire la même qualité. (Contexte : Être le point de continuité d’une refonte à plusieurs mains.)
Ce qu’un design system doit vraiment produire
Les composants sont la partie émergée. Le vrai livrable est ailleurs : des décisions reproductibles, une équipe autonome, et un designer qui n’est plus un goulot d’étranglement. C’est le même réflexe que pour la conversion d’un tunnel de réservation — ne pas se demander « quoi refaire ? » mais « qu’est-ce qui, une fois posé, tiendra sans moi ? ».
Un design system se juge donc à ce qu’il permet quand le designer n’est pas dans la pièce. S’il faut encore vous solliciter à chaque page, il n’a pas encore fait son travail.
En bref
- Un design system ≠ une bibliothèque Figma. Les composants sont visibles ; le livrable réel est l’autonomie qu’il donne aux non-designers.
- Transmettez le critère, pas l’arbitrage. Des règles explicites de décision valent mieux qu’une validation design à chaque publication.
- Rendez le critère vérifiable au moment de publier. Un outil qui montre le résultat sur-le-champ tient mieux qu’une règle à retenir.
- Mesurez-le à l’autonomie. S’il faut encore vous solliciter à chaque page, le système n’a pas fait son travail.