Capsule Design #4 - Vega, notre outil design pour mieux collaborer

Pour cette nouvelle Capsule Design, nous vous proposons un retour d’expérience sur la création d’un outil interne conçu pour optimiser la collaboration entre designers et développeur.euses AKA Vega !

Arnaud et Matthis, à l’origine du projet, échangent avec Adeline sur les challenges et les bénéfices qu’ils ont observé après un an de mise en place au sein de l’agence.

Bonne écoute à tous et à toutes,

Les Designers de l’Agence LunaWeb.

La transcription

Adeline : Bonjour à toutes et à tous, bienvenue dans ce nouvel épisode de Salut les Designers, le podcast de l’agence LunaWeb. Aujourd’hui, avec notre format court intitulé Capsule Design, nous irons à la découverte des différentes thématiques du design UX en compagnie de membres de l’agence.

Je reçois Arnaud Caudal UI et UX designer et Matthis Le Texier, développeur front-end à l’agence. 

Salut les gars, comment allez vous ?

Matthis : Eh bien, plutôt pas mal. Merci pour l’invitation !

Arnaud : Ça va bien, Merci.

Adeline : Pouvez-vous vous présenter et nous expliquer votre mission à l’agence en quelques mots ?

Arnaud : Je peux commencer, je m’appelle Arnaud Caudal, je suis designer depuis plus de dix ans. J’ai fait un peu de tout dans ma carrière en passant du print au motion design et je me suis très vite spécialisé dans le design d’interaction. Là, je suis à l’agence depuis bientôt deux ans et mon rôle avec les autres collègues designers, c’est de concevoir des interfaces, des concepts d’interactions et de navigation qui sont à la hauteur des besoins utilisateurs finaux et bien sûr, des objectifs de nos clients.

En tant que designer, c’est très important pour moi d’impliquer le plus tôt possible les développeurs dans la conception de l’interface.

Pour cela, je travaille en collaboration avec toute l’équipe projet et c’est hyper important pour moi d’impliquer le plus tôt possible les développeurs dans la conception d’interface. Après, je parle des développeurs, mais il y a aussi tout un ensemble de métiers comme les UX researcher qu’il est hyper important d’avoir sur ses projets.

Matthis : Et bien moi c’est Matthis Le Texier, je suis développeur depuis un peu plus de dix ans. Notamment, j’ai commencé en tant que développeur web et là, ça fait quatre ans et demi que j’occupe le poste de développeur front-end chez LunaWeb.

Mon rôle est de développer nos interfaces numériques avec tous les métiers de l’agence, principalement les designers et développeurs back-end.

Mon rôle, c’est principalement de développer des interfaces numériques, que ce soit pour des applications, des sites web, etc. Et je fais ça de paire avec un peu tous les métiers de l’agence et principalement avec mes comparses, designers et développeurs back-end.

Adeline : Merci à tous les deux. Aujourd’hui, vous allez nous parler d’un projet interne à l’agence qui s’appelle Vega. Il s’agit d’un starter kit documenté qui est censé bénéficier à tous les métiers de l’agence. Pouvez-vous nous en dire un peu plus sur ce projet ?

Matthis : Tout à fait ! Vega, c’est donc un projet qui est né il y a à peu près un an, qui se veut ouvert et utile à tous les membres de l’équipe au sein de l’agence. C’est une solution notamment orientée en fait « interface utilisateur » dont l’idée est de communier les connaissances et les pratiques au sein de l’équipe autour de tout ce qui est vraiment conception et développement d’interface. Et aujourd’hui, dans l’état actuel, ça s’apparente à une librairie de composants associés à une documentation

Vega, c’est une solution orientée « interface utilisateur » née il y a un an et qui se veut ouverte à tous les membres de l’agence. L’idée est de communier nos connaissances et nos pratiques au sein de l’équipe, autour de tout ce qui est conception et développement d’interface.

Arnaud : Pour en rajouter un peu sur l’historique du projet, il faut savoir qu’à la base Matthis et moi nous sommes amis de longue date, nous nous sommes retrouvé dans cette agence, je l’ai rejoint par la suite et en fait, on avait déjà envie de créer quelque chose, professionnellement parlant. Là c’était un peu l’occasion. Pour ma part, j’avais déjà travaillé sur des design system et j’avais pris l’habitude de préparer un gabarit Figma relativement ouvert pour pas se brider créativement parlant, mais pour permettre de ne pas réinventer la roue sur certains composants et graphiques.

