Depuis quelques années, le Design System est perçu comme “l’élu” qui va (enfin) apporter cohésion et organisation au sein des projets et des équipes. Bien que, comme l’Agilité, il devient un concept bankable sur un CV de développeur·euses et designeur·euse, qu’implique t-il vraiment ? Quels sont ses impacts sur les équipes et comment savoir si il est pertinent ou non pour un projet ?

Les principes d’un Design System

Le Design System est un produit au service des projets digitaux d’une entreprise. Il a 5 principes majeurs :

• Vivant, qui évolue et s’améliore avec le temps en fonction de l’identité de l’entreprise
• Agnostique, qui est compatible avec l’ensemble des principales technologies front-end
• Atomique, qui est construit sur le principe de l’Atomic Design
• Universel, qui reprends les standards universels d’utilisation (actions, lexique, internationalisation)
• Inclusif, qui intègre les grandes règles d’utilisabilité et d’accessibilité

Il permet aussi une meilleure collaboration et co-conception entre équipe de développement et de design.

Moi, développeur·euse, qu’est-ce que ça m’apporte ?

Un Design System réussi est une documentation claire et explicite sur la manière dont les composants vivent dans une application. C’est un contrat d’implémentation qui décrit leur état et intention afin de garantir la compréhension d’utilisation, d’implémentation et par conséquent, d’accélérer les développements. C’est également un outil qui permet d’avoir et de réutiliser un ensemble de composants ayant un comportement unique. Cette réutilisation permet d’éviter de développer ou re-développer des composants. Cela garantit de facto une qualité de code dû à la mise en place de processus de validation définis en amont du projet.

Moi, designeur·euse, qu’est-ce que ça m’apporte ?

Un Design System réussi reprend l’ensemble des principes de la marque, que ce soit l’atmosphère, l’ambiance, le message, la direction artistique mais aussi l’ensemble des éléments déclinables sur des outils et interfaces numériques. En bonus, il est possible d’y ajouter les éléments Print issus de la charte initiale.

Pour un·e designeur·euse, le Design System devient un référentiel toujours à jour dans lequel les principes de design et d’interface seront proposés avec une chose inédite : une documentation associée, voir même un versionning applicatif. Le Design System permet aussi de concevoir de manière user centric et de tester rapidement des bribes d’interface. Le composant peut être testé auprès d’utilisateurs·trices unitairement, dans une ou plusieurs pages.

Moi, PO et PM, qu’est-ce que ça m’apporte ?

Le Design System est un outil aidant à la production. Il permet vis-à-vis d’un·e PO :

• d’appréhender les composants embarqués dans une user story
• de concevoir des fonctionnalités user centric
• d’augmenter la vélocité de ses équipes (et oui car tout composant conçu et développé n’est plus à refaire et son temps d’intégration s’en voit réduit)

Moi, client·e d’un produit, qu’est ce que ça m’apporte ?

Pour un·e client·e, le Design System permet de profiter de patterns identiques ; c’est à dire des éléments de navigation, d’interactions identiques sur l’ensemble d’un outil ou application. Chaque composant n’ayant qu’un seul et même comportement répondant à un objectif précis.

Ai-je réellement besoin d’un Design System ?

Voilà une question essentielle à se poser. Tous les projets ne nécessitent pas un Design System. C’est un projet qui demande de l’implication et du temps aux équipes. Une acculturation à plusieurs équipes ou corps de métier différents est également primordiale à sa mise en place.

L’intérêt d’un Design System s’avère assez limité sur une petite application ou un produit simple. Un simple Kit UI et une librairie de composants peuvent suffire.

Son utilité peut se mesurer :

• au nombre de développeur·euses devant utiliser des composants similaires
• au besoin de scalabilité des interfaces ou des composants sur un ou plusieurs projets
• aux différents corps de métier intervenants sur les applications

Et si je ne sais pas ? Mieux vaut commencer par étape et utiliser un kit UI, un style guide dans Zeplin, Invision, ou autres outils puis y intégrer une documentation pas à pas. Ce sont ces éléments de documentation (conception, utilisation, versionning, etc.) qui feront émerger un Design System complet correspondant aux besoins des équipes.

Quels outils utiliser ?

Le Design System étant un projet en lui même, il convient de s’équiper avant de l’attaquer :

• un outil de suivi des tâches (Trello, Jira, Youtrack, etc.)
• un outil de prototyping (Sketch, Adobe XD, Figma, etc.), généralement le favori de votre designeur·euse
• un IDE, généralement le favori de votre développeur·euse
• un outil de versionning de source
• un Design System Manager ou DSM (Atom, Zeroheight, un outil from scratch, etc.)

Pourquoi un DSM ?

Car il formalise l’effervescence et l’énergie mises dans la conception tant du côté UX que du côté développement. Il est LA référence, LA source de vérité absolue. Son choix n’est pas aisé car il doit faire consensus entre deux univers d’outils différents.

