Margaux Perrin — 1- L’avantage de combiner les rôles de PO & UX

Product Design : du Discovery au Delivery, comment concilier UX et agilité ?

Episode 1 avec Margaux Perrin : l’avantage de combiner les rôles de PO et UX

Romain : Bienvenue dans notre série d’interviews qui vise à explorer les métiers de l’expérience utilisateur (UX, ergonomie, design d’interfaces) et de l’agilité, en creusant plus particulièrement le rôle combiné de PO et UX. Nous recevons aujourd’hui Margaux Perrin, consultante UX, Ergonome et Product Owner au sein de Sogilis, responsable de l’offre uxShadow.

Bonjour Margaux, pourrais-tu te présenter, qui es-tu et que fais-tu ?

Margaux : Bonjour Romain, je suis Margaux Perrin, je travaille à Sogilis depuis six ans en tant que UX Designer, UX Researcher et avec parfois la casquette de proxy PO. Dans ce cadre là, je travaille avec différents clients dans différents secteurs d’activité. Avant ça, j’ai travaillé pendant deux ans chez un éditeur de logiciels avec les même rôles. Et encore avant, j’ai fait des études en neurosciences : je viens d’un parcours en biologie et neurosciences cognitives, avec une thèse sur les interfaces cerveau-ordinateur qui m’a donné envie d’aller travailler sur des choses concrètes et appliquées en lien avec l’expérience utilisateur et son optimisation.

R : Merci pour cette introduction. Alors si on fait un focus plus particulier sur l’UX, un terme qu’on entend beaucoup avec des significations parfois différentes. Qu’est ce que c’est pour toi être UX designer ?

M : Alors quand je me définis comme UX Designer, derrière ça j’entends différentes sous-parties que sont l’UX Research, l’UX Design et la partie test / évaluation d’interface. Donc pour moi, le design comprend tout ça.

Aujourd’hui en France, il est assez courant d’entendre le terme “UX design” seulement pour la partie design d’interface. D’ailleurs il y a beaucoup de personnes qui se disent “UX/UI designer” et qui se focalisent sur cette étape de design d’interface. Dans ma pratique, je comprends aussi les autres parties, c’est-à-dire tout ce qui concerne le recueil du besoin utilisateur, la compréhension du contexte dans lequel le produit va être utilisé, les contraintes des utilisateurs, leurs besoins, leurs problèmes. Et donc ça, c’est en amont de la partie conception, de ce qu’on appelle le “maquettage basse fidélité”.

Je ne fais pas du tout la partie “maquettage haute fidélité”, qui est ce que j’appelle moi l’UI design” : j’ai des collègues qui font ça très bien, c’est vraiment des compétences différentes que je n’ai pas.

Ensuite, une fois qu’il y a quelque chose de bien propre — ou pas forcément d’ailleurs, ça peut être juste sur des maquettes basse fidélité- j’évalue la pertinence de ce qu’on a proposé à travers des tests utilisateurs ou des questionnaires. Cette étape peut également arriver en amont, s’il y a déjà un existant. Dans ce cas je peux par exemple faire un audit UX et des recommandations d’améliorations. Et donc voilà, pour moi, il y a tout ça dans mon métier.

R : Ce qui est intéressant, c’est que dans la manière dont tu parles du métier, on voit bien que c’est un rôle qui intervient à différentes étapes d’un projet. On pourrait même dire tout au long d’un projet, avec ce avant, pendant et après dont tu as parlé, le avant avec la recherche utilisateur, la qualification du besoin, le pendant, avec la conception des utilisateurs, le dessin des écrans et le après pour tester avec les utilisateurs, pour évaluer ce qu’on a pu dessiner.

M: Je rajouterais peut être d’ailleurs une petite partie dont je n’ai pas parlé qui est le pendant le développement. Même quand il y a un Product Owner déjà en place, pour moi c’est vraiment important d’être présente pendant le développement pour répondre aux questions des développeurs, pour vérifier qu’une fois que chaque User Story est développée, ça correspond bien à ce que j’avais en tête, qu’il n’y a pas des cas que j’avais oubliés de concevoir, et qui du coup ne sont pas gérés, ou alors qui ne correspondent pas aux bonnes pratiques d’ergonomie.
Donc ça c’est quelque chose qui est important pour moi, de même que le fait d’aller faire des tests utilisateurs une fois que le produit est développé, parce que ce n’est jamais pareil de tester des maquettes ou une vraie application développée.

