Design system : à partir de quand une PME en a-t-elle vraiment besoin ?
En décembre 2019, Figma a publié une expérience menée avec des designers : avec un design system à disposition, ils terminaient la même tâche 34 % plus vite que sans. L’étude a plus de cinq ans et Figma prévient lui-même qu’il s’agit d’un plafond, mesuré dans des conditions idéales. Le résultat reste parlant. Une bonne part du temps de conception part dans des décisions déjà prises ailleurs : la taille d’un bouton, la couleur d’une alerte, l’espacement d’un formulaire.
Le design system répond à ce problème. Longtemps réservé aux grands groupes, il intéresse aujourd’hui des PME qui gèrent un site, une application et une dizaine de supports en parallèle. Toutes n’en ont pas besoin. Cet article explique ce qu’il contient, montre deux exemples publics et propose des critères simples pour savoir si le vôtre doit attendre.
Un design system, concrètement
Un design system est un ensemble de règles et de composants réutilisables, documentés, qui servent à construire des interfaces cohérentes. Il réunit trois couches.
Les fondations d’abord : couleurs, typographies, espacements, grilles, ombres, rayons d’angle. On les exprime sous forme de « tokens », des variables nommées (couleur-primaire, espacement-m) partagées entre la maquette Figma et le code.
Les composants ensuite : boutons, champs de formulaire, cartes, menus, modales. Chacun existe une seule fois, avec ses variantes et ses états (survol, focus, désactivé, erreur).
La documentation enfin, la couche la plus négligée : quand utiliser tel composant, quand l’éviter, quelles règles d’accessibilité respecter. Sans elle, la bibliothèque devient un catalogue où chacun pioche au hasard.
La méthode de référence pour organiser tout cela reste l’Atomic Design de Brad Frost, publiée en 2016 : des atomes (un bouton) aux molécules (un champ de recherche), puis aux organismes (un en-tête), aux gabarits et aux pages.
Charte graphique, UI kit, design system : trois niveaux
La confusion est fréquente, y compris chez les prestataires. Une charte graphique fixe l’identité visuelle d’une marque sur tous ses supports, papier compris. Un UI kit rassemble des éléments d’interface dans un fichier de maquette. Le design system va plus loin : il relie la maquette au code, documente les usages et vit au rythme du produit.
En pratique, un design system s’appuie sur la charte. Il en reprend les couleurs et les typographies, puis les traduit en règles d’écran : contraste minimal, tailles de texte lisibles sur mobile, états interactifs.
Exemples de design system à étudier
Le Système de Design de l’État (DSFR)
En France, le Système de Design de l’État sert à produire les interfaces officielles des sites en .gouv.fr. Il propose plus de 50 composants prêts à l’emploi, des modèles de pages et des formulaires types. Service-public.gouv.fr et education.gouv.fr l’utilisent. Il est réservé aux services de l’État, mais sa documentation publique est une excellente école : chaque composant précise ses règles d’accessibilité.
Carbon, le design system d’IBM
Carbon se présente comme le design system open source d’IBM, construit sur l’IBM Design Language. Il couvre les fondations, les composants, des modèles d’interfaces et la visualisation de données. Sa force : la documentation explique le pourquoi de chaque règle, pas seulement le comment.
Ces deux exemples impressionnent par leur taille. Ne les copiez pas tels quels. Ils répondent aux besoins d’organisations qui comptent des centaines de designers et de développeurs.
Le bon moment pour créer votre design system
Voici les signaux que je surveille avant de recommander un design system à un client :
- au moins deux produits ou interfaces qui doivent se ressembler (un site et une application, un site et un extranet) ;
- plusieurs personnes qui conçoivent ou intègrent des écrans, en interne ou chez des prestataires ;
- des écarts visibles entre les pages : trois styles de boutons, des formulaires qui ne se comportent pas pareil ;
- une refonte de site en cours, qui oblige de toute façon à redéfinir les composants.
Si aucun de ces signaux n’apparaît, une charte claire et quelques gabarits suffisent. Un design system coûte du temps à créer, et surtout à maintenir. Sans personne pour le faire vivre, il se périme en quelques mois.
La maintenance mérite d’être prévue dès le départ. Désignez un responsable, même à temps partiel, qui valide l’ajout de nouveaux composants. Numérotez les versions, notez les changements dans un journal simple, et prévenez les équipes quand un composant évolue. Dans une PME, une demi-journée par mois suffit souvent. Sans ce rituel, chacun recrée ses propres variantes et la bibliothèque perd son intérêt.
À l’inverse, une jeune entreprise qui lance une application a souvent intérêt à poser des fondations dès le départ. Pendant la Startup Week de l’ESD, l’équipe Ami’go que je dirigeais a posé les bases d’un design system en cinq jours : palette, typographies, premiers composants. C’est ce socle commun qui a permis à onze personnes, réparties entre création et UX, d’avancer sur les mêmes écrans sans se contredire.
Commencer petit, et en partant de l’existant
La meilleure façon de démarrer tient en trois étapes. Faites l’inventaire des écrans existants et listez chaque composant, avec ses variantes. Ensuite, fusionnez : trois boutons proches deviennent un bouton avec trois variantes. Enfin, documentez d’abord les composants les plus utilisés, souvent une quinzaine, avant de viser l’exhaustivité.
Pensez accessibilité dès les fondations. Les règles WCAG 2.2 imposent un contraste de 4,5:1 pour le texte courant : vérifiez chaque couleur de la palette avant qu’elle n’entre dans cinquante composants.
Sur l’étude de cas UGC, le point de départ a été la marque elle-même : typographie variable, palette étendue, motifs modulaires organisés autour d’une grille. Ces fondations ont ensuite été pensées pour l’animation et déclinées sur des supports très différents, de l’écran d’accueil de l’application aux visuels sociaux.
Un design system rassemble des fondations, des composants et une documentation partagés entre design et développement. Il fait gagner un temps réel, à condition de correspondre à la taille de l’équipe et d’avoir un responsable. Pour beaucoup de PME, le bon point de départ est modeste : une charte solide, une quinzaine de composants bien documentés, et une règle simple pour en ajouter.
Vous hésitez sur le niveau dont votre équipe a besoin ? Échangeons sur votre projet ou découvrez l’accompagnement en design UX/UI du studio.
Sources