source : CommitStrip

Le DSM (Design System Manager) est un outil mis en place pour les teams de design et développement qui permet des interactions et une collaboration plus poussée qu’un simple Zeplin ou Invision.

Des choses à prendre en compte au préalable ?

Oui. Chaque UX, UI ou développeur·euse a des préférences en termes d’outillage. Pour choisir le plus adapté aux besoins de l’équipe il est important de :

• lister les intervenant·es (UX, UI, dev, communication, etc.)
• lister les besoins des intervenant·es (bibliothèque de composants, documentation, gestion des extraits de code, etc.)
• mettre en lumière les pain points liés à l’environnement technique
• cerner l’appétence technique des contributeur·trices
• évaluer le budget
• identifier la méthodologie de travail pour y extraire les éléments de planning et de gestion de ressources

Les exemples de DSM sont multiples. Il est possible d’utiliser un outil complet ou plusieurs outils complémentaires ; chaque solution répondant aux contraintes et souhaits d’outillage des équipes.

Comment faire mon choix ?

Avec un bon vieux benchmark. C’est ici que la liste établie au préalable va s’avérer indispensable. Prenez l’ensemble de vos critères et comparez les sans sous estimer l’importance des contraintes IT et budgétaires qui peuvent fortement orienter l’utilisation d’un outil ou d’un autre. Il est important de noter que le temps alloué par une équipe de développement à la mise en place et la maintenance d’un DSM.
De plus, le contexte politique peut être, en fonction du client, un facteur de risque à prendre en compte. Il peut être indispensable en fonction de l’impact politique et l’image de marque du projet de prévoir un ou plusieurs sponsors et les validations juridiques préalables.

source : Hike One

Des idées reçues ?

Le Design System souffre encore d’une méconnaissance au niveau du top management tout comme au niveau des équipes techniques, autant UX, UI que de développement.

Idée reçue #1 : ce n’est qu’une librairie de composants ou un kit UI

C’est bien plus que cela. C’est une occasion de fédérer ! L’investissement des différentes parties prenantes durant ces phases de réalisation renforcent l’esprit de collaboration en partageant par exemple des pratiques, méthodes et/ou outils de travail (versionning des sources, versionning sémantique, nommage, etc.). Le DSM centralise et sanctuarise alors ce travail.

Idée reçue #2 : l’utilisation du Design System sera un plus pour les équipes

Oui, à condition d’avoir correctement préparer le terrain. Il faut que les équipes aient une connaissance plus que superficiel de ce type de démarche pour réussir cette transformation. Même si un effort est fait sur la qualité de la documentation, l’accompagnement reste primordial pour garantir un accueil enthousiaste à cet outil.

Idée reçue #3 : la maintenance du Design System est à la charge du Studio/équipe UX

Non ! Cette documentation a pour but de faire vivre l’identité visuelle d’un ensemble d’applications, tant à travers son expression visuelle que son implémentation technique. Vous retrouverez dans la littérature actuelle la phrase-type « c’est un référentiel UX/UI ». Oui, mais la maintenance du Design System doit être garantie par la participation active de toutes les parties prenantes : PO/PM, UX/UI, développeur·euse et équipe de communication.

Idée reçue #4 : ça ne prendra pas de temps

Faux. Un Design System est un projet à part entière qui demande du temps et de l’investissement. C’est un projet qui mobilise PM, PO, Lead tech, UX, UI, marketing/communication et souvent un Scrum. C’est un projet qui se doit d’avoir ses propres US afin que le temps passé à concevoir, designer, développer un composant ne soit pas du temps fantôme.

Idée reçue #5 : pas besoin de faire de l’agilité, le designer·euse design et le développeur·euse développe

Faux. Ce projet se prête particulièrement à l’Agile et au Lean. Dans une logique de collaboration inter-équipe, ce projet est aussi l’occasion d’éprouver d’autres méthodologies de travail notamment dans de grands groupes un peu frileux de ne pas avoir de deadline.

Le mot de la fin

La mise en place d’un Design System est un sujet hautement stratégique à la fois pour un PM, client·e final·e mais aussi pour toutes les équipes techniques intervenant sur un projet. Il faut en effet comprendre les enjeux sous-jacents de la mise en place d’un tel outil avant de se lancer dans cette formidable aventure : temps, travail collaboratif, itération, tests utilisateurs, mise en place de nouvelles procédures et principes de travail.

Pour aller plus loin

Design System, Alla Kholmatova, chez Smashing Magazine
Comment concevoir un système de composants en atomic design ? Audrey Hacq, Medium
Tout savoir sur les Systèmes de Design ? Audrey Hacq, Medium
Articles de Nathan Curtis, Medium

Maëva Dosimont

Mahamoud Saïd Omar