R : Merci effectivement pour cette précision. Avec le recul que tu as sur cette pratique, quelle est pour toi la valeur qu’apporte dans un projet cette démarche UX, cette démarche centrée utilisateur?

M: Pour moi la valeur que ça apporte c’est de s’assurer du mieux qu’on peut — on ne sera jamais sûr à 100 % mais de se rapprocher au maximum de la certitude — que le produit va répondre aux besoins et aux attentes des utilisateurs.

En termes fonctionnels, à travers toute la partie exploration des besoins : quels sont vraiment les besoins des utilisateurs ? Qu’est ce qui va leur être utile ?

Et d’un point de vue utilisabilité, grâce aux bonnes pratiques qu’on connaît et qu’on maîtrise quand on fait ce métier.

Donc s’assurer d’avoir quelque chose qui va être “utile et utilisable, donc utilisé”, la fameuse phrase d’uxShadow.

Du coup, grâce à ça, on va réduire les allers-retours entre les gens du métier et les développeurs. On va réduire les frustrations entre ces deux équipes. Parce que quand le métier fait des demandes qui ne sont pas forcément très claires, très bien exprimées, et que le dev interprète, forcément il va y avoir des incompréhensions. Donc le travail de l’UX, ça va être d’aller vraiment creuser les besoins derrière les demandes. Parfois, il y a des solutions qui sont exprimées par une équipe plutôt que des besoins. C’est notre rôle d’aller creuser les vrais besoins, de les comprendre profondément, et d’imaginer la meilleure solution pour répondre à ces besoins-là.

Donc normalement on a moins d’allers-retours et de frustration du type “oui ça répond à mon besoin mais ce n’est pas utilisable”, ou à l’inverse “utilisable mais ça ne répond pas à mon besoin”. On réduit donc le temps et le coût de développement en allant directement vers une solution utile et utilisable.

R : C’est intéressant parce qu’on voit qu’on gagne sur tous les tableaux. Finalement, on gagne sur la vitesse d’exécution, d’apporter plus rapidement de la valeur aux utilisateurs, et on garantit que ce qu’on propose aux utilisateurs leur apporte effectivement de la valeur d’usage et qu’on ne tombe pas à côté de la cible qu’on a imaginée.

Quels sont les obstacles, les challenges que tu rencontres pour mener à bien cette démarche UX ?

La plus grande difficulté est souvent le fait de rencontrer vraiment des utilisateurs : selon les clients et le contexte, c’est parfois difficile. Il y a des clients qui ne veulent pas qu’on aille au contact de leurs utilisateurs pour des raisons stratégiques. Donc on est obligés de se contenter “d’utilisateurs” qui ne sont pas des “vrais” utilisateurs finaux. C’est un peu frustrant pour nous. Ou à l’inverse des clients qui sont très engagés, qui sont très ouverts à ça, mais pour lesquels on a du mal à trouver leurs utilisateurs finaux, à les capter, à les faire participer.

Il arrive aussi parfois que le produit qu’on a imaginé, même s’il est utile et utilisable, ne rencontre pas son marché. C’est la dimension plus émotionnelle, c’est plus difficile à évaluer, de s’assurer que ça va “matcher” d’un point de vue marché, marketing, plaisir et enthousiasme utilisateur.

R : Oui, effectivement, l’adoption d’un produit s’appuie aussi sur d’autres mécanismes : émotionnels, positionnement concurrentiel, accueil par le marché…

Alors si la phase de Discovery répond bien au besoin de recueil et de qualification des attentes utilisateurs, qu’en est-il du Delivery ? Tu as parlé tout à l’heure de l’intégration auprès des développeurs : quand il s’agit d’accompagner la réalisation, il arrive parfois que les contributeurs UX ne soient pas forcément intégrés au sein d’une équipe, ou intégrés que partiellement. C’est vrai que Scrum, par exemple, décrit très précisément comment intégrer des développeurs, comment développer des fonctionnalités, mais pas vraiment comment intégrer la dimension expérience utilisateur ? Tu pourrais nous en dire plus sur cette situation ? Comment tu la vis de ton côté ?

