Marie-Cécile de la Taille — 3- La recherche utilisateur au service du Product

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

Episode 3 avec Marie-Cécile de la Taille : la recherche utilisateur au service du Product

Romain Chabbal : 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é, et plus particulièrement l’articulation des rôles de Product Owner (PO) et d’UX. Nous recevons aujourd’hui Marie-Cécile de la Taille, Senior UX Designer au sein de l’agence web lyonnaise ZOL.

Bonjour Marie-Cécile, pourrais-tu te présenter, qui es-tu et que fais-tu ?

Marie-Cécile de la Taille : Je suis UX Researcher, je travaille en tant que UX Designer senior dans une agence digitale à Lyon. Je fais beaucoup de research principalement et j’ai une approche très axée exploration et Discovery dans mon métier.

R.: Qu’est-ce que c’est pour toi la recherche utilisateur ?

M-C.: C’est comprendre pour qui on est en train de concevoir un nouveau produit ou un nouveau service.

Comprendre par qui il va être utilisé, et comment, dans quel contexte, pour donner des pistes de conception aux designers et à toute la partie produit, donc les développeurs et Product Owner. Je me vois donc comme un lien entre les utilisateurs et les équipes projet, les équipes de conception.

Observer la réalité pour amener du concret

R.: Quelle valeur cela apporte dans un projet ?

M-C.: Je pense que ça apporte du concret. C’est à dire qu’on va évidemment partir d’hypothèses, mais qu’on va chercher à les vérifier sur le terrain. Donc il y a cette notion d’amener du concret au démarrage d’un projet en étant vraiment observateur de la société et de la manière dont les gens vivent. Parce qu’on va s’insérer dans la vie des gens, que ce soit dans la vie professionnelle, avec des outils métier, ou dans la vie personnelle, avec des produits ou services de grande consommation B2C.

Du coup, c’est vraiment observer ces gens-là et les interroger pour recueillir leurs avis et leurs besoins. C’est presque une approche sociologique.

Comprendre les métiers pour aider à faire mieux et plus vite

Est ce que tu aurais un exemple concret à donner d’une étude utilisateur récente que tu as faite et de ce que tu as pu apprendre et partager avec les équipes produit ?

J’ai beaucoup travaillé notamment sur des outils métiers. Et ce qui est passionnant là-dedans, c’est qu’on est amené à chercher à comprendre ces métiers pour lesquels on est en train de travailler. Ce sont parfois des métiers qui sont complètement aux antipodes de nos métiers de designers. Et je trouve ça passionnant. Typiquement, dernièrement, je suis intervenue sur une mission pour une boîte américaine qui est un éditeur de logiciels dans le domaine de la construction, du BTP, et qui avait besoin de comprendre l’état du marché en termes de besoins de transformation numérique et de besoin d’outils digitaux.

On a fait toute une série d’interviews auprès de conducteurs de travaux, directeurs d’exploitation, les gens du terrain, du métier, les gens qui construisent les immeubles. Et on leur demandait de raconter leur métier : c’est à chaque fois une entrée dans un univers complètement différent.

Donc j’ai appris comment ça se passait concrètement en cas de projet de construction, notamment sur la question des choix des outils digitaux qui vont être utilisés pendant les chantiers, comment ces choix sont faits.
Il y a des questions d’habitude aussi, parce qu’il y a des personnes qui vont intervenir sur le chantier qui à part le téléphone portable n’ont pas vraiment l’habitude d’utiliser des outils numériques. Et puis, concrètement, ils sont en train de monter un mur ou de faire de la peinture. Ce sont des métiers où le digital s’inscrit difficilement.

Il y a toute une transformation de ce secteur-là qui est en train de se faire depuis une vingtaine d’années, mais qui est très lente en fait. Du coup, c’est intéressant de se poser la question de “est-ce qu’on a vraiment besoin de ces outils ?” et s’ils en ont vraiment besoin, “pourquoi ?” Cela va peut être ne concerner que des actions très précises et très concrètes, de gestion des équipes, gestion logistique, ce genre de choses.

Donc le but c’est de se demander où est-ce qu’on peut les aider : à faire mieux, à faire plus vite, à gagner en performance.

La recherche utilisateur au service de la conception

D’accord. Faire mieux, faire plus vite, gagner en performance, on voit bien la valeur que ça peut apporter. C’est ce que tu disais tout à l’heure, bien comprendre le contexte d’usage, se demander s’ils ont vraiment besoin d’outils supplémentaires et si oui, sur quel périmètre fonctionnel.

