Je n'ai pas vu toutes les entreprises, tous les contextes, mais j'en ai vu pas mal, j'ai aussi beaucoup échangé avec des collègues qui eux-mêmes ont connus d'autres contextes, d'autres entreprises, et j'ai l'impression qu'on retombe toujours sur les mêmes problèmes autour du "Design System" qui est mauvais et/ou pas à jour et/ou pas pratique et/ou pas adapté à telle app… Sans me prétendre expert en Design System, je pense que beaucoup ne savent pas vraiment ce qu'est un Design System et même mélange le Design System et son implémentation.

Disclaimer : je ne suis pas designer, je suis développeur, j'ai quelques notions approximatives à force de travailler avec des designers et de travailler sur le sujet. Je ne prétends pas avoir la vérité absolue, cet article reflète mon avis, faites vos recherches, creusez le sujet, sortez du cadre de mon article et aussi du cadre mainstream qui vous pousse à créer votre Design System à tout prix pour vous forger votre propre avis !

C'est quoi un Design System ?

Pour commencer, il faut comprendre que quand on parle de "Design System", on parle d'un concept design, pas d'un concept de code. Un Design System c'est un langage visuel qui permet de présenter des informations / actions de manière uniforme dans votre écosystème d'application pour que les utilisateurs aient une expérience claire, que ce soit à travers des briques (souvent appelés "composants") uniforme et clairement identifiable, que des règles de typographies, de couleurs, d'espacements, de layout, etc. Il est le fruit du travail de recherche de designer auprès des utilisateurs et à travers la lecture de document de recherche sur les bonnes pratiques pour que les interfaces soient utilisables facilement. Le Design System reflète aussi l'identité de l'entreprise à travers des couleurs par exemple.

Vous l'avez peut-être senti mais l'idée c'est bien que ce soit universel à l'échelle de l'entreprise. Que ce soit utilisé par 100% des applications de l'entreprise. Même l'application mobile en Flutter ou React Native, même le site Drupal ou Wordpress qui sert de vitrine dans un coin. Partout.

Avoir un Design System c'est donc bien au delà d'un aspect code. C'est bien une brique design qui est maintenu par des designers, dont c'est le travail avec pas mal de contrainte : maintenir le Design System, s'assurer qu'il est complet, s'assurer qu'il est bien utilisé partout, mettre à jour le Design System en fonction des besoins, s'assurer que les composants sont accessibles (au sens utilisable par des personnes avec un handicap, quelque 28% des plus de 15 ans en France), etc.

Le Design System est un produit à part entière, à destination de vos équipes produits pour les aider à produire des applications cohérentes mais qui peut coûter très cher en fonction de la taille de votre structure.

Les composants de votre DS n'ont pas de raison d'être en React !

Je vois une très grande mode dans pas mal d'entreprise de créer un "Design System en composant React avec Storybook"… Je prends React en exemple, mais vous pouvez le remplacer par n'importe quelle librairies / frameworks c'est pareil pour moi…

Pour commencer : non si vous faite une librairie de composant React vous ne faites pas un Design System, vous faite une librairie de composant qui éventuellement est une des implémentations de votre Design System. Et j'ai bien dit UNE DES IMPLÉMENTATIONS. Rien ne vous empêche d'en avoir plusieurs. Rien ne vous oblige à avoir des composants React. Ne faites pas de composant React tout court même…

Pourquoi je n'aime pas les "Design System" en composant React / Angular / Vue / ce que vous voulez :

  • Ce n'est pas future proof : il se passera quoi le jour où le framework va évoluer / mourir ou que vous voudrez tenter un autre outil qui correspond mieux à un besoin (au hasard, votre site vitrine en Wordpress ou votre application mobile Flutter) ?
  • Ce n'est jamais bien fait : créer un bon composant réutilisable, c'est très long, ça demande beaucoup d'effort, c'est coûteux en temps et en énergie, et ça demande une assez grosse expérience pour faire des bons composants et peu de développeurs ont vraiment cette expérience ;
  • Ça n'inclue jamais ce qui n'est pas propre aux composants : c'est rare que les librairies de composant inclus les règles de typographie (ou à nouveau sous forme de composant ce qui rend le truc inutilisable…), de layout, d'espacement, etc. ;
  • Ce n'est jamais maintenu : peu importe où je suis passé, il y avait toujours plusieurs versions de la librairie de composants, souvent incompatible, et j'avais toujours une migration de librairie à faire à un moment ou un autre, et c'est généralement fait par des équipes en parallèle de leur travail sur leur application et pas sur du temps dédié ou même par une équipe dédiée donc c'est toujours bancal ;
  • C'est rarement complet et désynchronisé du Design System défini côté designer·s : comme c'est fait en "best effort" ou "au besoin" en parallèle du travail sur les produits, c'est rare de trouver des librairies complètes, on arrive rarement à un état complet, il manque toujours des composants ou des cas d'usage, ce n'est jamais le même comportement que ce qui est attendu côté Design System ;
  • C'est beaucoup de travail de synchronisation entre les différents utilisateurs : comme il s'agit de librairie qui définissent des composants partagés entre plusieurs équipes, chaque changement implique un gros travail de synchronisation pour que la librairie soit mise à jour dans les différents projets, que les nouveaux composants soient en compte, etc. le travail est assez énorme et fatiguant, je trouve que ça ne fonctionne jamais correctement ;
  • C'est en général une grosse perte de temps sur les développements des produits : les équipes de développement produits passent un temps fou à attendre / modifier / faire des remontés sur les Design System, voir on entendra des choses comme "on ne peut pas développer la fonctionnalité X car on a pas le composant du Design System" ;