Oui, c’est quelque chose effectivement que j’ai constaté depuis le début de ma pratique.

Quand j’ai commencé ce métier, je suis arrivée directement dans une équipe agile, très bien coachée. Je n’y connaissais rien à l’agilité, mais on m’a expliqué et ça m’a emballé sur le principe. Le côté itératif, tester souvent, aller souvent au marché, ça collait vraiment bien. Le côté orienté utilisateur aussi, la formulation des User Stories en soit, est un bon signe pour nous.

Mais effectivement, l’intégration dans les sprints de la personne qui fait la conception n’est pas du tout définie et pas simple à mettre en place. Il y a beaucoup de contraintes.

Ce qui est compliqué c’est que si on fait de la conception très en amont, finalement on retourne dans un cycle en V, avec tout un cahier des charges très précis, et puis le temps que ce soit développé, ce n’est plus forcément d’actualité. Si on fait la conception pendant six mois avant de développer, souvent, ça tombe un peu à côté.

Et puis même pour nous, UX designer justement, si on veut être intégrés dans le développement, que les développeurs puissent nous poser des questions, interagir et compléter des choses auxquelles on aurait oublié de penser au moment de la conception : c’est très compliqué si on a fait le travail six mois à l’avance, de se souvenir pourquoi on a fait tel choix de conception, quelle serait l’alternative si techniquement c’est trop complexe…Ça pose plein de problèmes, donc c’est clairement pas la bonne solution.

Ce que j’ai pu tester, c’était d’avoir un sprint d’avance. J’ai testé aussi zéro sprint d’avance, de faire la conception au début du sprint, mais ça je ne le recommande pas [rires] Ou pire, un sprint de retard, c’est-à-dire que les développeurs développent ce qu’ils ont en tête, et puis derrière ils le montrent et là éventuellement on fait des propositions de corrections. Là on est clairement pas dans dans l’optimisation du développement ! Les développeurs ne peuvent pas du tout estimer ce qu’ils pourront réaliser, et après coup, il y a du travail de dev à refaire, à défaire.

Enfin si c’est un sprint d’avance, c’est un peu mieux, mais c’est souvent trop court. Si on fait juste la partie UX/UI design, du maquettage pur et dur, ça va, en général on peut s’en sortir à peu près. Et encore, c’est quand même court un sprint, pour peu qu’il y ait des allers-retours avec le PO, le métier, etc.

Mais si on a une vraie démarche UX, d’aller faire un petit peu d’exploration, ça ne prend pas du tout 2 semaines. Même si en général le gros de l’exploration est fait en début de projet, quand il y a des nouvelles demandes qui arrivent, on a parfois besoin d’aller refaire un peu cette phase de Discovery, d’aller faire 1 ou 2 interviews pour comprendre quel est le besoin dans ce cas précis, de faire éventuellement un atelier de co-conception avec les utilisateurs, le client ou le PO, pour être sûr d’avoir bien bien compris le besoin et ne pas partir dans une mauvaise direction.

Puis derrière, il faut faire le maquettage basse fidélité, le maquettage haute fidélité, et il y a des allers-retours parce que ça ne correspond jamais à 100 % du premier coup.

Si on veut en plus faire des tests utilisateurs sur maquette, c’est vraiment impossible en un sprint. Ça dépend de la taille de la fonctionnalité, mais l’ordre de grandeur, c’est plutôt entre un et deux mois.

Donc pour moi, la bonne pratique, c’est d’avoir au moins deux sprints d’avance.

Sur des choses un peu plus grosses, d’être même encore un petit peu plus en amont.

Ça implique que la personne qui priorise le développement ait cette vision à un ou deux mois d’avance. Et de la dispo aussi pour à la fois participer à nos ateliers de conception, et en même temps gérer le développement, et en même temps éventuellement aller chercher des financements dans le cadre d’une startup. Ça fait beaucoup beaucoup de choses sur cette même personne.