Quel type d’obstacles tu rencontres pour mettre en place cette démarche de recherche utilisateur ?

Le plus commun des obstacles qu’on peut rencontrer quand on essaye de mettre en place une vraie démarche UX avec une partie de recherche en amont, ce n’est finalement pas tellement du côté du client final (la personne qui va commander le produit ou service), c’est plutôt au niveau des équipes de conception elles-mêmes, parce qu’il y a encore plein de gens qui n’ont pas l’habitude de travailler de cette manière-là, d’intégrer ces données-là.

Ils vont avoir l’impression que cette phase de recherche va finalement ralentir la conception, que ça va prendre beaucoup de temps, que ça va coûter beaucoup d’argent.

Et donc se pose la question de “qu’est-ce que ça apporte réellement ?” dans un projet de conception qui a un planning et un budget limité. Les plus forts obstacles que j’ai pu rencontrer dans les différentes structures où j’ai pu travailler, que ce soit en ESN ou en freelance, c’est par rapport à cet enjeu de comment faire comprendre aux équipes qu’elles ont besoin de cette phase-là pour mieux concevoir.

Faire vivre la recherche utilisateur pour faire comprendre son ROI

Est ce que tu aurais des conseils à apporter pour mieux surmonter ces obstacles ?

La première chose qui aide, c’est quand les membres de la direction, plutôt à des niveaux stratégiques supérieurs, ont bien intégré l’apport, le ROI, des démarches de recherche utilisateur.

Ce qui peut être mis en place c’est de les intégrer dans des projets de recherche, pour qu’ils voient comment ça se passe. Par exemple, s’il y a des séries de tests utilisateurs, qu’ils puissent y assister, pour qu’ils puissent entendre et voir réellement comment ça se passe.

Ce que j’aime bien, c’est faire expérimenter pour faire comprendre la démarche et son utilité. Je pense que ça a un vrai pouvoir de persuasion quand on intègre quelqu’un dans cette démarche, pour qu’il puisse la vivre par lui-même ou elle-même.

Et du coup, il y a le “tilt” à un moment donné qui dit “ah oui, quand même, j’ai appris ça que je n’aurais pas pu apprendre autrement”.

Après, il y a aussi les équipes de développement qui sont souvent des équipes qui ont la tête dans le guidon, parce que sur un développement de produit il y a beaucoup de choses à faire et souvent ces équipes ne sont pas du tout intégrées en amont.

Ce qui peut être bien, c’est d’intégrer au moins un Lead Tech dans des ateliers de co-conception, dans toute cette réflexion en amont, autour de “quelles informations on a récoltées” et “comment est-ce qu’on en vient à prendre ces décisions-là en termes de conception ?” Ça, ça peut être une piste.

Après, évidemment, tout dépend de ce qu’il est possible de faire en termes de timing, de planning, de ressources. Voilà, ce sont les deux pistes que je peux donner. Et il y a probablement plein d’autres choses que je n’ai pas testées qui sont faisables

Une implication ponctuelle pour vérifier la qualité de l’implémentation

On a parlé de la recherche utilisateur, de ce que tu mets en place en amont, de la valeur que ça avait, des obstacles que tu pouvais rencontrer et les conseils que tu pouvais donner pour les surmonter.
Tu as commencé à parler des équipes de réalisation, des équipes produits : est-ce que tu restes impliquée dans la phase de delivery, dans cette phase de conception?

De manière très ponctuelle : surtout pour vérifier que les choix qui ont été faits en termes de parcours et d’ergonomie ont bien été respectés. Donc ça peut être de faire un peu de recette par exemple. Mais finalement, une fois que les choses sont bien posées en amont, je dirais que la présence du researcher n’est pas tellement requise sur la durée. Hormis de manière ponctuelle pour bien vérifier que tout est respecté.

Alors qu’est-ce qui est important pour toi, pour bien faire ce lien entre les enseignements que tu as tirés de ta phase de recherche et la phase de réalisation, pour qu’il n’y ait pas de déperdition d’information et pour que ce qui a été imaginé, designé, corresponde effectivement à ce qui sera livré et mis entre les mains des utilisateurs ?

Je pense qu’il y a deux choses. Il y a ce que je peux voir du produit qui est en train d’être développé en allant faire une recette ou un audit.

