Vue générale de la mission design system

Ensemble, nous allons explorer mon expérience au sein de l'entreprise, mon rôle, et mettre un accent particulier sur l'une des missions les plus importantes : la création et la maintenance de la version 2 du Design System, utilisé par toute l'équipe produit. Ce projet a été réalisé en collaboration étroite avec l'équipe technique, puis renforcé par leur soutien continu.

‍

Présentation de l’entreprise et du produit

L’entreprise, que nous nommerons Perle 🐟 (en référence au sous-marin français), est une entreprise basée à Marseille concevant des drones sous-marins. Pilotables à l’aide d’une tablette et d’une manette, ces drones permettent l’exploration des fonds marins afin d’y collecter des données de différentes manières, en fonction de la configuration de l’appareil.

Ces données collectées permettent ensuite un traitement sur un cloud dédié, afin de pouvoir prendre des décisions en fonction des besoins de l’entreprise disposant de la solution de Perle : étude des fonds marins, cartographie, état de la coque d’un paquebot, etc.

‍

Mon rôle au sein de Perle

Les effectifs de Perle étaient dispatchées autour de deux produits distincts, bien qu’en constante relation :

• L’équipe Hardware, travaillant sur le drone, sa configuration et son pilotage
• L’équipe Cloud, travaillant sur le SAAS traitant la donnée et permettant sa consultation et sa mise en forme

Chaque équipe était constituée de Techs, de Product Designers et de PM, chapotant et huilant les rapports entre tous les membres de l'équipe. Dans le cadre de mon poste chez Perle, j'ai agi principalement au sein de l'équipe Hardware, traitant les différents besoins utilisateurs afin d'améliorer, sprint après sprint, l'application tablette de contrôle des drones. De plus, j'avais un rôle transverse au sein de l'équipe Hardware, agissant en tant que 'co-PM' de l'équipe, assistant le PM attitré afin de gagner en séniorité sur le produit ainsi que sur le rôle de Product Manager.

Cependant, une mission de fond a occupé mon séjour au sein de l’équipe : le portage et la maintenance de la v2 du Design System de Perle.Hardware !

‍

Perle.Hardware : Un produit à part entière 🐟

Un peu d’histoire

Originellement un simple kit d'interface basé sur Adobe XD, utilisé par les équipes de conception à cette époque, la V1 de ce qui deviendrait Perle.Hardware et Perle.Cloud était un document général conçu pour accélérer le temps de conception dépensé par les Product Designers des équipes produit, sans distinction de pôles.

Lors de la migration des concepteurs vers Figma, un outil bien plus en accord avec les usages actuels, l'UI Kit a dû tout naturellement suivre ce long voyage. Ainsi, lors de cette migration, une V1.5 puis une V2 ont été conçues puis déployées pour s'intégrer au workflow de toutes les équipes et de tous les membres de l'équipe produit. Transcendant son simple rôle d'UI Kit, les versions 2 (Perle.Hardware et Perle.Cloud) sont devenues des outils de conception transversaux essentiels à la création de nouvelles fonctionnalités sur les deux produits de Perle.

‍

Les prémices

Comme mentionné précédemment, la V1 du Design System était essentiellement un UI Kit. Sa mission principale consistait à optimiser le temps de travail des concepteurs en leur offrant une base de composants d'interface, ainsi que des directives stylistiques (typographies, couleurs, espacements, etc.), le tout regroupé dans un document dédié sur Adobe XD.

A mon arrivée au sein de Perle, j’ai pu observer deux problèmes majeurs :

• L’UI Kit n’était pas à jour : n’ayant pas de PrDesigners disponible à la maintenance de l’UI Kit, celui-ci n’était pas spécialement à jour, causant des ralentissements à la conception puisque nécessitant des retouches régulières sur les composants importés, issus du kit
• Adobe Xd était un problème : solution logicielle imparfaite, Adobe Xd ne proposait pas de portage efficace des UI Kit au sein des différents fichiers, causant des temps de traitement rallongés

En réponse à ces deux problématiques, j'ai initié et supervisé la transition de l'équipe de design vers Figma, une solution mieux alignée avec les standards actuels de conception. Ce transfert s'est déroulé progressivement, nécessitant une collaboration étroite avec les développeurs qui devaient également s'adapter à ce changement de plateforme, étant déjà habitués aux transferts de projets avec Adobe XD.

‍

La collaboration

Avec la transition vers un nouveau logiciel (de Adobe XD à Figma), je me suis rapproché des équipes techniques pour organiser des sessions de révision de la nouvelle plateforme de collaboration. L'objectif était de garantir que tous les membres partageaient une base de connaissances commune concernant cet outil.

Au fil de ces sessions, un élément crucial a commencé à émerger : l'intérêt des équipes pour les composants utilisés dans les prototypes était bien plus marqué que nous ne l'avions anticipé. La standardisation, la nomenclature, la précision visuelle, les variantes… Nous avions là les fondations de ce qui deviendrait une collaboration étroite, aboutissant à la création d'un Design System co-conçu par les Product Designers et les équipes techniques.