R : Alors c’est intéressant parce que spontanément tu t’es mis à parler du rôle de Product Owner qui a un rôle clé au sein de l’agilité, avec la notion de pouvoir se projeter sur un ou deux sprints d’avance, voire plus, de prioriser les fonctionnalités qu’on va développer en premier, et puis de les spécifier précisément pour pouvoir mieux les estimer. Du coup, c’est un rôle que tu as aussi porté. Pour toi, qu’est ce que c’est être Product Owner ?

Alors pour moi, le rôle de Product Owner c’est d’abord avoir la vision du produit, savoir dans quelle direction il doit aller, ce qu’on développe, dans quel ordre, avec cette notion de priorisation qui est très importante. Pour cette partie-là, il y a beaucoup d’interactions avec d’autres parties, des équipes métier, du marketing, des investisseurs et plein de choses qui gravitent autour et qui vont orienter cette vision et ces décisions.

Et après, il y a une partie plus terrain, qui est au quotidien avec les développeurs : gérer le backlog, s’assurer que les User Stories sont suffisamment bien découpées, bien définies, estimées… Et donc être au quotidien avec les développeurs pour répondre à leurs questions, si jamais dans les specs il y a des choses qui ne sont pas claires.

Et c’est amusant parce que j’en parlais hier avec un collègue qui trouve que c’est vraiment intéressant de séparer ces deux métiers, ce que moi j’appelle plutôt “PO” et “proxy PO”. En tout cas, cette dissociation, on se rend compte qu’elle est assez courante au final, même si dans le Scrum guide, c’est une seule personne qui fait tout ça. Dans la réalité, c’est quand même compliqué parce que c’est des compétences un peu différentes, des appétences différentes, d’avoir ce côté très vision et ce côté plus terrain au quotidien.

La personne qui est plus sur le terrain, elle doit parler, entre guillemets, “le langage des développeurs”, être bien compréhensible pour les développeurs. Alors que la personne qui est plus sur la vision, elle peut être un peu plus créative, un peu plus fouillis dans ses idées. Tant qu’à la fin, elle sait à peu près ce qu’elle veut et qu’elle arrive à le faire passer à quelqu’un d’autre, elle n’a pas besoin d’être hyper précise dans les besoins techniques et fonctionnels. Donc voilà, je trouve ça intéressant de séparer les deux rôles au final. Et c’est ce qu’on fait quand on prend cette casquette de “proxy PO”.

R : D’accord, tu veux dire que dans un contexte de service (ESN), le rôle de “Product Owner” (dans le sens de Product leader, celui qui a la vision du produit), va être porté plutôt chez le client, et toi, en tant que consultante, tu vas porter plutôt le rôle que tu as appelé le rôle de terrain, le rôle opérationnel de “Proxy-PO”, c’est bien ça?

M: C’est ça.

R: Quelles difficultés ça pose pour toi le fait de dissocier ces deux rôles ? De faire porter ces deux rôles par deux personnes différentes ?

Je ne sais pas. Je trouve que ça fonctionne bien en fait. Peut-être la difficulté, s’il y en avait, ce serait si la personne qui a la vision n’a pas assez de dispo pour fournir les infos nécessaires à la personne qui est sur le terrain. Parce qu’il y a besoin quand même d’une grande communication entre les deux, c’est vraiment important. Mais sinon, pour moi, c’est quelque chose qui fonctionne bien de séparer ces deux rôles au quotidien.

R : OK. On a vu que tu avais une casquette UX, que tu pouvais aussi avoir cette casquette proxy PO. Si on parle maintenant de la combinaison de ces deux rôles : PO & UX, Product Owner & User expérience. Selon toi, quel est l’intérêt de cumuler ces deux casquettes sur un même projet ?

Alors ce qui est intéressant dans le fait de cumuler ces deux casquettes, c’est que, en tant que UX qui a fait cette partie que j’appelle UX Research, l’exploration pour aller au contact des utilisateurs pour vraiment comprendre leurs besoins, leur contexte, etc., et qui a fait aussi la partie UX Design, de conception, on a déjà toutes les informations pour compléter les User Stories.