Et évidemment des tests utilisateur qu’on peut organiser de manière très régulière au fur et à mesure de la conception du produit, et qui permettent de s’assurer que l’on est toujours en phase avec les besoins des personnes pour lesquelles on est en train de délivrer justement.

Un risque de déperditions d’information entre l’UX et le Product Owner

Est-ce qu’il t’est arrivé pendant ces phases de recette au fil du développement ou pendant ces tests utilisateur de constater des écarts ?Tu peux nous donner des exemples où ce qui a été développé n’était plus complètement aligné avec ce qui avait été imaginé au départ ?

Des exemples? Oui. Alors je pense qu’il y a toujours un glissement. Même si on est dans des systèmes de production dits “agiles” dans lesquels on travaille en sprints sur des petites parties de produits, je dirais qu’il y a toujours une déperdition d’information, notamment au moment de la rédaction des user stories, où il peut y avoir des évolutions pour prendre en compte des contraintes et des besoins techniques. Et du coup, le risque c’est que ça n’évolue pas dans le bon sens.

Et donc effectivement, on parlait tout à l’heure de pouvoir garder un œil sur la phase de conception, je pense que typiquement à ce moment-là, c’est important que l’UX puisse être mis dans la boucle s’il y a besoin de revoir des choses pour des questions techniques. Et du coup, travailler main dans la main avec le Product Owner pour s’assurer que ce qui est décrit et ce qui est demandé corresponde réellement aux choix de parcours ergonomiques, de fonctionnalités et aux objectifs de “pourquoi est-ce que ces fonctionnalités on a décidé de les mettre dans le produit ?”.

Une documentation partagée et des relectures de backlog

Qu’est-ce que tu entends quand tu dis “travailler main dans la main” avec le Product Owner”, de quelle manière travailles-tu avec elle ou lui ?

Alors, ça ne va pas être d’écrire les user stories à sa place.

En tant que UX il y a de la documentation à apporter, avec les outils qu’on a à notre disposition ou qu’on peut mettre en place de nous même. Chaque personne a ses propres outils, sa propre manière de documenter ses choix.

Et cela peut aussi être faire une relecture de backlog avec le Product Owner de manière régulière, pour s’assurer que c’est sur les bons rails. Mais c’est vrai que je n’entends pas par là écrire les stories qui pour moi est le rôle du Product Owner.

C’est plutôt pouvoir l’aider, répondre à ses questions, lui donner suffisamment de documentation pour qu’il puisse rédiger ses stories.

Des échanges réguliers entre UX et PO pour aligner user stories et choix de conception

Est-ce que tu as un exemple concret de projet où tu aurais été impliquée plus fortement dans le delivery, dans la réalisation, et où tu as pu travailler avec un Product Owner?

A l’époque où j’étais en ESN, j’ai travaillé sur un projet de refonte assez long où il y avait un outil déjà existant mais qui datait un peu. On a tout remis à plat et on est reparti de zéro, mais l’objectif de l’outil restait le même.

Pour travailler là-dessus, j’étais intégrée dans une équipe avec une dizaine de développeurs, un Scrum Master, 2 PO qui était côté client, 1 proxy-PO qui était de notre côté, un UI et moi.

On se voyait deux fois par semaine avec l’UX et l’UI pour travailler avec les 2 PO et le proxy-PO sur la conception de cet outil.

Au démarrage il n’y avait pas de lead technique, alors on a fait en sorte que le Lead Tech intervienne aussi, en tant que responsable de l’architecture. On se regroupait pour discuter des propositions de user stories qui avaient été pré-écrites par le PO pour s’assurer que le besoin était bien compris et que la fonctionnalité décrite corresponde bien à nos choix de conception. Ensuite les PO et le proxy-PO finissaient la rédaction pour que ça rentre dans le backlog.

Des maquettes pour compléter les stories

D’accord. Est ce qu’il y avait une contribution aussi sous l’angle représentation visuelle de la story par exemple ?

Oui, on livrait des maquettes quasiment sur toutes les stories, à part celles très techniques.

C’était un travail assez lourd. Je ne sais pas s’il y a des équipes qui ont réussi à alléger cette partie-là, parce que finalement, des stories, ce sont des toutes petites parties d’un produit, alors que quand on travaille sur les maquettes d’un outil, on ne va pas juste maquetter cette petite brique : on reprend l’interface globale et on montre comment l’utilisateur interagit avec l’interface

