Innovation Digital & Tech

Idées reçues vs réalité : le quotidien du pilotage d'un design system (introduction)

Idées reçues vs réalité : le quotidien du pilotage d'un design system (introduction)

var(--variable-Qv6Rce5Op)

Sur papier : Material Design (Google), Carbon (IBM), Atlassian Design System (Salesforce), Polaris (Shopify), HIG d'Apple… Les standards de l'industrie que tout le monde cite et qui font l'unanimité. Ils inspirent, rassurent et donnent envie.

Sur le terrain : une réalité bien différente, des contraintes techniques, des arbitrages permanents, des compromis assumés, des priorités qui changent, des visions ambitieuses confrontées au quotidien d'équipes hétérogènes qui livrent et un design system qui s'adapte en continu.

Vous me voyez venir ?

Dans la réalité, la construction d'un design system se révèle être une boîte de Pandore avec ses 1001 surprises, beaucoup plus subtile et beaucoup plus humaine.

En tant qu'UX designer, travailler en amont sur les parcours, les besoins, frictions utilisateurs et l'expérience d'un service, avant même de toucher à un composant, a changé ma lecture du design system.

Avoir un ancrage UX fort permet de ne pas seulement avoir une vision de conception de bibliothèque d'assets mais de concevoir des référentiels vivants. Des frameworks qui permettent aux équipes de trancher plus vite, d'aligner les intentions produit et les contraintes dev, et de livrer de la cohérence sans sacrifier l'essentiel : l'expérience réelle de l'utilisateur final.

Et je comprends une chose fondamentale : un design system n'est pas une question d'outils, d'une belle documentation ou du niveau de structuration de l'entreprise. C'est une question d'alignement entre humains, contraintes et usage réel. Elle se mesure à son taux d'adoption réel, à la qualité des conversations qu'il génère entre designers, product managers, développeurs et équipes marketing, et à sa capacité à évoluer sans finir avec 22 versions parallèles qui coexistent sans qu'aucune ne fasse vraiment référence, comme les débuts de « Encore », le design system de Spotify.

À travers cette série de publications, je reviens sur 6 idées reçues courantes afin de les analyser, de les remettre en perspective et de partager avec vous ma propre lecture de la réalité. Les idées reçues ralentissent plus qu'elles n'aident. Elles peuvent créer de la frustration, des goulots d'étranglement, et déconnectent le design system des réalités terrain.

Les 6 idées reçues

  1. « Un design system doit être parfait avant d'être utilisé » → Mieux vaut 5 composants adoptés que 50 qui dorment dans Figma.

  2. « Il existe un modèle universel à copier » → Copier Material Design sans copier Google, c'est l'échec assuré. Le contexte compte plus que le framework.

  3. « Le designer design system ne fait que des composants » → Stratégie, accompagnement, gouvernance, adoption… C'est autant un projet humain que technique.

  4. « Un design system est une bibliothèque figée » → Ce n'est pas un livrable terminé, c'est un produit vivant qui évolue avec les usages réels.

  5. « Le design system tue la créativité » → Au contraire : moins de temps sur les boutons, plus de temps sur les vrais problèmes utilisateurs et le développement stratégique pour l'entreprise.

  6. « Un UI kit et une charte suffisent » → Un design system va bien au-delà : c'est de la gouvernance, de la pédagogie, de l'alignement humain.

Ce retour d'expérience s'inscrit dans un contexte projets précis. Il ne s'agit pas d'un mode d'emploi universel ni d'une vérité absolue sur les design systems. Mais plutôt un partage de terrain, destiné à nourrir les réflexions, ouvrir des pistes et à aider celles et ceux qui se lancent ou qui souhaitent prendre du recul sur la mise en place de leur design system.

Parce qu'un bon design system n'est pas celui qui impressionne par sa perfection. C'est celui qui sert le quotidien de vos équipes.

La partie 2 détaille les idées reçues 4 à 6, la synthèse et ce qui reste vrai, même avec l'IA.

Portrait of Lise Cognard

Lise

Cognard

Senior UX Designer