Il manque parfois des règles métiers un peu techniques, et c’est là qu’on va avoir besoin de retourner voir le métier ou le Product Leader qui pourrait compléter ces choses-là. Mais sur la partie besoins fonctionnels et sur la partie détails des interactions, on a déjà toute la connaissance, donc on gagne vraiment du temps à ne pas devoir la transmettre à quelqu’un d’autre, et que ce quelqu’un d’autre écrive le ticket à notre place.

R: Est ce que tu pourrais nous donner un exemple de projet sur lequel ça, ça a apporté de la valeur justement?

Oui, le projet sur lequel je travaille en ce moment, je pense que ça apporte beaucoup de valeur. C’est un projet industriel qui en l’occurrence n’est pas vraiment structuré en Scrum ou même “agile” de manière très rigoureuse, mais qui fait quand même des sprints, avec des User Stories et une équipe de développement qui attend des specs pour se structurer.

D’ailleurs, initialement, c’est comme ça que je suis arrivée sur le projet. Le besoin exprimé, c’était quelqu’un qui faisait des maquettes et de la spec parce qu’ils sentaient qu’ils manquaient de structuration dans l’écriture des demandes de développement. Et en fait toute la partie UX un peu plus poussée est arrivée en plus, en bonus, et ça leur a bien plu. Mais ce n’était pas forcément la demande initiale.

Et donc, pour ce client-là, le Product Manager justement, il a une vraie vision, qui est très claire, et qu’il arrive bien à prioriser de manière macro. Par contre sur le côté terrain, opérationnel, il n’a pas la dispo, ni l’intérêt je pense, d’aller vraiment dans ce niveau de détails. Ça ne correspond pas à sa personnalité. Et puis il a aussi plein d’autres missions par ailleurs qui font qu’il n’a pas le temps de se pencher là-dessus.

Donc ça lui va bien de me donner la direction en termes de priorisation macro et de besoins utilisateurs. Et derrière, je vais creuser à la fois l’aspect UX, je lui fais valider mes maquettes (de manière assez macro, il ne va pas aller dans le détail de l’ergonomie, il me fait confiance là dessus), et je vais écrire les User Stories. Puis les discuter avec les développeurs, les redécouper quand nécessaire et les affiner aussi. Et tout ce travail-là, ça ne fait pas gagner du temps directement au Product Manager — puisqu’il ne le faisait pas avant, mais ça fait gagner de l’efficacité à l’équipe : d’avoir un travail bien fait et de démarrer le sprint avec des demandes claires.

R : Merci pour cet exemple très concret, on voit bien la valeur apportée.
Est-ce qu’il y a une difficulté à combiner ces deux rôles au quotidien ?

Il peut y avoir une difficulté quand on est sur des projets où il y a une forte pression sur le temps : “Il faut livrer à telle date” par exemple. Pour moi, la difficulté dans ce cas-là, c’est que même si les rôles d’UX et de PO sont cohérents sur beaucoup de choses, il y a une petite différence : l’UX va toujours faire passer l’utilisateur en premier, alors que le PO va faire passer le client en premier.

Là, si c’est la même personne, ça peut créer des dissensions entre les deux casquettes, cela peut créer des gros dilemmes. Mais de toute façon, dans ces contextes-là qui sont très tendus d’un point de vue timing, c’est toujours le PO qui tranche.

Quand les rôles sont dissociés, en tant qu’UX, je vais faire des recommandations au PO de ce qui me semble vraiment important à régler comme bug, à améliorer, mais c’est le PO qui va décider in fine si on fait d’abord telle fonctionnalité, si on va plutôt développer une nouvelle fonctionnalité que d’améliorer telle autre etc.

Donc quand j’ai les deux casquettes, je vais avoir tendance à prioriser les choses qui sont vraiment indispensables pour la livraison, donc privilégier le rôle de PO finalement, puisque c’est le PO qui tranche.

Par contre l’avantage d’avoir ces deux casquettes, c’est que je peux aussi décider que même avec une date de livraison très importante, tel élément d’UX doit vraiment passer d’abord. Et ça, c’est quand même assez agréable d’avoir la main là-dessus et de pouvoir décider d’avoir ce petit curseur, de choisir là où on fait le compromis en fait. Et les compromis que je vais souvent faire, c’est de se dire que tout ce qui est de l’ordre de l’amélioration, qui va faire une meilleure expérience mais qui n’est pas indispensable, je vais le repousser un peu après cette deadline très forte.

