Bienvenue dans ce talk de la Product Week Summer 2021 où on va parler de la répartition de la recherche utilisateur entre le Designer et le Product Manager.
Dans les team produit, on retrouve souvent des designers et on se demande un petit peu : quelle est la répartition dans la conquête de ce fameux "insight utilisateurs" avec le Product Manager ? Quel est celui qui a le plus d'impact, le plus de poids dans cette recherche ?
Dans cette session, on a la chance d'accueillir Mickael David, Design Director de Doctolib et Laure Nilles, Lead Product Manager B2B chez Meilleurs Agents.
Pour commencer est-ce qu'on pourrait rappeler les différents rôles de la Product Team dans la recherche utilisateur ?
Laure : Alors nous, chez Meilleurs Agents, dans l'équipe produit on a différents métiers donc on a bien sûr des Product Managers et des Product Designers, on a également des Product Analysts, des Product Marketing Manager et un pôle qui est responsable des études quantitatives. Dans chaque équipe, actuellement on a six impact teams chez Meilleurs Agents, on va avoir deux Product Managers et un Product Designer. Et donc Product Manager et Product Designer interviennent sur la partie delivery et sur la partie discovery. On a une vraie partie commune sur le discovery qui se matérialise véritablement dans le parcours carrière pour ces deux métiers.
Mickaël : Alors chez Doctolib, c'est organisé un tout petit peu différemment, on a l'équivalent des impact teams sur les feature teams dans lesquelles on va retrouver différents profils : product manager, des développeurs et donc bien sûr des product designers.
On a fait le choix de spécialiser la partie discovery, user research, il ya deux ans. On a créé une équipe, qui elle aussi est affectée à des feature teams. Cela permet donc d'être très concentré sur les interviews, sur tout le travail de l'atelier de recherche, tout en gardant la proximité avec des feature teams qui permet de bénéficier du protocole et de savoir comment faire tout ça.
Laure : Une petite précision supplémentaire, peut-être, sur notre organisation chez Meilleurs Agents. Depuis un an, on a constitué une équipe que l'on appelle "équipe de recherche" qui fait du discovery vraiment en amont des décisions de la roadmap, justement pour nous aider en savoir plus sur une cible d'utilisateurs ou sur un sujet en particulier. Cette équipe doit nous permettre de prendre de meilleures décisions sur la roadmap et cette équipe, à la différence de Doctolib est tournante, donc tous les deux mois les personnes et les sujets changent.
Mickaël : Là où nous on a une équipe product strategy qui sera en amont, qui va explorer effectivement toutes les possibilités business qui s'offrent à nous. La user research peut aussi intervenir et aider cette équipe ponctuellement mais c'est vrai que ce n'est pas une équipe tournante. C'est une équipe dont c'est l'activité principale.
Très bien, on pourrait peut-être faire un focus maintenant sur le rôle du designer en relation avec le product manager?
Laure : Oui, je peux, bien- sûr, alors comment on se répartit la partie discovery chez nous? On a vraiment ressenti le besoin à un moment donné, de définir qui avait le lead sur telle ou telle partie du discovery. Ce sont des choses dont on a discuté ensemble et qu'on a posé sur papier, si je puis dire. On définit des leads pour chaque étape du discovery et en même temps, ce qui est important pour nous, c'est de se dire en fait, pour avancer le plus vite possible vraiment notre autre clé du succès, c'est de se dire : pour décider qui prend le lead sur cette tâche, il faut aussi qu'on prenne en compte la disponibilité des uns et des autres, les compétences des uns et des autres. Parce que la réalité c'est qu'on ne maîtrise pas tous, au même niveau les interviews, les tests utilisateurs... Les product managers sont également investis sur ces étapes là et donc on se laisse la possibilité, peut-être, dans un moment où le product designer d'une équipe va être très très chargé, on se permet de dire : là le product manager va mener les interviews, parce qu'il sait le faire. Ca permet d'avancer plus vite, tout en déchargeant le product designer donc on a vraiment on a cette organisation là.
Mickaël : Sur l'équipe design, en général, où du coup on a 4 équipes, on a le product design, la user research et on a aussi l'UX Writing, ils sont trois et le brand design. On a la chance d'avoir la brand intégrée au design.
Peut-être, rappelle-nous ce que fait chaque team du coup.
Mickaël : Ok ! Product design, l'outil principal c'est figma donc c'est vraiment toutes les interfaces, ça c'est le livrable et après en amont, c'est de travailler avec les feature teams pour accompagner toute la réalisation des interfaces.
- La user research, fait un peu le liant, le lien, on va dire avec toute la partie business amont et de découvrir en fait quel est vraiment le problème a tacler. Après, elle travaille de pair avec les product designers.
- L'UX writing qui va faire ce qu'on appelle la micro copie, donc tout le texte qui peut y avoir sur une interface. Pour la partie médecins/praticiens qui est la partie un peu cachée de l'iceberg, c'est vraiment un outil de productivité BTOB. C'est une interface où 70-80% est constitué de texte. C'est vraiment du texte très précis, qui va accompagner l'utilisateur à travers différents funnels pour manipuler de la donnée de manière générale, donc la copie est très importante, d'où justement cette spécialisation.
- La brand va faire décliner toutes les illustrations, le tone of voice d'une manière générale, et qui va faire à la fois, du print pour mettre des posters dans les salles d'attentes des médecins, jusque dans le produit. Le fait justement d'avoir la Brand rattachée au design, ça a des effets de bord très positifs sur la consistance de la marque, quelque soit le point de contact de l'utilisateur. On a vu que des effets positifs d'avoir cette organisation là et donc du coup on a exactement les mêmes illustrations quelque soit le point de contact.
Alors qu'avant c'était séparé et vous avez ressenti le besoin de rapprocher un peu ?
Mickaël : Alors c'est surtout qu'avant c'était externalisé. Chacun faisait appel à des prestataires mais il y avait pas un fil conducteur sur la direction artistique. On a eu la chance d'intégrer un profil et du coup à l'époque, il n'y avait pas une grosse équipe marketing, qui étaient structurée donc du coup on l'a rattaché au design. Ça s'est fait de manière très empirique et c'est très bien comme ça. Après sur la partie user research, quand je suis arrivé, il y a trois ans et demi, la user research, elle était faite un peu par les PM, un peu par les sales, tous les gens qui étaient en contact avec l'utilisateur final. On a choisi de spécialiser cette user research, pour être détaché de ce qu'on appelle le run, d'être détaché vraiment de la réalisation des fonctionnalités et de pas avoir la tentation de se dire : par rapport au temps que j'ai ou par rapport à ce que j'ai envie de faire de mon produit, j'aimerais bien que ça aille par là donc je vais un peu peut-être guider l'utilisateur vers là. Alors qu'en fait, ce n'est pas le but. Le but c'est de vraiment comprendre où est ce qu'il en est ? Quel est son problème ? Quels sont ses irritants au quotidien ? et de répondre à ça.
Chez nous, ce sont des chasseurs de biais, c'est vraiment le credo. Comment est ce qu'on essaye d'avoir une photo de la vérité ? À l'instant t : comment est ce qu'on arrive à reproduire le comportement d'un utilisateur quand il est tout seul chez lui, sans forcément avoir quelqu'un à côté lui, qui même par sa présence sans rien dire, va de toute façon induire un comportement un tout petit peu différent ? C'est très compliqué. C'est là où on a choisi vraiment de créer ce pôle là, qui va développer ses propres protocoles d'interviews, de focus group. On va utiliser des outils comme Mural, pour faire un peu de Design Thinking, de faire converger des idées ou faire émerger des idées.
C'est vrai qu'au début, l'équipe product management se sentait un peu dépossédée de quelque chose. Mais ils ont vite perçu, le côté positif : en effet ça demande énormément de temps de faire ces protocoles, par rapport aux personas qu'on va interroger. Nous, on est sur les praticiens et c'est un dentiste, des médecins généralistes, un podologue et en fait par spécialité, il peut y avoir des irritants différents, y avoir des problématiques différentes qu'on soit à Paris, en province, en France, en Allemagne... Ca c'est une première organisation et depuis le début de l'année, on se rend compte que c'est pas scalable d'avoir une équipe. On ne va pas recruter 50 user reseachers parce que c'est une masse salariale importante et surtout en fait, on a choisi de passer dans une autre étape, où on va, un peu comme Meilleurs Agents, aider des Product Managers ou de toute personne, qui est en charge d'un sujet à faire lui-même sa user research. Du coup, on va l'accompagner, on va rédiger des protocoles, on va un peu contrôler que les premières interviews se passent bien, s'il y a vraiment un effet un peu pédagogique, de formation pour justement comprendre que lorsqu'on passe dans cette phase de contact avec l'utilisateur, il faut que je pose mon cerveau, j'en pose un tout neuf qui soit complètement débarrassé de mon quotidien et c'est un exercice qui est très compliqué.
Mais on essaye du coup de faire un mix entre des projets qui sont pleinement manager on va dire par la user research et qui sont accompagnés par la user research.
Laure : Si je peux rebondir sur cette cette histoire de biais, qui est quand même assez clé effectivement. Ça prend énormément de temps, nous, notre Lead product designer avant, elle faisait de la recherche chez Orange. Elle était vraiment accompagnée par un ingénieur à temps plein, qui va chercher chaque biais dans tout son travail. C'est vraiment énorme, en fait et moi, ça m'a toujours beaucoup étonnée : le temps que ça prend, l'énergie que ça prend de déceler vraiment tout ce qui peut induire en erreur en fait l'utilisateur. Nous, c'est vrai, qu'on a pris le pari de ne pas avoir des personnes qui sont uniquement dédiées à ça. Mais en fait, pour contrebalancer un peu ça, ce qu'on a mis en place, c'est un certain nombre de rituels et d'habitudes. Quand quelqu'un rédige, par exemple, une trame d'une interview, il ne peut pas la faire sans l'avoir partagé en amont à l'ensemble de l'équipe produit. On a vraiment cette habitude de partage à l'extrême, vraiment de tout ce qu'on fait afin de traquer tous les biais possibles, qui sont parfois difficiles quand c'est notre sujet, quand c'est le produit sur lequel on travaille depuis quelques mois, ça peut vite arriver de déraper. Face à ça... on met vraiment le barrage de partage. En fait, a priori c'est repéré. On est 30 dans l'équipe, donc il y a un moment donné, il ya quelqu'un qui dit quelque chose. C'est vraiment sur le sujet des biais.
Quels outils utilisez vous chez Doctolib et chez Meilleurs Agents ? On peut également aborder dans cette partie du rôle fondamental de capitalisation?
Mickaël : C'est un des projets sur lequel on travaille aujourd'hui et pour l'instant on est encore à étape 1. On utilise un outil qui s'appelle Dove Tail qui permet pendant les entretiens, les interviews, de prendre des notes et c'est un outil qui est pratique parce qu'il accompagne le user researcher jusqu'à la mise en forme de son compte rendu, en partant de phrases, de mots clés, de tags intelligents qu'il va pouvoir mettre en avant sur ce compte rendu.
Derrière l'objectif, c'est que dans six mois, un an peut-être, un product manager qui se pose une question sur un sujet puisse aller dans cette user research library et se dise que toute la donnée qui existe déjà sur le sujet et peut-être, avoir un début de réponse, et décider à ce moment s'il déclenche une autre étude ou pas.
Ca c'est la capitalisation, ce sont des sujets que l'on appelle du Build, de construction sur le long terme.
La capitalisation passe aussi beaucoup par la communication : on a des rituels assez forts de présentation du travail réalisé. Entre designers, on a mis en place des All Hands Design parce qu'aujourd'hui on est 35 sur cette équipe donc, de temps en temps, c'est bien d'avoir ces réunions là. On en fait toutes les trois semaines pour montrer un peu ce qu'on fait, pour créer justement une synergie entre les groupes.
Les UX Writers, la brand, ne sont pas toujours en contact avec la User Research et de voir ce qu'ils font au quotidien, surtout en remote, c'est quand même utile.
Le vendredi, on organise un product meeting, on a tous les product managers de l'entreprise et on fait systématiquement dans l'ordre de présentation il y a un sujet design, soit product design, ou brand, ou user research où on présente rapidement les conclusions d'une étude qui a été faite la semaine d'avant. On réexplique un peu le protocole, comment est-ce que ça a été fait, les personnes qui ont été recrutées, les profils ... et ça permet aussi d'acculturer tout un groupe de gens. Nous on accueille énormément de gens, chaque mois, il y a 100 personnes qui rejoignent Doctolib tous les mois, donc c'est pour ça qu'il faut acculturer très très vite pour que cette culture design, user centric soit immédiatement acquise par tout le monde.
On a fait des tests avec plusieurs outils dont dove tail, d'ailleurs je crois qui ne convenait pas tout à fait à l'équipe et du coup on est revenu à Notion, notre outil de documentation pour toute l'équipe produit. C'est vrai qu'avoir le bon niveau d'information, les bons tag effectivement et surtout de créer vraiment ce réflexe à chaque fois qu'on fait une interview, à chaque fois qu'on fait un test utilisateur, de mettre ses comptes rendus dedans, c'est aussi un peu long un peu compliqué parfois à mettre en place dans l'équipe. C'est un vrai problème d'entreprise comme peut-être le design system, au final.
Pour la petite aparté, le Design System, nous a pris huit mois, c'était un vrai projet d'entreprise avec des profils dédiés à ça comme la user research ops qui va justement passer du temps pour accompagner : comment je vais bien tagger, comment je vais structurer tout ça. C'est le tout début mais, en tout cas, on essaie de se donner les moyens.
Après sur les outils - parce que on n'a pas fini - nous on utilise Maze donc pour faire des user tests avec des interfaces en remote, c'est assez facile, ça marche plutôt pas mal. On a Mural qui est l'équivalent des Miro et tous ces outils, c'est un peu la même chose. Il y a Figma aussi qui a sorti le sien figjam et donc qui est très pratique pour toute l'équipe design. Toute la suite google : les google sheets, slides etc et après ce sont des logiciels de type surveygizmo, alchemer, qui permettent justement de lancer par mail des formulaires, des questions et répondre à des questionnaires en ligne ...
Il y aussi frase app pour l'ux writing par exemple, les suites Adobe pour le côté brand même la brand, ils se sont mis à figma également, ils adorent le côté super rapide et puis la continuité avec les interfaces produits...
Laure : Nous, de notre côté pour les prototypes qu'on fait tester, on utilise marvel ; pour les ateliers on va utiliser whimsical. Il y a un autre outil qu'on aime bien mais qui n'est pas que pour le design dès qu'il ya des post it en jeu, c'est très sympa, je vous recommande : ça s'appelle métro rétro, il a une petite fonctionnalité qui permet de faire des confettis aussi on aime bien. Il faut que les outils soit un plaisir, ça reste du travail mais c'est quand même sympa de d'avoir des petites fonctionnalités qui sont de la gamification et qui vont vraiment permettre de s'approprier plus facilement l'outil. Sinon effectivement la suite google qui est quand même toujours très efficace et Notion. On utilise TestingTime pour les recrutements de testeurs mais côté BtoC, on a un peu la même dynamique. C'est presque plus facile en BtoC parce qu'ils nous font le recrutement et coté BTOB, on pioche un peu dans nos agences immobilières. On en a presque 10 000 donc on peut bien filtrer sur les critères.
Du coup peut-être que pour cette dernière partie, on pourrait parler un petit peu de la scalabilité de vos organisations dans la recherche utilisateurs ?
Mickaël : Chez Doctolib, on est 1800 je crois, je suis arrivé il y a trois ans et demi, on était un peu moins de 400 donc c'est vrai que c'était trois belles années.
C'était une période assez excitante et effectivement dans l'adn de l'entreprise, au niveau du comité exécutif, il ya une vraie volonté de créer cette culture forte pour permettre au groupe de grandir sans perdre cette âme de de startup. Comment est-ce qu'on est orienté solutions ? Comment ne pas de devenir un gros groupe un peu immobile ? Comment ça se concrétise ? On a énormément de rituels donc déjà les matinées sont dédiées plutôt au build à ce qu'on disait tout à l'heure, donc comment je passe du temps avec mon équipe d'experts, de product designers, de user researchers, d'UX writer. L'après midi est plutôt dédiée au run avec les feature teams pour essayer de garder cette culture design forte et éviter peut-être quelle puisse se diluer un peu dans le temps.
Comment est ce qu'on va onboarder très vite des nouvelles personnes dans l'équipe ? Quand une personne arrive, elle a une semaine de Doctolib academy donc où elle a toutes les présentations à l'échelle d'une entreprise et quand elle arrive dans l'équipe design, elle va avoir les outils, tous les process et méthodes... On a maintenant un design ops qui s'occupe de ça donc ça fait partie de sa job description, c'est quelqu'un qui va vraiment accompagner tous les nouveaux arrivants. Ça permet de grandir en tout cas sur les expertises, tout en gardant cette culture.
Laure : Je te rejoins sur la partie onboarding, qui est vraiment essentielle. On essaye au maximum de la peaufiner avec les nouvelles arrivées mais c'est vrai que c'est très clé. Toute la partie montée en compétence aussi, est à mon avis essentielle pour scaler en tant qu'entreprise, donc est-ce qu'on a ces moments qui sont dédiés à l'entraînement sur certaines méthodes ? est-ce qu'on est accompagné en tant que personne dans l'équipe produit pour s'améliorer ? Je pense qu'il faut aussi savoir repérer le moment où les choses dysfonctionnent et réagir vite. Nous, c'est vrai qu'on a eu des moments où avant nos daily d'équipe produit, chacun parlait un à un, et au bout d'un moment, on se répétait, ça durait extrêmement longtemps. Il faut être aussi à mon avis, très agile sur ces différents rituels qui sont tellement importants pour l'équipe. Savoir trouver d'autres façons de faire, de partager, de s'améliorer, tout en restant dans la performance.
