Capsule Design #10 : La coopération design et dev. avec VEGA, 1 an après !

Dans cette dixième (déjà !) Capsule Design, Arnaud, Manuel et Anaïs reviennent sur notre headless design system après un an d’utilisation.

Entre changement d’équipe, réorganisation des temps de travail et échanges collaboratifs avec les membres de l’agence, plongez dans le making of de VEGA saison 2.

Bonne écoute à tous et à toutes !

La transcription de l’épisode

Arnaud : Bonjour à toutes et à tous, ici Arnaud designer au sein de l’Agence LunaWeb et bienvenue dans ce nouvel épisode de Salut les Designers. 

Aujourd’hui, avec notre format court intitulé “Capsule Design”, nous allons vous raconter la suite de la création de Vega, notre solution interne pour améliorer la collaboration entre les pôles design et technique. Nous vous en avions parlé en octobre 2022 dans notre quatrième Capsule Design.

Matthis : C’est un projet qui est né il y a à peu près un an. C’est une solution notamment orientée interface utilisateur dont l’idée est de communiquer 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.

Arnaud : On vous invite à l’écouter si ce n’est pas déjà fait.

Depuis il s’est passé beaucoup de choses sur Vega. Nous avons par exemple réorganisé notre façon de travailler, et surtout, sanctuarisé du temps et défini un budget pour continuer à faire avancer le projet sereinement. 

Il s’est passé beaucoup de choses sur Vega depuis l’année dernière. Nous avons réorganisé notre façon de travailler, sanctuarisé du temps et défini un budget, pour continuer à faire avancer le projet sereinement. 

Petit changement d’un point de vie équipe, puisque Matthis, notre développeur a quitté l’agence pour démarrer une nouvelle aventure du côté du product. Nous avons donc recherché un nouveau développeur au sein de l’équipe pour reprendre le travail qui était déjà bien lancé. 

Et c’est donc Manu qui a tout doucement repris la main côté développement.

Manu : Pour ma part, je suivais le projet déjà depuis son lancement mais je l’ai rejoins réellement fin 2022. Pour la petite histoire, il faut savoir que la mise en place d’un moyen de mieux industrialiser notre travail, c’est un sujet qui a été assez récurrent chez LW et qui me semble plus atteignable aujourd’hui notamment grâce aux outils comme Figma.

Toujours est-il que dans un premier temps, je suis passé par une phase d’assimilation du travail que Matthis avait déjà réalisé. En particulier sur l’usage de Storybook, l’outil dans lequel les composants sont mis à disposition pour les équipes de développement.

La mise en place de moyens de mieux industrialiser notre travail est un sujet qui est assez récurrent et qui nous semble plus atteignable aujourd’hui grâce à des outils comme Figma.

Une fois un peu plus en confiance, je me suis lancé dans l’implémentation d’une version stable du composant “bouton”, qui était déjà existant mais pas encore totalement finalisé.

Ça s’est révélé être un très bon exercice étant donné que ce composant peut adopter plein de formes différentes : primaire, secondaire, avec ou sans icône… et j’en passe.

Et, après quelques itérations, je l’ai présenté au reste de l’équipe Front-end qui a pu me faire quelques retours. Ça a mené à de petits ajustements destinés à simplifier l’adoption de l’outil parce que c’est quand même mieux si c’est utilisé sans trop de difficultés.

Arnaud : Ce changement d’équipe a également été l’occasion de revoir notre façon de travailler et d’avancer sur le projet. 

Et pour nous accompagner là-dessus, il nous fallait une vision plus globale qui nous a permis de prendre plus de hauteur sur la production. 

Nous l’avons trouvé auprès d’Anaïs, cheffe de projet à l’agence.

Anaïs : En début d’année, j’ai rejoint l’équipe sur le projet pour les épauler sur l’organisation et leur permettre de se concentrer sur la production sans avoir à se poser trop de questions d’organisation.

On a commencé par faire un REX de la première année écoulée pour prendre un peu de hauteur et faire le point sur ce qui avait été fait au cours de cette année et ce qui semblait pertinent à mettre en place pour l’année à venir.

Dit autrement, on a commencé à établir une roadmap en débutant par la 1ère étape : lister les tâches à faire, les modules à concevoir.

Pour améliorer Vega, nous avons commencé par faire un REX de la première année écoulée, pour prendre un peu de hauteur et faire le point sur ce qui avait été fait et ce qui semblait pertinent à mettre en place. 