Et pour en revenir au projet qui nous intéresse, on peut dire qu’il est composé de plusieurs modules qui vont se découper selon les besoins les plus urgents de l’agence. Aujourd’hui, on a mis un premier module en place. L’idée, c’est que ce projet soit vraiment en amélioration continue.

Au-delà du besoin, Matthis et moi sommes amis de longue date et on avait envie de créer quelque chose, professionnellement parlant.

Après avoir passé pas mal de temps sur le premier module au niveau du process, on s’est rendu compte qu’on avait vraiment envie de s’inspirer du design thinking. Aujourd’hui, on est en train de poser les bases pour que  toute l’équipe puisse contribuer au projet et on a encore du travail.

Adeline : Il y a beaucoup de notions clés sur lesquelles on reviendra dans le podcast. Mais avant de rentrer dans le détail, pouvez-vous nous donner les grands objectifs de ce projet ?

Arnaud : Le premier, c’est vraiment de favoriser la collaboration entre tous les acteurs d’un projet, surtout, plus précisément d’impliquer vraiment la technique dans la conception, de rendre plus transparent les problématiques entre ces deux métiers et surtout de rassembler en fait deux domaines de compétences.

Le premier objectif est vraiment de favoriser la collaboration entre tous les acteurs d’un projet, plus précisément d’impliquer vraiment les profils techniques dans la conception.

Matthis : On a aussi un deuxième objectif, qui est quand même assez majeur, celui d’être plus efficace et de gagner du temps. Il faut savoir que nous sommes une agence, du coup on a la contrainte d’avoir plusieurs projets qui sont souvent en parallèle et on enchaîne donc les projets et on fait, on voit qu’on se répète quand même assez souvent dans ce que l’on produit.

Matthis : Même si la solution, en fait, est toujours adaptée à la problématique soumise par le client et à son identité numérique, etc, on a quand même le souhait de gagner du temps sur, notamment, la conception et la production d’éléments d’interface qui peuvent être assez bateaux ou assez répétitifs de projet en projet. Par exemple un fil d’Ariane, c’est généralement quelque chose que l’on va répéter, on va reprendre un peu les mêmes recettes, même si potentiellement, on en a deux ou trois différentes.

Un deuxième objectif, qui est quand même assez majeur, c’est celui d’être plus efficace et de gagner du temps.

Et du coup, ça fait gagner du temps, autant en design qu’en développement. Et avec ce gain de temps, l’idée est de créer de la valeur ajoutée sur ce qui le mérite. C’est-à-dire investir plus sur les objectifs principaux des problématiques clients, leur fonctionnalités clés qui vont généralement les aider à développer leur business.

L’idée de ce gain de temps, c’est de créer de la valeur ajoutée sur ce qui le mérite.

Adeline : Donc, on retient deux grands objectifs principaux. Pouvez-vous nous expliquer de quelle manière vous avez répondu à ces objectifs ?

Arnaud : Premièrement, on a vraiment travaillé tous les deux main dans la main, si j’ose dire. Première étape, c’était de faire un atelier pour définir les besoins de l’agence et en définir aussi les objectifs qui allaient nous guider.

Ensuite, on a brainstormé avec Matthis sur le premier module sur lequel on souhaitait démarrer. Nous avons choisi de travailler sur les formulaires car ça nous semblait hyper complet comme premier sujet. On n’avait pas mal de challenges importants à traiter, comme par exemple l’accessibilité et d’un point de vue conception, nous avons également pu apprendre à gérer un très grand nombre de composants et on sait que c’est quelque chose d’assez chronophage à faire en design UI.

Nous avons choisi de travailler sur les formulaires dans un premier module car en plus des enjeux d’accessibilité, nous avons pu apprendre à gérer un très grand nombre de composants et de variantes.

Et ça nous a permis de se rendre compte, lors de nos recherches, de l’importance de la documentation.

Matthis : Oui tout à fait, on avait déjà des recherches, préalablement sur les formulaires, par différents membres de l’équipe, mais ces recherches restaient éparpillées entre différents canaux de l’agence. Et du coup, c’était assez difficile à retrouver. Donc l’idée, c’était un peu de centraliser tout ça.

