Décryptage du rôle d’un Product Owner sur un Design System

Je m’appelle Magali Bai, je suis Product Owner sur la mise en place d’un Design System d’un grand groupe français depuis maintenant 1 an et demi.

Voici mon retour d’expérience en tant que PO sur l'implémentation d'un produit digital très particulier et évoluant dans un environnement complexe.

Quel est le rôle d’un Product Owner sur un Design System ?

Commençons par un peu de contexte : ce grand groupe français a lancé son programme de transformation digitale en mai 2020, ayant pour objectif de devenir numéro 1 du marché grâce à la construction d’outils métiers sous forme d'applications SaaS dédiées aux différents métiers (marketing, ventes, promotions…) du groupe dans le monde afin d’avoir un impact sur les ventes.

Plusieurs produits digitaux ont vu le jour, dont le Design System qui a pour objectifs :

• Harmoniser tous les produits digitaux grâce à la mise à disposition d’une librairie commune pour tous les designers et développeurs du groupe.
• Réduire le time to market, et notamment le temps dédié au design et au développement.

C’est ici que démarre l’aventure du Design System de ce groupe Français….

Il était une fois ….

En 2021, une agence externe qui avait initié le sujet et créé une partie de la librairie. Le chantier a ensuite été confié à une équipe dédiée au design de l'interface utilisateur (UI).

Cette équipe était composée d'un lead designer, de designers UI et de développeurs back-end et front-end.

Le lead designer a peu à peu endossé le rôle d'un product manager, ce qui a nécessité une évolution de la structure de l'équipe. Ainsi, pour venir l’épauler, il a eu besoin de l’appui d’un Product Owner.

TA DA, me voilà !

En tant que Product Owner, je gère les aspects clés du produit en veillant à la livraison, la priorisation du backlog et la qualité du produit.

Pour avancer rapidement et efficacement, je travaille main dans la main avec l'équipe UI pour comprendre son travail et transmettre les informations aux développeurs. Je rédige des US alignées avec le design et les pré-requis techniques pour assurer une bonne livraison des composants.

Enfin je dois être alignée avec le Lead Designer/PM pour travailler ensemble sur la feuille de route. La collaboration est primordiale pour la réussite de notre projet.

Ainsi, cela permet de mieux comprendre les besoins de chaque équipe et de proposer des solutions adaptées à chacun.

Mais quelles sont mes missions principales ?

J'ai participé à différentes phases de réalisation du produit :

La phase de Build

Comme évoqué précédemment, à mon arrivée sur le projet, une grande partie de la conception était déjà prête et certains développements avaient commencé.

L'objectif était de pouvoir livrer de la librairie figma et du storybook en 5 mois.

Pour atteindre cet objectif, j'ai organisé un atelier pour déterminer les definitions of Ready (DoR) et of Done (DoD) avec toute l'équipe technique et design. Cela a permis de poser un cadre pour préparer et livrer au mieux à l’issue de chaque sprint.

Ce n'est pas tout, j'ai également défini un modèle de rédaction des User Stories, dans lequel on trouve :

• La description
• Les propriétés variantes qui donnent toutes les caractéristiques du composant, allant des couleurs, des tailles au comportements attendus (hover, active, focus etc.)
• Les critères d'acceptation en BDD (Behavior Driven Development)

Et toujours accompagné d'un lien Figma pour permettre aux développeurs de respecter les attentes de la conception et des comportements pensés.

En plus de cela, j'ai travaillé avec l'équipe pour définir les dépendances entre les différents composants, afin de s'assurer que le développement avance de manière cohérente et de minimiser les risques de régression.

Par exemple, quand on parle de dépendances entre les différents composants, c’est qu’il faut que certains composants soient construits en amont pour pouvoir l’assembler avec un autre composant.

Ici, cette table est composée de plusieurs éléments qui doivent impérativement être construits en amont de la création d’une table :

• Chips (1)
• Buttons (2)
• Pagination (3)

À chaque livraison, l’intervention d’une QA était requise pour vérifier que le front-end était conforme à la conception, mais aussi que les composants étaient fonctionnels. Pour assurer une bonne QA, il a été nécessaire de mettre en place un plan de test partagé avec les designers de l'équipe. En tant que PO, je me chargeais de la recette fonctionnelle et les designers de la recette front-end.

Remarque : le plan de test a été construit en collaboration avec les designers, et comportait les différents cas d'utilisation ainsi que les critères d'acceptation. Nous avons également travaillé avec les développeurs pour nous assurer que les tests étaient complets et pertinents.

Une fois la première version livrée, selon la feuille de route du programme, un premier produit digital “E” devait migrer vers le Design System. Cet outil permet aux responsables marketing de rendre compte des dépenses de marketing direct chaque semaine. Les données collectées alimentent l'algorithme d’un autre outil digital.

Pour cela, j'ai collaboré avec l'équipe “E” pour définir les différents éléments à migrer, les priorités, ainsi que les éventuelles difficultés à anticiper. Nous avons également travaillé à la mise en place d'un plan de communication pour informer les utilisateurs de la migration, ainsi qu'à la formation des équipes pour qu'elles soient prêtes à utiliser le nouveau système.

Enfin, j'ai optimisé le processus de développement, en identifiant les points de blocage comme la gestion des bugs et les améliorations possibles par le paramétrage des différents jiras afin que les données soient remontées correctement dans ma backlog.

Nous avons ainsi mis en place des outils et des processus plus efficaces pour accélérer le développement et améliorer la qualité du produit final comme des instances dédiées pour que les PO nous remontent leurs besoins, leurs frustrations, ou tout simplement pour que je leur remonte les dernières informations. C’est ce qu’on appelle la “Design authority”, ce sont des processus organisés par la partie Design qui vont permettre les échanges d’informations avec toutes les parties prenantes et surtout bien préparer les migrations.