Une fois qu’on avait listé toutes ces idées, on les a classifiées et on a défini les priorités. Pour ça, on s’est appuyés sur 2 critères assez simples : la fréquence d’utilisation (est-ce que ce module est fréquemment utilisé dans nos projets ou est-ce que c’est finalement plus anecdotique ?) et la complexité à le concevoir.

Ça nous a donné une vision très rapide sur le bénéfice / temps passé. Si un élément d’interface est souvent (voire quasi toujours) présent dans nos projets et qu’il peut être assez rapidement déployé dans Vega, alors il est mis en haut de la liste.

Quand on a terminé cette liste priorisée, on savait alors où on voulait aller pour ce qu’on appelle entre nous  “la 2ème saison de Vega”, on savait ce que cette 2ème année devait embarquer.

S’est alors posée la question de “Comment on s’organise ? Comment on s’assure de réussir à avoir de la visibilité sur notre avancée pour que, à la fin de l’année, on ait réalisé tout ce qu’on s’était fixé ensemble ?”.

On a commencé par définir une enveloppe de temps qu’on pouvait allouer à ce projet interne et on a sanctuarisé ces temps dans la feuille de route de notre quotidien de l’Agence. C’est comme ça qu’on a validé que l’on pouvait allouer 2 jours par mois de chacun à ce projet, que l’on a planifiés sur toute l’année à venir au rythme d’1 journée toutes les 2 semaines.

Après avoir prioriser les éléments à travailler, la question de l’organisation s’est posée. Nous avons décidé de sanctuariser deux jours par mois et d’avancer en sprint. 

Sur la base de ce rythme-là, on a décidé d’avancer en sprints et de découper l’année en 12 sprints.

Et puis on s’est créé un rendez-vous de suivi mensuel : tous les derniers mercredis du mois, on se retrouve tous les 3 et on fait :

• Le point sur ce qui a été fait au cours du mois (est-ce que les modules qu’on s’étaient fixés sont prêts, est-ce que leur conception a soulevé des problématiques particulières, est-ce que les dernières mises à jour ont été partagées aux autres designers et développeurs front de l’Agence, etc),
• Et on se fixe les objectifs pour le sprint suivant

Ça permet à chacun de bien savoir ce qu’il a à faire ce mois-ci et aussi d’anticiper les éventuels besoins un peu spécifiques, notamment quand on a besoin de solliciter d’autres personnes de l’Agence, on peut alors organiser à l’avance un atelier de travail conjoint sur le sujet.

Arnaud : Ces sprints évoqués par Anaïs nous ont permis d’avancer sur différents sujets petit à petit, s’en trop s’étaler. 

L’un des premiers sprint en question fut la réorganisation de notre starter Figma. En effet, au bout de plus d’un an d’utilisation, notre starter a accumulé plusieurs retours et axes d’améliorations de la part des designers mais pas que : Les développeurs, les chefs de projets et même les clients ont influé sur les évolutions que nous apportons au starter. Évidemment, les plus petites évolutions ont pu être absorbées rapidement lors de nos sprints mensuels.

L’un des premiers sprint fut la réorganisation de notre starter Figma. En effet, au bout d’un an d’utilisation, nous avions accumulé plusieurs retours et axes d’améliorations de la part des designers mais aussi des autres membres de l’équipe projet.

Néanmoins, certains sujets de fond ont nécessité plus de temps de travail pour revoir des fonctionnements plus structurants. Par exemple, il y a l’organisation des pages, le besoin d’explication pour utiliser certains modules, la gestion et le partage des styles avec les développeurs etc.

Les dernières mises à jour de Figma ont aussi guidé certaines évolutions. Après en avoir évalué les impacts, nous les appliquons à nos modules en place pour fournir un starter avec des fondations et des composants performants et faciles à utiliser pour notre équipe. 

Par exemple, les dernières évolutions relatives aux variantes nous ont permis de revoir la façon de concevoir certains modules. Plus récemment, la mise en place des variables sur Figma, toujours en beta à l’heure où nous enregistrons ce podcast, nous permet de revoir les fondations et la rationalisation d’un grand nombre valeurs numériques. Nous pensons qu’il s’agit d’un des game changer de notre starter.

Les dernières mises à jour de Figma ont aussi guidé certaines évolutions. Par exemple, la mise en place des variables, toujours en beta, est probablement l’une des game changer de notre starter.

Une fois ces évolutions mises en place dans notre starter de travail, nous les validons avec les designers et les développeurs puis nous déployons une version utilisable par toute l’équipe. Actuellement, nous venons de refaire cet exercice et nous comptons le refaire chaque année pour garder un starter performant et qui s’adapte aux usages et aux besoins de l’équipe.

