5 erreurs courantes dans la mise en place d’un Design System

Dans le monde du Product Design (et du web en général) le Design System est devenu le sujet Design incontournable. Même s’il est parfois mal utilisé, ce terme a le mérite de mettre sur le devant de la scène une pratique Design plus réfléchie, et au contact des autres corps de métier (la Tech en premier lieu). Mais attention aux raccourcis ou aux pièges dans la mise en place de votre Design System ! On fait le tour de la question à travers 5 points.

Design System par ci, Design System par là.
Ce qu’il faut retenir avant tout, c’est que le Design System est un outil (ou un service) destiné aux équipes de conception d’interfaces produit. L’objectif est de générer : de la cohérence, de la maintenabilité, de la qualité, des pratiques unifiées, ou encore du langage commun entre les équipes Design et Techniques. On pourrait encore citer d’autres attributs, mais ce n’est pas la question aujourd’hui.

Voyons plutôt les erreurs les plus courantes observées sur les Design Systems mis en place par les équipes.

Le Design System trop « vendu »

« Nous, on a un Design System complet et super efficace ».

Génial. Et après analyse, on se rend compte que ce fameux Design System est en fait un fichier Figma. Juste un Figma.

En soi, un Figma peut parfois suffire. Mais dans ce cas, appelons les choses par leur véritable nom, et dans ce cas on parlera plutôt de « UI Kit ». Là où un Design System sera composé d’un UI Kit, mais également d’un système de documentation, d’une gouvernance, d’une roadmap, de la traduction Tech du UI Kit, et de beaucoup d’autres choses.

Ne confondons pas les choses : le Design System, c’est « la complète ». Ce n’est pas un UI Kit.

Mais ne dévalorisons pas non plus ce qui existe déjà : parfois, un UI Kit suffit amplement et peut couvrir des besoins complexes. Tout dépend de l’équipe, de son organisation, et de la complexité des produits propulsés par le Design System. Et parfois, un UI Kit solide est d’ailleurs bien plus souhaitable qu’un Design System « commencé partout mais terminé nulle part ».

Le Design System trop complexe

Toutes les équipes Product ont dans leurs références le Design System d’IBM, ou d’autres grandes entreprises. Des Design System complets, sexy, qui font baver, et qui proposent des méthodes de conception complètes.

Sauf que, dans la majorité des cas, on est ni IBM, ni Spotify, ni Apple. Et on a pas non plus des équipes de Design de 30 personnes. Notre écosystème de produits et services est rarement aussi complet et complexe que celui de ces entreprises, mais on continue de répliquer à la lettre leurs principes de conception.

En répliquant simplement (plutôt que de s’inspirer) les principes des Design Systems de ces grandes entreprises, on génère des Design Systems bien trop complexes par rapport à nos usages réels, ou à la maturité de nos équipes sur le sujet.

On arrive donc parfois avec des UI Kits :

• Avec beaucoup trop de tailles de texte possibles (7 suffisent amplement)
• Avec beaucoup trop de possibilités en terme de choix de couleur (pour une couleur donnée, on a sans doute pas besoin de toutes ses nuances 50, 100, 200 etc. ; 5-6 suffisent souvent amplement)
• Avec un choix bien trop large en termes de possibilité d’espacements (idem, 7-8 espacements suffisent amplement)
• Avec des variables définies avec des niveaux d’abstraction trop complexes (« bibliothèque » et « variables décisionnelles » suffisent généralement)
• etc.

Bref, il faut un diplôme de la NASA et 3 jours d’onboarding pour s’en sortir. Non.

Le Design System est censé être un outil au service des équipes. Il doit aussi être un outil de prise de décision (en de fait, proposer un ensemble cadré de possibilités). C’est donc à lui de s’adapter aux équipes et d’évoluer avec elles, plutôt que l’inverse.

Le Design System pensé par les Designers uniquement

