Accueil » Revue de presse » ** Comment faire un design system en 10 étapes : le retour d’expérience de la MAIF

** Comment faire un design system en 10 étapes : le retour d’expérience de la MAIF

Goulven Baron, UX designer à la MAIF, fut au cœur de l’équipe chargée de la conception d’un design system. Lors du BlendWebMix à Lyon, il a livré un retour d’expérience complet et utile pour ceux qui désirent mettre en place un design system dans leur entreprise.

Commençons par définir ce qu’est et à quoi sert un design system. Il s’agit d’un référentiel, qui regroupe des éléments d’interface et leurs règles d’usage, utilisé par de nombreux acteurs dans l’entreprise, voire en dehors (développeurs, intégrateurs, marketeurs, communicants, prestataires…). Un design system a de nombreuses vertues : il unifie l’identité visuelle, permet d’éviter certains impairs, pose des recommandations, informe ses utilisateurs, encourage l’accessibilité et peut avoir pour effet de réduire la fréquence de cette demande reçue trop souvent par les designers : “Tu pourras me renvoyer le bon logo au format PNG ? Tu sais celui que tu m’as envoyé la semaine dernière ? Es-tu sûr que c’est le bon d’ailleurs, il n’a pas changé récemment ?”

 

  … Ceci est un article de Thomas Coëffé pour Blog du modérateur

 

1. Faire un benchmark
Le design system commence à être une thématique bien documentée. En cherchant bien, vous trouverez des retour d’expérience sur la méthodologie, des événements, des conférences, des meetups sur le sujet. De nombreux systèmes sont ouverts, vous pouvez les parcourir et référencer les éléments structurants que vous trouvez intéressants. Vous pouvez d’ailleurs visualiser celui de la MAIF à cette adresse : design.maif.fr. Outre ces recherches et ce benchmark, n’hésitez pas à interviewer directement des professionnels ayant mis en place (ou utilisé) un design system dans leur organisation.

 

2. Constituer une équipe
C’est un point central qui détermine la réussite d’un design system. Un design system aura peu de chance de réussir s’il est porté par une personne seule. À la MAIF, une équipe composée d’une product owner, un UX designer, deux développeurs front-end et deux UI designers a été constituée pour porter ce projet. Cette équipe cœur a ensuite travaillé avec de nombreuses autres teams pour construire le design system. Les membres de l’équipe cœur étaient des référents dans l’entreprise, ils étaient donc en contact permanent avec les autres UX, UI, développeurs front-end… Revers de la médaille : ils étaient sollicités en permanence et donc peu disponibles.

 

3. Étudier l’existant
Lorsqu’on souhaite mettre en place un design system, on peut être confronté à deux situations. En général, “au commencement était le chaos” : aucun référentiel, aucun style guide, aucun document qui référence les composants et les recommandations pour construire des interfaces. À la MAIF, c’était différent. Il existait déjà de nombreux embryons de référentiel, basés sur des technologies variées (Trello, SharePoint, Marvel, InVision…). Pour obtenir cette connaissance, on réalise des interviews en appliquant une méthode stricte permettant de couvrir l’ensemble des utilisateurs ; une problématique complexe pour la MAIF qui est composée de nombreuses entités, elles-mêmes constituées de métiers variés.

Si c’était à refaire, Goulven Baron passerait plus de temps sur cette phase de la conception. Le devoir d’inventaire est important, il permet de proposer un outil et un contenu plus en phase avec la réalité et le besoin des utilisateurs. C’est un passage obligatoire mais c’est parfois complexe : on peut se heurter à une dette graphique importante et le temps disponible n’est pas toujours suffisant pour référencer parfaitement tout l’existant.

 

4. Comprendre les craintes et les attentes
La récolte des attentes est une étape importante permettant de guider le projet. À la MAIF, les futurs utilisateurs ont évoqué l’accessibilité du design system sur une simple URL, ils souhaitaient que des explications soient données pour chaque composant (usage, droits…) et surtout que les données soient à jour. Globalement, le design system devait répondre à ces problématiques : ne pas refaire l’existant continuellement et être assuré que la ressource est bien valide. Des craintes ont également été exprimées : “vous allez rajouter une couche de complexité à des process déjà très compliqués” ; “si vous réussissez votre projet, mon métier ne servira plus à rien, tout le monde pourra assembler des pages comme s’il jouait aux LEGO, je ne vois pas pourquoi on devrait continuer de faire des maquettes”. Ces peurs nécessitent des réponses, elles ne doivent pas être ignorées.

 

5. Définir le contenu et l’arborescence
C’est une phase importante du projet. L’idée est de rencontrer les équipes, dans leur plus grande diversité, pour comprendre quels éléments doivent être référencés. On peut travailler avec des tris de cartes, commencer à constituer des catégories et dessiner des arborescences. Trouver une cohérence globale, acceptée par l’ensemble des services, n’est pas une mince affaire – mais n’oubliez pas non plus que le mieux est l’ennemi du bien. Le choix de la MAIF a été de séparer son design system en trois parties : l’identité de marque, les interfaces publiques et les interfaces collaborateurs.

 

6. Choisir son support technique
Autre moment important de la constitution d’un design system : le choix technique. C’est un éternel débat : doit-on développer from scratch ou utiliser un CMS du marché ? Les équipes de la MAIF ont dessiné une matrice des besoins et évalué la réponse apportée par 3 outils, avant de porter leur dévolu sur Frontify.

 