En dehors de ça, nous avons voulu aller plus loin en nous interrogeant sur les besoins de chaque personne et de chaque métier à l’agence. On s’est donc emparé du sujet avec Anaïs…

Anaïs : On avait vraiment envie d’intégrer toute l’équipe dans la réflexion et on a donc lancé une enquête interne destinée à tous les métiers de l’Agence.

Le but : faire émerger des idées en interrogeant tout le monde et les différents métiers de l’Agence sur les fonctionnalités et éléments d’UX que chacun voit revenir de manière récurrente au sein des projets et qui pourraient être rationalisés.

Nous avions aussi vraiment envie d’intégrer toute l’équipe dans la réflexion et nous avons donc lancé une enquête interne destinée à tous les métiers de l’Agence, avec le concours de Justine, UX Researcher à l’Agence. 

Nous avons analysé les réponses avec Justine, UX Researcher à l’Agence, et nous avons listé l’ensemble des éléments qui ont été cités, en tenant compte également des occurrences, du nombre de fois que chaque élément a été cité par quelqu’un.

Ensuite, pour savoir par où commencer, nous avons brainstormé ensemble et nous avons fait émerger des quick-wins et une feuille de route.

Arnaud : En faisant cet exercice, nous avons segmenté les résultats en les différenciant en 2 grandes familles :

D’une part, les composants qui sont relativement simples et rapides à concevoir et à intégrer : des boutons, des champs de formulaires… Il y a d’ailleurs une grosse part de ces composants présents dans n’importe quel design system.

Avec ces recherches, nous avons pu segmenter les futurs travaux en deux grandes familles : les composants d’interface comme les boutons et les champs de formulaire et les modèles de conception comme les menus par exemple.

D’autre part, les designs patterns ou modèle de conception qui sont plus complexes à mettre en place sans une base solide. Manu nous en parle…

Manuel : Pour celleux qui ne sont pas familiers avec la notion de Design pattern, pour faire simple, ce sont des solutions à des problèmes de conception assez récurrents.

Par exemple, un des plus courants est celui des navigations burger. Concrètement, lorsque l’on est sur smartphone ou plus généralement un contexte d’affichage réduit, la navigation principale se retrouve rapidement à prendre beaucoup d’espace sur l’écran.

Pour éviter à l’utilisateur de se retrouver avec cet élément qui prend toute la place à chaque fois qu’il change de page, l’idée est de la cacher par défaut et de mettre en place un bouton permettant de l’afficher quand l’utilisateur le souhaite afin de lui faciliter la navigation sur le site.

Pour en revenir à Vega, suite à tout ce travail de récolte des besoins et de classification, on a pu prioriser les éléments et avancer efficacement.

Avec l’arrivée de nouvelles fournées d’éléments, nous avons commencé à chercher à mieux organiser et structurer toute cette mémoire sous forme d’une documentation via l’outil Notion.

Néanmoins, depuis les premiers modules, tout le travail de recherche et les décisions qui ont été prises étaient disponibles sous forme de notes mais avec l’arrivée de la nouvelle fournée d’éléments, nous avons commencé à chercher à mieux organiser et structurer toute cette mémoire sous forme d’une documentation via l’outil Notion.

Notre objectif étant que chaque membre de l’équipe puisse s’y référer. Qu’il s’agisse d’une nouvelle arrivante ayant besoin de monter en compétences, comme d’un ancien qui cherche à muscler son argumentaire sur des choix de conception.

On a donc mis en place une documentation listant chaque élément, composant ou design pattern, reprenant toutes les informations utiles et faisant référence, lorsque c’est nécessaire, à des contenus de documentation plus générale.

Notre objectif a été que chaque membre de l’équipe puisse s’y référer. Qu’il s’agisse d’un·e nouvel·le arrivant·e ayant besoin de monter en compétences, comme d’un·e ancien·ne qui cherche à muscler son argumentaire sur des choix de conception.

Par exemple, les liens d’évitements présents dans Vega ont une version où leur affichage dépend du focus. Puisque nous avons déjà décrit ce à quoi correspond cet état dans une page sur l’accessibilité, nous avons fait directement référence à ce contenu au sein même de la page présentant des liens d’évitements. Grâce à ça, si nous décidons de mettre à jour ce texte, nous n’avons qu’à modifier le bloc original et automatiquement, les références se mettront à jour.

Cette complémentarité entre la documentation Vega et la documentation générale nous semble être le meilleur compromis pour avoir des informations digestes sur les éléments Vega, mais aussi pour améliorer la maintenabilité et l’évolutivité des contenus.