Donc en plus de cette documentation de base qu’on avait déjà, avec Arnaud, on a pas mal étayé avec des recherches un peu plus poussées autour de certains sujets et notamment on a été pas mal scruter les différents design system ou études UX disponibles un peu dans la nature. Le but était en fait de prendre en compte aussi les axes majeurs chers à l’agence.

En plus de la documentation de base qui existait déjà, nous avons étayé nos connaissances avec des recherches un peu plus poussées autour de certains sujets, notamment autour des différents design system.

Comme le disait Arnaud, on se fait un devoir quand même de concevoir des UI qui sont les plus accessibles possible, dans le périmètre de nos projets. Et du coup, l’idée c’était d’emmagasiner vraiment plein de connaissances et de connaissances, justement, glanées à droite et à gauche et de par nos expériences personnelles.

L’idée, c’était d’avoir ces connaissances pour concevoir des composants résilients, robustes, qui puissent répondre à différentes problématiques et ainsi les emmener au mieux de ce qu’ils puissent délivrer en termes de qualité.

Arnaud : Je crois que tu l’as dit tout à l’heure, mais en fait, on en a tiré plusieurs versions avant d’arriver sur une qui nous semblait convenir. Et pour faciliter ça, d’un point de vue construction sur Figma, on a vraiment travaillé en atomic design et on a réalisé plein de planches de composants malléables et facilement éditables sur Figma.

Pour faciliter la construction de cette solution sur Figma, on a vraiment travaillé en atomic design et réalisé de nombreuses planches de composants malléables.

On a eu deux versions majeures de ces planches de composants. La dernière, on s’est basée sur les retours de l’équipe qui a pu expérimenter cette première version de test. Et ça, du coup, ça nous a permis de se rendre compte un petit peu de l’importance du processus, justement.

On parlait un peu de design thinking, circulaire ou du coup, on éprouve un petit peu les composants avant de les rendre disponibles pour tous. L’idée, c’était vraiment de donner à l’équipe quelque chose de facile à prendre en main pour laisser libre cours à la créativité de toutes et tous et de convenir à la plupart des projets.

Matthis : Après tout ce ping pong entre Arnaud et moi pour concevoir une base autour des champs de formulaires, on a testé cette solution sur différents projets, que ce soit nous mêmes en fait, mais également en incluant d’autres membres de l’équipe, en leur proposant d’utiliser les solutions proposées afin de tester et récolter du feedback, voir justement ce qui n’allait pas ou ce qui allait justement dans ce que l’on proposait.

Après ce ping-pong entre Arnaud et moi pour concevoir cette base autour des formulaires, nous l’avons testé sur différents projets.

Du coup, avec tout ce feedback, on a continué d’améliorer notre base au fil des implémentations, toujours sur un jeu d’allers retours, et au final on a commencé à documenter nos premiers composants pour partager un peu la connaissance à tous les membres au sein de l’agence.

Adeline : Des réponses à des problématiques qui paraissent assez riches. Concrètement, à quoi cela ressemble-t-il ? Quels outils avez-vous mis en place, utilisés pour arriver à ce résultat ?

Arnaud : Je vais parler un peu de la partie organisation et présentation. Pour ça déjà, on va dire que le premier outil qu’on a lancé, c’est Miro. Pour nos brainstorming, pour nos ateliers, mais aussi pour la présentation de notre travail à toute l’équipe. Et on s’en est servi aussi un petit peu pour essayer de concevoir le cycle Vega.

La conception de Vega s’est inspirée du design thinking, dont on a repris les grands axes et que l’on a traité à notre sauce. C’est quelque chose qu’on a spécifié précisément pour ce projet là.

C’est inspiré du design thinking, justement. On a repris les grands axes et on les a un peu traité à notre sauce. On l’a spécifié précisément pour ce projet-là et pour les designers. J’en ai un peu parlé tout à l’heure, on travaille avec Figma, ça nous permet de centraliser tous nos modules, ça nous permet justement de les documenter comme on veut pour qu’ils soient, très facilement utilisables par toutes et tous.