Pour certains points, vous pouvez me rétorquer qu'avoir une bonne documentation peut suffire et que Storybook aide à le faire. Oui mais pour moi non. La documentation n'est jamais complète. La documentation n'est de toutes façons jamais lu par les consommateurs. La documentation est encore un nouveau produit à mon sens qu'il faut maintenir et que personne n'a envie de maintenir en général. En tant que développeur front j'ai presque toujours été obligé de tester les composant en comparant le rendu chez moi et le code source pour code desdits composants pour les utiliser… Storybook n'est pas forcément un mauvais outil mais c'est un outil qui doit être maitrisé, demande un apprentissage à part entière et demande là aussi un effort de maintenance (un effort qui sera en général insuffisant, en général l'effort n'étant déjà pas mis à maintenir les produits à jour, les outils de documentation des produits qui ne sont pas vu comme des produits je n'y crois pas…).

HTML et CSS sont vos amis !

Je critique, je critique, mais je propose quoi ?

Le cas que j'ai trouvé le plus efficace c'est les contextes sans cette couche de librairie de composant. Je trouve beaucoup plus efficace de diffuser une feuille de style, avec éventuellement quelques web component pour certains cas particuliers difficile à gérer uniquement en CSS. Cette feuille de style peut être construite depuis rien ou comme un thème / une surcouche à une librairie CSS existante comme Bootstrap ou même des librairies plus légère comme PicoCSS.

Pourquoi ça fonctionne bien ?

  • On ne dépend de rien à part le navigateur (HTML et CSS sont natifs) ;
  • Chaque équipe l'utilisera librement avec son framework que ce soit JavaScript comme React ou Angular ou même des CMS comme Wordpress et Drupal ;
  • La mise à jour est transparente : il suffit de mettre à jour le style diffusé et il est directement pris en compte partout (même si on a un risque de casser certaines applications qui respecterait pas les guidelines ou si on introduit une erreur) ;
  • HTML et CSS sont stables dans le temps donc vous n'avez pas à vous inquiéter de breaking change qui vous bloquerait ;

Par contre j'avoue que ça ne prend pas en compte le mobile si vous avez une application native (si c'est du web mobile c'est bon par contre). Là je n'ai pas de solution, et je n'ai pas d'expérience ne travaillant pas dans des contextes avec des applications mobiles natives dans mon périmètre d'équipe. Mais j'imagine qu'on doit pouvoir définir des fichiers importables un minimum uniforme pour le mobile à travers plusieurs applications et plusieurs technologies.

Cette solution ne va pas non plus régler le problème de la documentation, au contraire car chacun étant plus libre d'utiliser le code, il faut le documenter plus pour s'assurer que ce soit correctement utilisé. Mais là la configuration de la documentation peut être faite très facilement comme on ne dépend d'aucun framework. Par contre c'est aussi là que s'appuyer sur un framework CSS existant peut-être un facilitant, car ces frameworks sont souvent largement bien documentés, donc il suffira de documenter les spécificités plutôt que 100% de tout ce qui est mis à disposition. Peut-être aussi mettre en place des outils / process pour valider la bonne utilisation dans les différents produits.

L'utilisation au maximum de CSS simple vous permet aussi de pousser au maximum du style "classless", des styles directement appliqués sur les balises html, parfois si un attribut d'accessibilité est présent comme le fait beaucoup PicoCSS permettant une prise en compte du style sans même que les développeurs des produits n'ait à s'en occuper pour peu que la sémantique HTML soit respectée.

Alternative à créer son Design System : se baser sur un Design System existant ?

Il existe pas mal de grand groupe qui diffuse en public et/ou open source leur Design System. Pourquoi ne pas simplement utiliser l'un d'eux ?

Quelques exemples (il en existe plein d'autres !) :

  • Carbon Design System d'IBM
  • Material Design de Google
  • Human Interface Guidelines d'Apple
  • Fluent Design System de Microsoft
  • Ant Design de Ant Group
  • Lightning Design System de Salesforce
  • Codex de Wikimedia

Ce sont clairement des Design System qui reflète au moins en partie les identités d'entreprise (c'est un peu moins vrai pour Ant Design qui est pensé pour être réutilisé facilement et pouvoir appliquer des thèmes facilement aussi), mais ce sont des Design System complets, qui ont fait leurs preuves, qui ont des implémentations connues et parfois déjà maitrisé par les développeurs.

Utiliser un Design System déjà existant permet un gain financier et un gain de temps conséquents, designer et développeurs pourront s'appuyer sur le travail qui a été fait par d'autres et se concentrer sur la création de valeur sur votre/vos produit·s.

À l'inverse, prendre le Design System d'une autre entreprise permet moins de refléter votre identité. Mais à mon sens ça peut largement être compensé en ajoutant un thème personnalisé pour correspondre aux couleurs de l'entreprise, et en exploitant bien le Design System pour mettre en avant ses différences.

Alternative à créer son Design System : prendre directement un framework CSS existant ?

Si utiliser le Design System d'une autre entreprise peut être un frein à représenter une marque forte, se baser sur un framework CSS peut être un bon compromis : tout est déjà implémenté en termes de technique, il suffit d'ajouter sa patte (thème, spécificité) par-dessus pour se l'approprier.

Un framework CSS a l'avantage de proposer en général un bon socle de travail, il est maintenu par un groupe de personnes hors de l'entreprise qui potentiellement des compétences qu'on n'a pas, il est battle-tested (testé au travers d'application venant de divers contextes), si on a besoin de correction sur ces frameworks il est possible de contribuer au projet.

Ces frameworks ont aussi l'avantage de généralement imposer peu de chose sur la manière de construire les pages donc c'est possible de créer ses propres règles à partir des briques fournies.

Quelques exemples :

  • Bootstrap
  • PicoCSS
  • BeerCSS

Si je pense tout le monde connait Boostrap et l'a même surement utilisé tellement il était répandu en version 2 et 3 (même s'il continue d'évoluer et se moderniser pour être toujours un très bon framework CSS avec sa version 5), peu connaissent PicoCSS et BeerCSS. BeerCSS est une implémentation du Material Design avec quelques ajustements pour avoir un framework CSS plutôt complet et super facile à utiliser. PicoCSS est à l'inverse un framework CSS plutôt minimaliste : on a peu de choses (avec tout de même des choses intéressantes comme le support out-of-the-box des thèmes light/dark automatiquement pris en compte via les préférences du navigateur) mais ce qui est proposé est bien construit, laisse une marge très forte à la personnalisation, très axé sur la sémantique HTML (et les attributs aria pour compléter de sorte à pousser l'accessibilité par design).

J'ai pas mal utilisé PicoCSS ces dernières années et j'en suis très content. J'ai lu des très bons retours sur BeerCSS. Bootstrap est un indémodable à mon sens.

open sourcer son DS ?

Si vous choisissez de quand même partir sur votre propre Design System, il y a pour moi un point qui est clairement capital : la large mise à disposition.

Peu importe la manière dont on construit son Design System et son/ses implémentations, il est pour moi important de tout rendre accessible (au moins en lecture) à 100% des personnes de l'entreprise, de communiquer autour de comment accéder au Design System, et de faire en sorte que chacun puisse utiliser et comprendre le Design System. De préférence c'est aussi idéal si un canal permettant de donner un avis est présent pour à minima avoir la possibilité de demander des précisions sur un cas d'usage et/ou remonter un problème. Le niveau au-dessus serait de pratiquer l'Inner Source (open source mais à l'échelle de l'entreprise), permettant à chacun de proposer des améliorations, même s'il faut une équipe design solide pour évaluer les améliorations proposées pour que le Design System ne parte dans tous les sens, c'est un vecteur d'adoption, car l'ensemble de l'entreprise peut plus facilement se sentir impliqué dans ce produit.

Est-ce qu'il faut rendre son Design System open source ? Non. Dans la très vaste majorité des cas, ça ne fait absolument pas sens.

Rendre son Design System open source, ou même simplement public, c'est l'exposer à des usages non contrôlés, des remontés qui ne vont pas dans le sens de l'entreprise, ouvrir une porte facilité vers la réplication de ses propres outils. Maintenant c'est parfois ce qu'on souhaite. Prenez le cas du Material Design de Google ou du Human Interface Guidelines d'Apple, ils sont là pour accompagner les développeurs d'applications à suivre certains patterns pour uniformiser l'expérience utilisateur sur Android et iOS (iPhone et iPad) principalement, sans ces Design System on aurait des expériences beaucoup plus approximatives quand on utilise des applications venant d'éditeurs tiers. Je peux aussi prendre le cas du Design System de l'État français (qui au passage est implémenté essentiellement sous la forme de HTML/CSS), il est à destination principe des différents outils publics venant de l'État français, c'est à dire plusieurs ministères, des DSI différentes, des besoins de design similaires qui étaient recréés dans chaque DSI sans plus-value. Rendre ce Design System public a permis une diffusion facilité à tous les ministères et une mutualisation des ressources (en tout cas, j'imagine).

Note : pour le Design System de l'État, certains considèrent que c'est aussi une manière "accidentelle" de facilité la création de site de phishing. Pour le coup je ne suis pas d'accord, les groupes de personnes qui font des sites de phishing n'ont pas attendu ce Design System pour créer des clones de quelques pages des sites de l'État pour voler des données. N'oubliez pas que quand vous êtes sur un site, vous pouvez faire Ctrl+s pour sauvegarder la page courante, ses styles, ses scripts, etc. et avoir juste à le bidouiller avant de le remettre en ligne pour faire du phishing (soit beaucoup moins d'effort qu'utiliser un Design System).

Pour moi, à part pour les rares cas où ça fait sens, rendre son Design System public / open source c'est simplement une manière de flatter des égos (designer·s, développeur·s ou même direction). Ça ne répond à aucun besoin.

Conclusion

Comme je le disais en introduction : je ne suis pas expert en Design System, en création de librairie de composant ou même en design, j'ai acquis des concepts au fil du temps, j'ai une expérience qui fait que je me suis forgé un avis. Vous avez parfaitement le droit de ne pas avoir le même avis que moi.

Pour moi un indice fort qui montre un problème dans un Design System c'est quand les développeurs ne veulent pas partir dessus pour les outils internes. Un Design System est censé être la boite à outil qu'ils utilisent au quotidien, qu'ils maîtrisent, qui leur fait gagner du temps, un refus d'utilisation est pour moi une démonstration que quelque chose ne va pas. De la même façon que des produits contenant beaucoup de style personnalisé : un Design System bien fait est censé proposer la très grande majorité des cas d'usage out-of-the-box à mon avis.

Mon but premier avec cet article est de vous pousser à réfléchir sur votre besoin réel autour du Design System et tout ce qui gravite autour, ainsi qu'au coût impliqué par la création d'un Design System, vous avez parfaitement le droit d'avoir une autre vision, et je suis complètement ouvert à la discussion sur le sujet !

Sources :

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Créez une illustration dynamique et expressive montrant des développeurs et développeuses en fuite devant une représentation complexe d'un design system. Voici les éléments clés à inclure :

  1. Personnages :

    • Quatre développeurs et développeuses, deux hommes et deux femmes, avec des expressions de stress ou de frustration. Ils courent ou s'éloignent rapidement d'une scène où se trouve le design system.
    • Utilisez des couleurs vives et des silhouettes dynamiques pour rendre les personnages plus expressifs.

  2. Design System :

    • Montrez une version stylisée et souvent complexe d'un design system, avec des composants UI (boutons, cartes, formulaires) alignés de manière désordonnée ou avec des incohérences visuelles.
    • Utilisez des couleurs sombres ou monotones pour représenter un design system qui semble lourd et difficile à utiliser.

  3. Contexte :

    • Placez la scène dans un bureau ou un espace de travail informel, avec des écrans d'ordinateur, des claviers, et des souris pour ajouter de la réalité.
    • Ajoutez des éléments comme des tasses de café, des stylos, ou des posters techniques pour enrichir l'atmosphère.

  4. Action et Dynamisme :

    • Montrez les développeurs en mouvement, en train de courir ou de s'éloigner rapidement. Utilisez des lignes fluides pour représenter leur trajectoire.
    • Ajoutez des expressions faciales et des gestes pour montrer leur frustration ou leur désespoir.

Style et Conseils :

  • Utilisez un style visuel qui combine réalisme et expression pour rendre la scène dynamique et expressive.
  • Choisissez une palette de couleurs contrastée pour mettre en avant les émotions des personnages et la complexité du design system.