Once upon a time, the story of the battle between PO and UX

Le point de vue partagé dans l’article ci-après est le reflet d’observations partielles, partiales au cours de mes différentes missions depuis plus de 6 ans.

Au sein des équipes projets (web et/ou app), il y a une bataille qui fait rage. Celle entre les PO et les UX. Une bataille qui met en exergue la méconnaissance des deux parties du métier de l’autre et le manque de maturité en management projet.

Mon article n’apporte pas de réponse définitive mais ouvrira, je l’espère, des portes, espaces de discussion.

PO et UX : Qui est-ce ?

Ces deux profils se retrouvent généralement dans des projets numériques en mode Agile.

Un Product Owner (PO) est un membre permanent de l’équipe projet. Sa mission : définir un produit qui apportera le maximum de valeur métier aux utilisateurs dans le temps et le budget impartis au projet.

Un UX Designer n’est pas nécessairement un membre permanent de l’équipe projet. Sa mission : rendre un produit/service utile et utilisable et créer une expérience mémorable pour les utilisateurs de ce produit/service

Dans le cadre d’un projet quelles sont les combinaisons organisationnelles possibles :

  • L’UX sous le PO — la combinaison classique

Cette configuration induit en fonction des personnalités, de l’expérience du PO,…, un lien hiérarchique entre les deux parties. Ce qui n’est pas forcément le cas (ce point pose le cas du rattachement hiérarchique différent du rattachement fonctionnel). Dans ce cas, le PO a tendance à définir sans consulter l’UX en amont les tâches de ce dernier. Pré-découpage des travaux et parfois, donne immédiatement la solution. Ce contexte positionne l’UX dans un rôle d’exécutant et bride beaucoup ce dernier.

  • Le PO coaché par l’UX — la combinaison la plus rare

En quoi consiste ce coaching ? C’est l’UX qui connait la vision cible et définit avec le PO le chemin pour aller vers cette vision cible. Dans la mesure où l’on est dans un système Agile. Cette vision peut être revue dans le temps. Cette configuration frustre énormément les POs. Ils ont le sentiment que la construction de la vision produit leur échappe et peut les réduire à la rédaction d’US.

  • Le PO et l’UX sur un pied d’égalité — j’en parle plus bas.

Le problème du POUX — Recouvrement de compétence

Assez régulièrement, l’UX et le PO se retrouvent dans des situations de recouvrement des compétences. (quelques articles ici, ici ou encore ici) Néanmoins, si les deux métiers sont complémentaires et ont des points communs. Ils sont très différents.

Ce qu’un UX et PO peuvent avoir de commun :

  • Une solide connaissance du produit
  • La communication autour des évolutions
  • La coordination d’équipe
  • La gestion d’un planning
  • Assurer un delivery

Ce qui est différent côté UX

  • La coordination d’équipe sera celle d’une équipe de type UI, UX ou UI, UX, Dév Front
  • La gestion du planning sera celui des UI et UX ou UI, UX, Dév Front
  • Définition des parcours utilisateurs, réalisation de Journey Map
  • Définition de personas ou proto-personas
  • Le delivery sera celui associé à la production graphique et la bonne intégration des composants.
  • La gestion des campagnes de tests (Test A/B, Focus Group, Interview, Guerrilla Testing…)
  • Le suivi des KPIs lié à l’expérience des utilisateurs

Je ne fais pas ici mention des aspects de charte, définitions graphiques, d’interactions qui sont propre à l’interaction design (composante de l’UI). Point qui ne sont normalement pas du ressort de l’UX Designer mais il peut coordonner cette partie.

Ainsi même si le PO a besoin de l’UX, il ne peut être UX. Sa présence auprès des autres membres de l’équipe projet est précieuse. C’est une activité qui est également chronophage. De la même manière l’UX ne peut être PO. L’UX n’a pas vocation à coordonner l’intégralité des métiers présents sur un projet. Dans les deux cas, les deux parties sont perdantes et n’assument pas pleinement leur rôle lorsqu’elles interviennent sur le périmètre de l’autre.

Ce recouvrement de compétences appelle également des questionnements sur l’ownership. Qui est owner de quoi ? C’est pour moi un faux problème qui pose par contre un vrai point sur la vision que chaque partie peut avoir d’un produit/service.

Un UX Designer peut intervenir sur un produit/service dans sa globalité. Un PO intervient sur un projet qui est tout ou une partie d’un produit/service.

Concrètement et pour exemple : 
Je suis une société qui propose un service de ticket restaurant.
Dans mon équipe, je peux avoir un UX pour la définition de l’expérience sur l’app et le web pour les utilisateurs des tickets restaurants et les professionnels qui chargent les comptent de leurs employés. Je peux avoir un PO associé à la partie paiement, un PO selfcare particuliers, un PO selfcare professionnels.

Cette dimension macro vs micro peut être une source de frustrations et d’incompréhensions.

La voix des utilisateurs et utilisabilité

Le Product Owner, dans un modèle d’organisation Agile, va s’appuyer sur les retours utilisateurs pour vérifier que la valeur délivrée est bien celle attendue. Cela lui permet également d’identifier des axes d’optimisation. C’est peut-être le plus gros points d’incompréhension sur les deux métiers.

Au démarrage de l’implémentation des méthodes Agile, le rôle de l’UX n’était pas identifié ou exprimé clairement. Ainsi je préciserai le point de la manière suivante. C’est au PO d’anticiper son besoin de disposer de retour utilisateurs et de demander à l’UX d’organiser cette partie-là. L’UX aura alors à charge de lui donner de la visibilité sur ce point. Il est plus facile d’identifier au démarrage du projet les points qui devront être vérifié quantitativement (au travers de tests A/B par exemple) ou de chercher à mieux connaître la perception des utilisateurs de notre produit/service (test qualitatif).

De la même manière un Product Owner est garant de la mise en oeuvre et du bon fonctionnement du produit/service. L’UX est garant de l’utilisabilité du produit/service. J’entends déjà des PO me dire : “Nous sommes aussi garant de son utilisabilité !

Pas de l’utilisabilité en tant que tel. Le Product Owner s’assure que le produit soit fonctionnel, utilisable. L’utilisabilité, c’est l’aptitude à atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d’utilisation spécifié. C’est un des paramètres, indicateurs d’une bonne expérience avec un produit/service. C’est l’UX Designer qui analyse ce point.

Peut-être que comme moi, vous voyez de plus en plus la complémentarité et la transversalité des deux rôles.

Pistes de solution

Mon premier point serait de dire qu’un UX Designer intervenant sur des projets Web ou App se doit aujourd’hui de maîtriser l’Agile. C’est ainsi qu’il saura trouver sa place au sein de l’équipe. Cela pourra passer par l’ajout d’un bloc Design dans le Kanban de l’équipe, définir avec le PO le DOD de la partie Design (Définition of Done), s’appuyer sur les différents rituels pour faire entendre sa voix…

Mon second point serait qu’un positionnement avec le Product Owner et l’UX Designer sur un pied d’égalité serait la meilleure configuration. Chaque partie a besoin de l’autre. Chaque partie contribue à la construction de la vision produit. Chaque partie contribue à la création de valeur pour le produit/service. Cela demande de la part de chaque partie de la maturité quant à l’appréhension de leur métier et une bonne connaissance du métier de l’autre. C’est la configuration la plus délicate à mettre en place parce qu’elle demande une bonne entente entre les deux parties. Et ça, c’est de l’humain… Néanmoins pour l’avoir déjà vécu, c’est pour moi, la combinaison gagnante pour les équipes et le projet.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.