L’idée, c’est de pouvoir les réutiliser facilement pour des nouveaux projets, un petit peu comme base et évidemment, c’est un fichier qui est à disposition pour les designers, qui est ouvert à la consultation pour les développeurs et sur lequel, dans l’idée, n’importe qui pourrait mettre des commentaires pour améliorer telle ou telle chose au fur et à mesure.

Matthis : Du côté des développeurs, on est parti sur l’utilisation de Storybook qui est un outil, un environnement qui permet de développer en isolation, décorrélé de tout contexte projet. Cet outil, on l’a un peu personnalisé pour pouvoir présenter du code source de multiples langages donc, c’est-à-dire, notamment pour les développeurs, l’important c’est le HTML, le CSS et JavaScript. Et du coup présenter ce code source qu’on peut ensuite copier coller au sein du projet.

Nous sommes partis sur Storybook pour la documentation générale et Zero Height pour la documentation technique.

Il faut savoir que Storybook c’est aussi un outil qui permet d’être une source de documentation. Mais en fait, on l’a gardé pour une documentation seulement technique, pas une documentation générale parce que, en fait, justement pour pouvoir contribuer à Storybook, pour l’utiliser, il faut quand même un bagage assez technique.

Et justement, pour avoir une documentation qui puisse être accessible et modifiable par l’ensemble de l’équipe, que ce soit des UX researcher, des chef.fe.s de projet, des designers, des développeurs, etc, on est en train de mettre en place un autre outil qui s’appelle Zero Height, qui est un outil qui, à la base, permet de documenter des design system.

Donc on va retrouver des fonctionnalités assez classiques, comme l’écriture de notes générales, des exemples de cas d’utilisation, de faire ou ne pas faire, etc. C’est un outil en fait en ligne et comme je le disais qui ne nécessite pas de bagage technique pour être mis à jour. Du coup, ça permet que tous les profils de l’agence puissent agrémenter la documentation si besoin et pour répondre eux-mêmes à leurs propres problématiques.

Aujourd’hui, on est plus dans l’optique de mettre en place une documentation liée à l’utilisation pour les designers et les développeurs, mais l’idée, c’est aussi de rajouter dans le futur des notions qui émergeront en fait au fur et à mesure à l’agence, comme l’éco-conception, l’UX writing ou tout autre domaine.

Adeline : Et dans toute cette mise en place, l’élaboration du projet, quelles sont les problématiques que vous avez rencontré ?

Matthis : Une des problématiques principales, c’est de pouvoir s’adapter à tout projet, techniquement et sans aller dans l’ultra paramétrable. On n’a pas vraiment envie d’avoir une usine à gaz entre les mains qui peut paraître très compliquée à utiliser ou à prendre en compte.

Une des problématiques principales, c’est de pouvoir s’adapter à tout projet, techniquement et sans aller dans l’ultra paramétrable.

Donc l’idée, c’est de faire attention à ne pas créer des composants trop fermés et qui briseraient la créativité. Vraiment, le but, c’est de faire en sorte que ce soit une base qui puisse être extensible au design de chaque projet afin de garder la singularité graphique et l’identité numérique de nos clients.

Arnaud : Il Faut savoir que c’est un projet qui nous a demandé de beaucoup nous adapter, sur lequel on doit vraiment avancer ensemble. En l’occurrence avec Matthis, mais à l’avenir avec d’autres personnes du métier. Et du coup, on a eu besoin de faire des pauses. On a donc fait en sorte de notre côté de profiter de ces temps de pause pour tester les modules sur des projets clients ou demander des retours à l’équipe, etc. C’est un projet qui est assez chronophage, qui nous a demandé des plages de temps assez larges et régulières pour bien démarrer un module.

Vega est un projet qui nous a demandé de beaucoup nous adapter. Nous devons vraiment avancer ensemble, avec Matthis, mais à l’avenir avec d’autres personnes, d’autres métiers.

Après, c’était un peu plus simple à gérer, on va dire. On a donc dû anticiper au mieux notre planning. Ce qu’on prévoyait de faire, ce qu’on prévoyait de rechercher, sachant que justement, en phase de recherche, ce n’est pas facile car on navigue beaucoup à vue, on ne sait jamais trop ce qu’on va trouver et sur quoi on va avancer.

En interne, on a dû bien expliquer l’objectif de Vega : gagner du temps sur nos projets pour laisser plus de temps pour la partie purement créative, graphique, conceptuelle.