Arnaud : Avec Vega, on a envie d’optimiser la qualité de chaque module déployé et d’aligner leur processus de conception avec le discours de l’agence. C’est ce qui nous pousse à prendre en compte plusieurs domaines bien précis : L’accessibilité et l’éco-conception évidemment, mais aussi d’autres domaines comme l’UX writing et le SEO. 

Avec Vega, nous avons envie d’optimiser la qualité de chaque module déployé et d’aligner leur processus de conception avec le discours de l’agence : accessibilité, éco-conception mais aussi UX writing et SEO. 

Ces deux derniers sujets nous ont d’ailleurs demandé de nouveau d’interroger d’autres membres de l’équipe pour récolter les meilleures pratiques à adopter en conception. Prenons ces deux sujets pour vous parler de la façon dont nous avons procédé.

Après avoir annoté un petit nombre de recommandations d’UX writing à certains modules de notre documentation, nous avons fait appel à Justine, référente sur le sujet à l’agence. Nous lui avons tout d’abord présenté en détail la doc et son fonctionnement, puis nous lui avons demandé d’apporter ses propres recommandations et d’ajuster si nécessaire celles que nous avions ajoutées en amont.

Pour le SEO, nous avons procédé légèrement différemment, nous avions besoin de deux visions complémentaires pour concevoir un module de pagination. Pour cela, nous nous sommes de nouveau tournés vers l’équipe afin de récolter une vision purement SEO grâce à Maéva ainsi qu’une vision plus technique portée par Aimerick.

Nous avons donc préparé avec Manu une petite interview d’une heure qui avait pour objectif de déceler des contraintes, des axes d’améliorations et des leviers de conception.

En expérimentant plusieurs façons de collaborer avec l’équipe, nous avons appris à nous adapter à différentes situations pour rendre possible notre volonté de rendre Vega plus participatif.

Ces deux manières de procéder nous ont permis d’améliorer grandement la qualité de nos modules. Vue d’un autre prisme, en expérimentant plusieurs façons de collaborer avec l’équipe, nous apprenons à nous adapter à différentes situations pour rendre possible notre volonté de rendre Vega participatif. Notre souhait, c’est de faire jouer le collectif en rendant Vega vivant et utile pour toute l’équipe.

Anaïs : Après 2 ans, si on regarde un petit peu derrière nous, on voit qu’il y a eu beaucoup d’évolutions depuis le début : notre organisation autour de ce projet s’est structurée, de nombreux modules ont été mis en place et sont désormais disponibles et utilisés au quotidien par l’équipe, on a trouvé un rythme de croisière qui porte ses fruits et nous permet d’avoir un rendu final à la hauteur des ambitions que l’on s’est fixées.

Arnaud : On a eu besoin d’un long moment pour poser un socle fiable à travers le starter Figma, la stack storybook, la documentation et surtout l’organisation des temps de travail afin d’avancer en toute sérénité sur plusieurs modules. 

On se rend compte qu’après notre premier module, nous avons eu du mal à avancer, car nous n’arrivions pas à trouver du temps pour se lancer dans de nouvelles évolutions. 

Nous avons eu besoin d’un long moment pour poser un socle fiable à travers le starter Figma, la stack storybook, la documentation et surtout l’organisation des temps de travail, afin d’avancer en toute sérénité sur plusieurs modules. 

Le fait de s’organiser en sprint grâce à Anaïs, de sanctuariser du temps et de poser un budget, ça nous a véritablement permis de démarrer le projet. C’est pas un sujet anodin et il faut vraiment y mettre les moyens pour avoir un résultat satisfaisant et qualitatif.

Ce qui est cool, c’est qu’on voit l’utilisation de la stack au quotidien. 

On a encore quelques barrières à franchir de façon à ce que l’équipe puisse s’approprier l’outil pour y contribuer. Continuer à clarifier et à structurer les processus de conception d’un module devrait permettre de faire intervenir encore plus de monde sur le projet et de différentes façons. Surtout, on a envie que Vega soit un outil collectif, évolutif et qui nous permette de continuer à améliorer la qualité de nos productions.

Clarifier et structurer les processus de conception des modules devrait nous permettre de faire intervenir encore plus de personnes sur le projet et de différentes façons. Nous avons réellement envie que Vega soit un outil collectif et évolutif.

Et bien c’est déjà la fin de cette dixième capsule design. Merci à Anaïs et Manu de m’avoir accompagné sur ce podcast. On revient le mois prochain avec un nouvel épisode.

En attendant, 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. 

À très bientôt !