Du coup on devait rattacher nos maquettes aux stories pour chaque petite brique et on se retrouvait avec une masse de maquettes qui évoluaient d’une story à l’autre, ce qui posait des questions de versionning.

Comment gérer ça pour que les maquettes soient bien à jour dans le backlog ? C’était un vrai besoin car c’était fortement demandé par les développeurs d’avoir des maquettes : cela leur permet de faire ce qu’ils voient et ce qu’ils lisent dans la story.

Zeplin pour gérer les versions de maquettes

Vous utilisiez un outil particulier, une méthodologie particulière pour adresser cette problématique de versionning ?

On a fini par travailler avec Zeplin. A l’époque, l’UI avec qui je travaillais faisait ses maquettes sur Sketch et il avait mis en place cet outil Zeplin, qui permettait de fournir aux devs front les maquettes des interfaces avec un certain nombre d’informations utiles comme le code CSS.

En plus cela permettait de ranger et nommer les maquettes : on avait défini une taxonomie et on avait créé des dossiers par grosse feature dans lesquels on utilisait les manières de nommer qui étaient utilisés dans le backlog pour que les dev puissent s’y retrouver “tout seuls”.

Donc on a fait ce travail-là de se dire “OK, comment est-ce que vous fonctionnez pour arriver à vous retrouver dans les stories ?” et “comment est-ce qu’on peut arriver à le traduire à travers cet outil sur la partie maquettes ?”.

On a tâtonné avant d’arriver là et ça a plutôt bien fonctionné je dirais, avec les limites que tout outil peut avoir, qui sont les limites propres à l’outil et aussi les limites humaines.

L’UX pourrait être davantage impliquée dans la priorisation

On a parlé de comment une fonctionnalité est décrite à la fois textuellement et visuellement, et de la valeur qu’elle apporte à l’utilisateur en lien avec le besoin auquel elle répond. Quelle est ta contribution pour la priorisation de l’ensemble des fonctionnalités dans un backlog ?

Ça dépend beaucoup du contexte d’équipe dans lequel tu travailles. C’est souvent des jeux de pouvoir, et donc le plus souvent c’est le PO qui priorise, avec les devs qui mettent des points de faisabilité ou de difficulté, et qui du coup ont un fort impact sur la priorisation de telle ou telle story, telle ou tel feature.
Après la roadmap au global, elle est souvent décidée par les PO
Moi de mon expérience, je n’ai jamais été beaucoup impliquée dans ces roadmaps, dans ces questions de priorisation. On ne m’a jamais vraiment demandé “est-ce que c’est prioritaire pour les utilisateurs ou pas ?” Ce qui est dommage parce qu’en tant que UX on peut aussi apporter des éclairages sur les choix à effectuer. Mais souvent ces choix appartiennent aux PO au final.

Quelle influence la recherche utilisateur permet-elle d’avoir sur le produit ?

Tu parles de roadmap globale : de quelle manière est-ce que tu t’appuies sur les enseignements issus de la recherche utilisateur pour venir influencer cette roadmap ?

Cela va surtout influencer les choix fonctionnels dans la conception.

Après la roadmap c’est plus un planning, un lotissement du produit. On prend le produit, on le découpe en lots, et puis on se dit, ça ça être le MVP, ça ça va être la version 2. Puis dans chaque lot, on va mettre des grosses priorités. La recherche utilisateur, elle va plus aider à concevoir l’outil global en fait.

Sur les différents projets sur lesquels je suis intervenu, il y a des projets pour lesquels les roadmaps étaient déjà définies. Donc mon rôle était plus d’apporter un regard sur telle ou telle fonctionnalité, agrémenté grâce à la recherche utilisateur. Quand on prend le temps de la faire, parce que quand on intervient sur ce type de projet déjà démarré, on ne prend pas toujours le temps de faire des recherches utilisateurs. Quand le projet est déjà bien avancé et qu’il y a des développeurs qui attendent qu’on les “nourrisse”, la recherche c’est ce qui “zappé” en premier.

Après j’ai pu aussi intervenir beaucoup plus en amont, avec un besoin qui était d’avoir une idée de ce qu’il faut faire comme outil et de brosser dans les grandes lignes le backlog initial. Quand tu interviens sur ce type de projet, tu n’as pas encore de roadmap parce que c’est juste un client qui vient te voir avec une problématique et qui dit “On pense qu’il faut un produit pour ça. Comment est-ce qu’on fait ?”.