7. Obtenir un premier feedback des utilisateurs
Pour mettre en place une version beta, de nombreux copier coller en provenance des embryons de design systems existant ont été réalisés, sans que ces textes soient challengés dans un premier temps. Cette étape permet de valider (ou non) le choix technologique qui vient d’être effectué. On s’adresse à une population variée (services, métiers) et on fait aussi participer l’équipe cœur qui commence à bien connaître son sujet. Les retours ont été nombreux : interface trop austère, arborescence pas toujours adaptée, recherche peu intuitive… Des problématiques liées à l’hébergement des données aux États-Unis ont été soulevées et des limites techniques ont pu être repérées (sur l’arborescence notamment). Les utilisateurs ont en revanche apprécié les Do et Don’t des composants et pu exprimer leurs désirs non-assouvis.

 

8. Changer si nécessaire
Ces retours ont poussé l’équipe produit à réaliser un pivot technique. Frontify impliquait des contraintes trop fortes, il n’était pas possible de réaliser un développement from scratch (temps, budget), le choix s’est donc porté sur Jahia – un CMS très populaire dans le secteur de la bancassurance. La MAIF avait les compétences métiers nécessaires pour itérer sur cette base bien maîtrisée. Des iframes ont simplement été utilisés pour exposer les composants et leur code.

 

9. Déployer son design system
La cas de la MAIF est particulier, car la mise à disposition du design system était associée à une refonte de la marque réalisée en interne sous non-disclosure agreement. La mise en production du design system a donc été réalisée en pleine nuit, en parallèle du déploiement des nouveaux éléments de marque, ce qui a sans doute parasité le design system. Les collaborateurs ont pu être perturbés par ces deux nouveautés, la nouvelle marque qu’ils découvraient et l’accès à un nouvel outil pour accéder aux composants.

Les grandes catégories définies aux prémices du projet ont été conservées (identité de marque, interfaces publiques, interfaces collaborateurs), elles ont été enrichies avec un kit de démarrage, des principes de design et des moyens de contact. Ensuite, les utilisateurs peuvent accéder à divers composants et leurs usages : logotype, polices, web, mobile, marquage, filiales, couleurs, vidéo, affichages, partenariats, iconographie, social media, son, impression… Certains types d’éléments sont peut-être spécifique à la MAIF, mais nombre d’entre eux peuvent être utilisés dans la plupart des design systems.

 

10. Obtenir le feedback des utilisateurs
L’outil est accessible, les utilisateurs le découvrent, l’utilisent : les premiers feedbacks sont récoltés par l’équipe de conception. Le conseil de Goulven Baron est le suivant : ouvrir au maximum les chemins de communication. Dans une grande organisation, ils sont divers et c’est normal, limiter les canaux est contre-productif. C’est à l’équipe de centraliser les retours, pas aux utilisateurs d’être contraints d’utiliser un canal défini par l’équipe. Les utilisateurs ont ainsi pu utiliser Slack, Microsoft Teams, Yammer, une adresse email dédiée, CRISP (un outil de feedback), le téléphone des membres de l’équipe et bien évidemment échanger directement avec eux à la machine à café.

Ces feedbacks ont abouti sur quelques bonnes surprises, notamment l’uniformisation des signatures d’emails grâce au composant proposé et bien identifié dans le design system ; mais les membres de l’équipe technique se sont mis à faire du SAV pour bien paramétrer les signatures sur Outlook… D’autres points plus négatifs ont été soulevés, notamment la faible valeur ajoutée pour la conception web. Des workflows existaient déjà, ils n’étaient pas parfaits mais ils avaient le mérite d’exister et leurs utilisateurs continuent à les utiliser. Dans ce cas, il ne faut pas tenter de contraindre les utilisateurs en tentant de couper les systèmes existants et fonctionnels : essayer plutôt d’enrichir le design system pour augmenter son intérêt.

Autre remarque des utilisateurs : les composants sont de moins en moins décrits à mesure qu’on descend dans l’arborescence. C’est un chantier gigantesque mais important ; dans une démarche agile, on comprendra que l’équipe ait préféré déployer un outil incomplet plutôt que de passer 2 ans à définir en détail chaque composant. Ce travail permet d’expliciter clairement l’arbre de décision : doit-on utiliser un formulaire ou du conversationnel ? Il y a des règles qui permettent de faire ces choix, elles doivent être explicitées pour renforcer l’autonomie des utilisateurs. Enfin, Goulven rappelle que le design system peut être discuté, ce n’est pas un canal de validation. L’idée n’est pas de contraindre mais d’expliquer. C’est comme avec les enfants : pour qu’ils ne sautent pas par la fenêtre, vous pouvez mettre des barreaux ou leur expliquer pourquoi il n’est pas souhaitable qu’ils sautent par la fenêtre. À vous de choisir l’option qui vous paraît la plus adaptée ; mais ayez à l’esprit que lorsqu’un utilisateur est contraint d’une manière qui semble arbitraire, il aura toujours l’envie et les moyens de contourner les règles définies.

 

 

Cet article a été sélectionné par designer.s dans le cadre de sa veille éditoriale et intégré à sa revue de presse européenne francophone !

Pertinence et intérêt de l’article selon designer.s :

***** Exceptionnel, pépite
**** Très intéressant et/ou focus
*** Intéressant
** Faible, approximatif : Opaque, manque « clairement de clarté », et d’exemples concrets, dommage !
* Mauvais, très critiquable
(i) . Informatif