Mais je m’assure qu’avant la deadline, il y ait vraiment le minimum et suffisant pour que l’expérience utilisateur, elle, soit quand même fluide et sans blocage, sans grosse incompréhension. Donc en fait, j’arrive, grâce à ma connaissance du métier et des règles d’ergonomie, à dissocier les fonctionnalités qui sont vraiment indispensables pour une première livraison de celles qu’on pourra faire après.

R: Oui, c’est un peu un équilibrage entre 2 valeurs différentes : la valeur client (business) et la valeur utilisateur (l’expérience). C’est intéressant parce que dans une démarche agile “classique”, on équilibre la valeur d’un côté et la complexité de l’autre et on essaie de prioriser en cherchant ce qui a le plus de ROI (Return On Investment). Là, on vient questionner la notion de valeur : finalement, cette valeur, elle est multiple, multidimensionnelle. On a la valeur qu’on apporte effectivement à son client, à l’organisation, au business, mais aussi la valeur qu’on apporte à l’utilisateur final. Dans ce que tu décris, on garantit qu’on considère bien ces deux valeurs : elles sont décrites, estimées et exprimées au sein du backlog, même si ce n’est pas toujours facile d’arbitrer dans le sens de l’une ou de l’autre.

Est ce que tu aurais des conseils à donner à ceux qui souhaiteraient se lancer pour porter ces deux rôles ?

M : Sur cette partie un peu “double casquette” parfois difficile à concilier, le conseil que je donnerais, c’est de se poser et de faire une liste des éléments qui selon nous sont vraiment indispensables pour une UX minimale, et le mettre directement dans les specs des User Stories.

Par exemple, pour moi, ce qui est le plus important, ça va être la gestion des erreurs, parce que des erreurs mal gérées peuvent nous bloquer dans notre parcours utilisateur. Donc pour la gestion des erreurs, on ne fait pas un ticket à part qui risque de glisser dans le sprint d’après, puis d’après, puis finalement ne sera jamais fait. On le met directement dans le ticket story de base. La gestion d’erreur fait partie de la valeur apportée par la fonctionnalité.

Par contre, il y a d’autres choses qui apportent seulement du bonus. Je pense par exemple à avoir des raccourcis clavier pour faire une fonctionnalité. On pourrait avoir tendance à le mettre dans la spécification de la fonctionnalité (ex: Ctrl + N pour ouvrir la fonctionnalité). Ça pour le coup, j’aurais tendance à le redécouper et à dire “ça peut venir plus tard”.

Donc ce qui est important, c’est d’apprendre à faire ce découpage et d’être à l’aise avec. Ne pas se sentir frustré en tant que UX parce qu’on a tellement redécoupé que finalement il n’y a plus que du pur fonctionnel et pas du tout une bonne expérience utilisateur. Cela m’avait aidé au début de faire la liste des critères de Bastien Scapin et de me poser la question lesquels sont indispensables à mettre dans ma user story de base, et puis lesquels je peux redécouper et mettre dans des user story à part.

R : Oui, ça a vraiment du sens. On retrouve cette logique itérative : plutôt que de passer six mois à designer une interface optimale qui ne sera peut être jamais conçue telle quelle, c’est intégrer cette idée de critères d’acceptation qui ne soient pas uniquement fonctionnels, mais qui soient des critères d’acceptation “d’expérience”, des critères d’acceptation UX qui permettent de valider qu’une fonctionnalité donnée est DONE parce qu’elle atteint une expérience cible minimale. On pourrait presque parler, comme on parle de MVP (produit minimum viable), d’”expérience utilisateur minimum viable”.