<aside>☝ En tant que PrD, je me suis occupé d’une partie de la v1.5 de Perle.Hardware, qui était auparavant un seul UI Kit pour les deux produits, maintenant divisé en deux, pour chaque produit de la marque.Cependant, je dirigeais aussi la collaboration de toutes les équipes en tant que semi-PM. En maintenant le backlog à jour et en organisant des points de revue avec les techs pour aborder les problématiques de transition et de besoins de leurs côtés, je m’assurais que cette refonte soit comprise et répondait aux besoins de toutes et tous !

</aside>

Pour mener cette transition à bien, voici la démarche utilisée :

• Des meetings initialement sur la découverte de Figma, étaient prévus de façon hebdomadaire avant puis pendant la transition. Nous y abordions des questions d’ergonomie du logiciel, mais aussi des notions approfondies pour les curieux.
• Voici ce qui a été observé :
• Les équipes techs avaient de leur côté des briques de codes réutilisées régulièrement au sein des différents produits “pour ne pas devoir tout redévelopper”.
• Les équipes produits disposent eux aussi de briques afin de diminuer les erreurs, les inconsistances et d’augmenter la standardisation qualité du produit en diminuant les coûts de conception
• → Il y a là l’occasion de réunir les deux outils afin de répondre a une problématique passée “Tenir à jour l’UI Kit”, qui pourrait être désormais plus complet et donc plus simplement maintenu.
• Suite a cette découverte, nous mettions à jour l’épique au fil de l’eau avec les différentes US se dégageant des meetings, mettant en valeur l’évolution du projet, passant peu à peu d’un simple portage a une future bibliothèque de savoir produit interne.
• Chaque US découlait d’une observation au cours des meetings
• Elle contribuait a faire évoluer le contenu du DS, de sa nomenclature, de son lien avec les équipes techs
• Les US répondaient aux même critères de qualité que des US produit “classique”, en terme de fond et de forme, afin de ne pas traiter ce sujet différemment, bien qu’interne

‍

L’aboutissement

En voyant l’intérêt grandissant qu’apportait ce nouveau produit, nous avons staffé temporairement une équipe de conception de Perle.V2, composée de :

• Deux PrDesigners, un par équipe produit (Hardware et Cloud) chargés de concevoir les nouvelles composantes de la bibliothèque avec une nomenclature et une architecture établie (et donc comprise) en collaboration avec les équipes techs.
• Deux développeurs, encore une fois un par équipe produit (Hardware et Cloud) faisant une vérification ponctuelle des éléments ajoutés et contribuant à l’ajout du storybook

Cette équipe allouait un temps variable au projet en fonction des besoins externes. Cependant, ce fut un projet maintenu et choyé pendant six mois, période durant laquelle amélioration continue fut apportée sur la plateforme.

La plateforme fut conçue sur Notion (plateforme sur laquelle les handoff design ↔ tech étaient déjà en vigueur). Cependant, d’autres outils ont été cependant considérés pour une v3, comme Zeroheight afin de simplifier la maintenance pour les équipes futures.

Le DS s’articulait autour d’une architecture atomique classique, bien que renommée pour fit avec le vocabulaire commun :

• Les fondations, comprenant les éléments insécables des composantes d’interface
• Les composants, élément d’interface avec une fonction, conçu uniquement avec des éléments “fondationnés”
• Les patterns, pour les éléments complexes redondants et standardisés au sein des processes techs

Une partie contenu, initiée par les UX Writers / Sales était en cours de conception durant mon expérience passée, mais je ne sais pas si elle a vu le jour.

Chaque élément du design system était composé de :

• Une introduction, décrivant l’élément dans sa fonction, afin de garantir une documentation complète lors d’un onboarding
• Les usages de l’élément, autour de do's et de dont's clés
• Les variantes de l’élément, s’il en disposait
• De ressources externes, avec un embed Figma vers le composant et un embed Storybook pour les briques de code des dévs

‍

L’impact

Suite au déploiement du DS, au fil de sa conception, nous avons remarqué que cette collaboration commune a permis de simplifier la mise en place de features, fluidifiant le lien entre techs et PrD. De plus, la mise en place d’une bibliothèque commune a permis de diminuer drastiquement les aller-retours entre les deux sous-équipes, permettant ainsi de gagner du temps.

Ainsi, nous avions observé que :

• Les équipes étaient plus efficaces, puisque moins aliénées par des points de synchros réguliers
• Les équipes se sentaient plus libres et se comprenaient plus sur certains aspects du travail de l’autre
• Les équipes techs s’impliquaient plus naturellement dans les problématiques de tests, là où avant il y avait un besoin de lobbying des PMs

Concrètement, nous avons observé un gain d’une journée par sprint en moyenne, avec une hausse de la vélocité des équipes d’environ 10%.

‍