La phase de Run

La migration d’un produit avait été initialement estimée à un mois de temps, cependant, en raison des congés estivaux, elle a finalement duré trois mois. Malgré les attentes élevées que nous avions placées dans cette migration, qui devait nous permettre d'acquérir notre premier adoptant et de prouver la valeur de notre Design System, nous avons dû faire face à plusieurs obstacles lors de la phase RUN :

• Incident sur la production du produit “E” qui a entraîné un ralentissement de la migration
• Bugs non identifiés, beaucoup d’erreurs d’implémentation par le produit “E” et aussi des bugs côté Design System
• Gestion du stress et de la frustration des équipes

En plus de l'amélioration continue du Design System, l'enjeu principal de cette phase était de pouvoir débugguer des éléments tout en continuant à pousser des évolutions. Cependant, la tâche s'est avérée plus complexe que prévu.

En effet, la première version du Design System a été livrée seulement deux semaines avant le lancement de la migration “E”, ce qui a engendré la remontée de nombreuses anomalies, et peu de temps pour les corriger. Les efforts de l'équipe ont donc été concentrés sur la correction de ces bugs, ce qui a eu un impact sur la roadmap produit et bloqué la mise en production de nouveaux composants.

Finalement, bien que cette phase ait été très challengeante et que nous ayons dû surmonter de nombreux écueils, elle a été très enrichissante. Le travail de proximité avec l'équipe design et l'équipe technique a eu une forte valeur ajoutée, cela nous a permis de consolider nos compétences et d'assurer une bonne entente entre ces deux équipes.

Quels sont les obstacles que j’ai rencontrés et comment les surmonter ?

Au cours de ces mois de migration, nous avons dû faire face à plusieurs difficultés.

Tout d'abord, il y avait la correction des bugs. Les bugs arrivaient au fil de l’eau et nécessitaient une attention constante pour être corrigés rapidement.

Pour gérer ces vagues d’anomalies, nous avons décidé de les prioriser et de mettre en stand by toute amélioration du design system.

J’ai mis en place une task force pour gérer ces nombreux bugs (par exemple, les développeurs n’avaient que des sprints dédiés aux bugs).

Nous avons également dû gérer la relation avec le Product Owner de E. Il était important de maintenir une communication fluide pour éviter toute incompréhension entre les deux parties. En plus des daily dédiés à la migration, j’ai organisé des points hebdomadaires pour échanger avec le Product Owner et son équipe. Et bien sûr, j’allais prendre des nouvelles régulièrement.

La gestion de l'équipe technique représentait également un défi de taille. Il fallait s'assurer que chaque membre de l'équipe était aligné avec les objectifs et qu'il disposait des ressources nécessaires pour travailler efficacement. Pour assurer cela, j’ai mis en place des sessions de démo à chaque release avec les correctifs. En effet, ces démonstrations permettaient de rassurer l’équipe qui implémente le Design System en montrant que le bug remonté était reproductible et corrigé.

Enfin, la gestion du stress et de la frustration de notre équipe et de celle d'E était essentielle pour maintenir la motivation et l'énergie. Encore une fois, la clé est la communication. En tant que PO du Design System, je restais toujours à disposition pour échanger avec les équipes de E.

Dans l'ensemble, cette période de migration n’a pas été facile, mais elle nous a permis de consolider nos compétences et de renforcer notre collaboration entre équipes. Nous avons dû faire preuve de persévérance, de créativité et de patience, mais nous avons finalement réussi à livrer une version stable et fiable du Design System.

Pour conclure : si toi aussi, tu es Product Owner d’un Design System, voici mes recommandations :

🧑‍💻 Comprendre les besoins des utilisateurs : S’assurer de bien comprendre les besoins et les attentes des utilisateurs du Design System. Cela va te permettre de prioriser les fonctionnalités et les améliorations qui sont les plus pertinentes et utiles pour eux.

🤝 Impliquer les parties prenantes : Travailler en étroite collaboration avec les différentes parties prenantes, notamment les designers, les développeurs et les responsables produits. Les impliquer dans le processus de définition des fonctionnalités et des améliorations du Design System. Tenir compte de leurs commentaires et de leurs besoins spécifiques.

👀 Établir une vision claire : Définir une vision claire pour le Design System. Identifie les objectifs à long terme et les avantages attendus pour l'organisation et les utilisateurs. Cela aidera à aligner les efforts de développement et à communiquer efficacement les objectifs aux parties prenantes.

🚀 Établir une feuille de route : Créer une feuille de route détaillée pour le Design System, en prenant en compte les fonctionnalités et les améliorations prioritaires. Cela permettra de planifier les ressources nécessaires et de communiquer les étapes clés aux parties prenantes.

🙏 Favoriser la collaboration et la communication : Encourager la collaboration entre les différentes équipes travaillant avec le Design System.

⭐️ Assurer la qualité et la cohérence : Veiller à ce que le Design System maintient une qualité élevée et une cohérence dans tous ses composants. Établissez des normes et des directives claires pour la conception, l'accessibilité et l'utilisation du Design System. Effectuer des audits réguliers pour identifier et corriger les problèmes éventuels.

📊 Recueillir les commentaires des utilisateurs : Mettre en place des mécanismes de collecte de commentaires des utilisateurs sur le Design System. Utiliser ces informations pour améliorer continuellement le système, en prenant en compte les besoins et les suggestions des utilisateurs.

🔁 Évoluer et itérer : Considérer le Design System comme un projet évolutif et itératif. Accepter les retours d'expérience et les leçons apprises pour améliorer continuellement le système.