Et du coup, la notion de roadmap n’est pas encore intégrée, parce que tu n’es pas encore vraiment rentré en mode projet, tu es en mode “amont du projet”. Donc c’est du cadrage pur et dur.

En tant que UX Researcher, tu peux intervenir à ces différents niveaux et puis aussi sur toute la partie évaluation, typiquement de l’audit et des tests utilisateurs que tu fais au fur et à mesure. Donc en fait ça dépend de la problématique à laquelle est confrontée ton client. De pourquoi il vient te voir et pourquoi il a besoin de toi.

Une posture d’ouverture pour explorer le champ du problème avant de penser aux solutions

D’accord. Oui, c’est intéressant de voir ces deux manières d’intervenir, soit très en amont pour le cadrage, soit dans un projet qui est déjà lancé. Quels conseils donnerais-tu à des clients pour que cette phase de recherche soit un succès et puisse vraiment apporter de la valeur?

A la fois d’être présent tout au long de la recherche, mais de ne pas chercher à influencer les chercheurs.
Parce que c’est important d’être présent tout au long de la démarche, ne serait-ce que pour bien comprendre ce qu’on est en train de faire et pourquoi on répond de cette manière-là à la problématique.

Mais, c’est ce que je dis souvent, tout le monde arrive en ayant déjà des idées de solutions et de réponses aux questions. C’est humain, le cerveau est câblé pour trouver des solutions à des problèmes.

Et donc la grande difficulté quand on se lance dans ce genre de démarche — et je pense que beaucoup d’UX peuvent être eux-mêmes confrontés à ça, c’est justement de mettre de côté les idées qu’on a et de rester l’esprit suffisamment ouvert pour accueillir et accepter toutes les informations qui vont être recueillies pendant la recherche utilisateur.

La recherche UX contribue à la hiérarchisation des besoins utilisateurs

C’est très intéressant comme conseil, d’avoir cette posture d’écoute pour accueillir les enseignements.
Tout à l’heure, tu disais que tu étais assez peu sollicitée sur la priorisation, que c’était plus à la main des P.O. et qu’il y avait des enjeux de pouvoir derrière. Mais en même temps, en tant qu’UX, tu sentais que tu pourrais avoir une légitimité à apporter un éclairage pour aider à faire des choix. Est-ce que tu pourrais développer un petit peu cette partie-là s’il te plait ?

Quand on fait une démarche complète de recherche utilisateur, à un moment donné, on se pose la question de hiérarchiser tous les besoins, tous les insights qu’on a récoltés. Quels sont les plus importants pour les utilisateurs que j’ai interrogés, que j’ai pu observer ?

Et cette hiérarchisation des besoins, c’est un vrai guide pour arriver à prioriser une roadmap, à choisir quel lot va être la priorité 1, 2, 3 etc. Et encore une fois, c’est toute la démarche UX que de repositionner l’utilisateur au centre des choix, et de faire ses choix en prenant en compte ces données issues de cette phase de recherche.

Alors il y a évidemment des contraintes, comme je disais tout à l’heure, de planning, de ressources et de budget. Mais pour moi, cette contrainte des besoins utilisateurs est aussi importante que les autres à prendre en compte.

Oui, effectivement.

Pour clôturer notre interview, je vais te proposer 2 phrases à compléter. Comment est-ce que tu compléterais la phrase suivante :

“Pour toi, un duo UX/PO qui fonctionne bien, c’est…”

C’est gagnant-gagnant.

“La principale difficulté pour choisir entre 2 fonctionnalités, c’est…”

C’est quand on n’écoute pas les utilisateurs. Quand on ne les écoute pas, ça devient difficile de choisir.

Pour conclure, est-ce que tu as un message à transmettre à celles et ceux qui nous lisent ?

Faites du mieux que vous pouvez, avec les outils que vous avez et avec les personnes avec lesquelles vous travaillez dans le cadre de vos différents projets.

Et considérez les notions d’éthique et de responsabilité : c’est important de comprendre pourquoi on fait des choses et comment on les fait, pour éviter des dérives dans les choix de conception.

Merci Marie-Cécile pour cette belle ouverture et pour nos échanges :-) !

Pour en savoir plus sur l’approche UX de Marie-Cécile, vous pouvez consulter son profil LinkedIn.

Vous rencontrez vous aussi ces problématiques et souhaitez aller plus loin sur le sujet ? Vous pouvez prendre RDV pour échanger avec Romain : https://calendly.com/romain-chabbal-uxshadow/ameliorer-ux