Autre problématique, ça a été de faire adhérer vraiment l’équipe au projet. C’est pas vraiment une problématique, mais je savais d’expérience qu’avec ce genre de simili kit, il peut toujours y avoir une petite réticence. “Est-ce que ça ne va pas me brider créativement ?” Sur ce point, typiquement, on a déjà bien expliqué l’objectif de ce projet, qui était de gagner du temps sur tous nos projets clients, pour laisser plus de temps sur la partie purement créative, graphique, conceptuelle. Si on avait loupé cette qualité là de Vega, je pense qu’on aurait préféré tout arrêter car moi je pense que le plaisir de créer librement, c’est vraiment ce qui nous anime, nous les designers, tout au long d’un projet.

C’est important aussi à ce niveau là, en fait, de laisser la porte ouverte pour laisser aux designers le soin de ne pas, par exemple, utiliser un module dans le cas où le projet nécessiterait quelque chose de vraiment sur mesure.

Matthis : Autre point auquel je pense, c’est qu’il faut trouver les bonnes solutions qui soient utilisables facilement par le reste de l’équipe. Et ça, ce n’est pas si facile. Le projet, en soit, est assez singulier, on trouve peu de documentation ou de retours d’expérience, sur des personnes qui auraient déjà essayé de faire la même chose.

Le projet, en soi, est assez singulier. On trouve assez peu de documentation ou de retours d’expérience de personnes qui auraient déjà essayé de faire la même chose.

Au final, on doit vraiment tout créer de zéro et on avance pas mal à tâtons en faisant face à de nouveaux concepts, les contraintes de nos outils, de nos variétés d’utilisation, etc. C’est vraiment un travail, comme on l’a dit, en constante évolution, basé sur le feedback de chacun au sein de l’équipe.

Adeline : En plus de répondre à vos objectifs initiaux, est-ce que vous avez d’autres avantages, des à côtés bénéfiques, qui se sont dessinés ?

Matthis : Oui, complètement. Je pense beaucoup à la centralisation des connaissances et des bonnes pratiques. En fait, tout ce que chacun peut apprendre dans son coin ou à travers les modules développés au sein du projet Vega, on va pouvoir les communiquer en un seul endroit.

Côté bénéfice, je pense évidemment beaucoup à la centralisation des connaissances et des bonnes pratiques.

Je pense notamment à l’exemple du placeholder sur le module des formulaires. On avait des collègues qui n’étaient pas forcément au courant qu’un placeholder c’est à éviter en soit sur un site web, parce que ça pose des problèmes d’accessibilité. Les gens voient un champ rempli avec un placeholder, qui en soit est sensé l’inviter à remplir ce champ. Mais ils peuvent potentiellement le considérer comme déjà rempli et du coup passer à côté et quand il soumettra son formulaire, générera des erreurs. On avait des personnes qui étaient déjà au courant de ça dans l’équipe mais d’autres ne le savaient pas. C’est un bon exemple de connaissances à partager un peu pour tout le monde, on a cet enrichissement de connaissances communes.

Ça permet aussi un onboarding un peu plus aisé des personnes qui rejoignent l’agence. Avec ce regroupement de connaissances, on va déjà pouvoir leur mettre un pied dans l’agence.

Ça permet aussi, je trouve, un onboarding un peu plus aisé des personnes qui rejoignent l’agence ou même des profils juniors. C’est-à-dire qu’avec ce regroupement de connaissances, on va pouvoir leur mettre déjà un pied dans l’agence, ou nourrir des connaissances personnelles qui n’avaient pas encore.

Et dernier avantage, c’est pour des personnes qui ont pu accumuler justement de l’expérience, certaines notions, qui ont pu les partager, mais sans forcément les centraliser quelque part et qui finalement quittent l’entreprise, ça permet de pas perdre ces ressources là en fait, et d’être toujours dans l’évolution constante au sein de l’agence.

Arnaud : Là, si on parle un peu plus du métier de designer, si on prend le premier module qu’on a mis en place, je trouve que ça a permis de rassurer les designers sur le fait qu’ils ont donné l’ensemble des clés dont le dev a besoin pour travailler.