Le Design System, parce qu’il comprend le mot « Design », est souvent le territoire des Designers en premier lieu. Puis des autres métiers. C’est une bêtise.

Quand on parle de Design System, on doit penser « Design » à la manière anglo-saxonne : le Design comme « La Conception ».

Faire du Design System le territoire des Designers, c’est couper la collaboration avec les autres équipes, techniques notamment. On investit donc dans un outil qui ne sert rien d’autre que nourrir les égos, et les problèmes de collaboration entre Design et Tech subsistent : très bon calcul…

Le Design System appartient à toute l’équipe produit : Design, Tech, Métier, PO, PM… Il matérialise la conception commune d’un composant par et pour toute l’équipe produit. En réponse à des besoins discutés et arbitrés, des specifications cadrées, et des comportements débattus puis décidés. Ce n’est pas un recueil de composants décidés par une équipe Design, « parce que qu’on connaît le job », et pour lesquels les autres équipes n’auront qu’à se débrouiller pour que ça fonctionne.

Le Design System sans gouvernance ni roadmap

Un UI Kit, c’est bien. Avec de la documentation (dans le Figma ou ailleurs), c’est mieux.
Mais quand on doit piloter plusieurs projets avec un Design System, on doit savoir où est-ce qu’on va, comment, à quel rythme, et en passant par quelles étapes.

C’est là qu’intervient le duo manquant à beaucoup de Design Systems : la gouvernance et la roadmap.

La gouvernance d’un Design System consiste à définir une équipe de pilotage du projet. Idéalement multidisciplinaire (Designers, Développeurs, représentants du métier), cette équipe est notamment en charge de :

• Piloter la roadmap du Design System :
  Quels composants doivent y être intégrés ? Pour quels usages ? Avec quelle priorité ? Dans quel timing ?
• Vérifier que le travail avance correctement :
  Que la roadmap est suivie ; Que les composants soient conformes et testés en condition réelle ; Que la documentation soit présente ; Que la transmission aux équipes techniques soit efficiente…
• Arbitrer :
  Quel composant doit évoluer, dans quel sens et pourquoi ? Quels feedbacks des usagers sont pertinents ?
• Mesurer l’adoption :
  Comment les différentes équipes utilisent-elles ce service ? Qu’en pensent-elles, est-ce qu’il leur permet de gagner du temps ? Que faut-il faire évoluer pour plus de satisfaction et d’utilisation ?

Lorsqu’un Design System manque de gouvernance et d’une Roadmap, il manque d’une colonne vertébrale : il risque donc d’évoluer sans cap, au grés des demandes des uns et des autres, et de se transformer en une espèce de chimère à 3 queues et 2 têtes. Bref, l’inverse total de l’objectif initial.

Le Design System qui oublie l’accessibilité

Si elle n’est pas toujours un sujet d’interface « sexy », l’accessibilité est un sujet qui prend de plus en place de place d’un point de vue règlementaire. Et rien que pour cette raison, vous ne pouvez pas vous permettre de la traiter comme un sujet satellite, « qu’on poussera quand on le devra vraiment ».

Les impacts des critères d’accessibilité sur la conception graphique et technique des interfaces sont réels, et provoquent parfois de véritables problèmes : retours en arrière fonctionnels ; temps de production rallongés ; roadmap non tenue…

Le Design System a ce rôle d’unifier la conception entre le Design et la Tech. Et cette conception commune est également le fruit des contraintes de chaque métier. Plutôt que d’attendre, intégrez donc les contraintes de l’accessibilité à l’ensemble, pour gagner du temps !

Pour cela, vous pouvez soit former un•e référent•e en interne, soit commencer par un audit effectué par un•e partenaire externe. L’objectif est simplement de ne pas laisser ce sujet de côté avant qu’il ne soit trop tard : de se former, d’itérer à son rythme, et d’intégrer l’accessibilité au travail global de qualité des produits.