M : Oui, et d’ailleurs ça me fait penser à quelque chose qui est peut-être une des difficultés aussi de ce rôle combiné, c’est de passer de la maquette à la User Story et de penser au maximum de cas possibles. On ne pensera jamais à tout, mais essayer de lister tout ce qui est de l’ordre de l’UX et qui risquerait d’être oublié par les développeurs si on ne le fait pas. Je pense à la gestion des erreurs, au fait de pouvoir annuler, revenir en arrière. Tout ce qui est de l’interaction, et la gestion des cas particuliers. Qu’est-ce qui se passe quand il n’y a pas encore de contenu par exemple, ou quand il y en a trop, ou pendant le chargement. Donc, tous ces états-là, bien penser à les décrire et les discuter avec les développeurs. Et en fait, ce qui est important, c’est d’avoir une équipe de développeurs qui est sensibilisée, qui comprend l’intérêt de l’UX et de l’ergonomie, et qui du coup va avoir le réflexe de venir vers nous s’il manque une de ces informations.

R : Est ce que tu aurais des conseils à donner aux entreprises qui souhaiteraient être accompagnées dans ces démarches centrées utilisateur, dans ces démarches agiles, une entreprise qui a un projet de refonte de son outil existant ou de création d’un nouveau produit numérique. Quels conseils tu donnerais à ces organisations ?

M : De se faire bien accompagner, d’avoir les bonnes compétences. Typiquement, on a des entreprises qui vont faire appel à des personnes aux profils UX/UI, qui sont des profils supers intéressants mais qui parfois ne maîtrisent pas cette partie UX Research, évaluation, et testing. Du coup d’avoir bien les deux : par exemple une personne qui va se concentrer sur l’UI design et une autre personne qui fait plus la partie recherche en amont et tests en aval. C’est ce qui nous assure d’avoir in fine quelque chose qui sera vraiment adapté aux usages et utilisable. Et s’il manque une partie, il va y avoir un trou dans la raquette, il va y avoir un manque de compréhension des besoins et ça s’en ressentira sur le produit fini.

R : Ce qu’on voit, c’est qu’il y a besoin d’un grand nombre de rôles dans une équipe de design et développement d’un produit ou service digital. Que ces rôles sont différents, qu’ils peuvent être complémentaires et qu’il y a un vrai besoin d’animation de cette équipe pluridisciplinaire. Pour toi, quel est le rôle du PO/UX dans l’animation d’une telle équipe, dans la coordination de ces différents rôles ?

M : Quand je prends ce rôle-là, je vais souvent au-delà de la partie purement opérationnelle, gestion du backlog : je peux prendre ce rôle d’animation, surtout quand il n’y a pas de Scrum Master dans l’équipe du projet. Ce rôle d’animer les réunions, d’être le lien et le contact privilégié avec le client, c’est souvent moi qui le porte dans le contexte d’une prestation, mais ça ne fait pas forcément partie du rôle “PO/UX”.

Typiquement ce serait bien d’avoir un Scrum Master qui irait encore au-delà. Parce qu’il y a toute une partie que je ne fais pas, par exemple s’assurer que les rituels sont bien mis en place, aider à lever les problèmes quand il y en a, éviter les interruptions de l’équipe de dev. Ça peut m’arriver de le faire quand vraiment un problème me saute aux yeux, mais je considère que ce n’est pas vraiment mon rôle.

R : Un mot de la fin pour conclure notre interview : si tu avais un seul message à transmettre à celles et ceux qui nous lisent, quel serait-il ?

M : Mon premier réflexe, c’est “intéressez-vous à vos utilisateurs”, ça c’est évidemment la base pour le côté UX. En fait, l’expérience utilisateur est partout. Les développeurs qui consultent les User Stories pour essayer de les développer, ils vivent aussi une expérience utilisateur, et c’est là que le rôle du Product Owner est important pour favoriser cette expérience utilisateur là. Avoir ce rôle combiné, je pense que ça favorise l’expérience utilisateur des développeurs dans leur quotidien et je trouve ça assez intéressant de réfléchir aux expériences de nos collaborateurs finalement, et pas seulement à celle des utilisateurs finaux de nos produits.

Merci beaucoup à Margaux pour son temps et son partage.

Pour aller plus loin :

• suivre Margaux sur LinkedIn :
  https://www.linkedin.com/in/margaux-lergo/
• prendre RDV pour échanger avec Romain : https://calendly.com/romain-chabbal-uxshadow/ameliorer-ux