Typiquement sur le Figma que l’on a préparé, il y a vraiment toutes les itérations possibles de certains champs, des cases à cocher, etc. De base, en fait il y a tout. Il suffit juste de l’éditer et le mettre en forme selon justement la charte qu’on veut appliquer. Petit à petit aussi, on se rend compte que ça crée un petit peu plus de rapprochements entre le design et la technique.

Ce travail de documentation a permis de mettre des mots sur des concepts et de déconstruire certains aspects techniques et de conception qui n’étaient pas forcément visibles ou simples à prendre en compte.

Parce que ce que l’on a préparé sur Figma, ça a permis à toutes et tous de voir visuellement, d’un seul coup d’œil, toutes les variantes possibles d’un même composant. La documentation, ça a permis également de mettre des mots et de déconstruire un petit peu certains aspects techniques et de conception qui n’étaient pas forcément visibles, pas forcément faciles à prendre en compte. L’exemple des placeholder typiquement, c’était un bon exemple. Et petit à petit le projet, on se rend compte qu’il a un peu infusé dans les esprits.

Aujourd’hui, après un an de lancement, au fur et à mesure, nous nous rendons compte que ça a réduit les frictions qui pouvaient exister lors du passage à la réalisation technique.

Adeline : Quelles sont les prochaines étapes ?

Matthis : Je pense que l’une des prochaines étapes majeures, ça va être d’encourager la contribution de tous au projet et aux solutions proposées. C’est vraiment vers ça que l’on se dirige je pense en ce moment. Laisser d’autres personnes démarrer de nouveaux modules au sein du de Vega et du coup permettent d’étoffer le catalogue de composants, de modules proposés. Et tout ça du coup à travers le cycle itératif Vega auquel on a pensé, qui est basé comme je le disais sur une méthode de ping pong, on fait, on teste, on fait et au final on arrive à quelque chose et puis on documente.

Je pense que l’une des prochaines étapes majeures va être d’encourager la contribution de tous et toutes au projet et aux solutions proposées. C’est vraiment vers ça que l’on se dirige en ce moment.

Un bon point, ce serait, je pense, de profiter des solutions proposées sur de plus en plus de projets. Ça serait un bon marqueur d’adoption pour Vega, ça serait cool de voir ça ! (rires)

Arnaud : Un autre enjeu dans le futur aussi, ça va être d’entretenir tous ces différents modules. Pour l’instant, on en a qu’un mais potentiellement un jour on en aura je ne sais pas, peut-être mille ! (rires)

Je rigole, mais il faudra bien les entretenir justement pour qu’ils restent à jour, vérifier aussi s’ ils sont toujours utiles. Pour ça, on peut observer comment s’adapter aux nouvelles contraintes, aux nouveaux usages du web.

Il va falloir entretenir tous ces modules pour qu’ils restent à jour, vérifier qu’ils soient toujours utiles et observer comment on peut s’adapter aux nouvelles contraintes, aux nouveaux usages du web.

Pour finir, la prochaine étape cruciale, c’est que l’on va commencer justement à sonder chaque métier de l’agence pour vraiment définir quels pourraient être les prochains modules et sur lesquels travailler, prioriser tout ça.

Adeline : Merci beaucoup Matthis et Arnaud pour la présentation de ce starter kit documenté, un projet singulier et structurant pour l’agence, on se revoit bientôt pour un nouvel épisode !

Vous pouvez d’ores et déjà retrouver ce format Capsule Design tous les deux mois, en compagnie d’une personne de l’agence. Retrouvez également nos épisodes en format long avec des invité.e.s expert.e.s de leur sujet.

N’hésitez pas à vous abonner à la newsletter du podcast pour retrouver l’ensemble des ressources de nos épisodes, les tips et conseils de nos invités, c’est sur le site salutlesdesigners.lunaweb.fr que ça se passe.

On vous dit à bientôt pour un nouvel épisode de Salut les Designers !

Découvrez tous les mois un nouvel épisode de Salut les Designers consacré au design et à ses méthodes. UI, UX, motion, accessibilité, éco-conception, recherche, nous échangeons avec des professionnel·le·s passionné·e·s au grès de nos rencontres pour mieux comprendre leurs méthodes de conception centrée utilisateur.

Un retour, une question ? Contactez-nous sur salutlesdesigners@lunaweb.fr ou sur Linkedin.