Les Jobs To Be Done vous aident-ils à faire de meilleures personas ?

Le problème des personas 😒 ➡️ 📦

La persona est un outil classique du travail sur l’expérience utilisateur. Depuis son introduction par Alan Cooper en 1998 dans le livre The Inmates Are Running the Asylum, il a évolué pour s’imposer comme un standard dans la quasi totalité des équipes produit.

Une persona est tout simplement un document (souvent présenté sous forme de poster) décrivant un archétype représentant un groupe d’utilisateurs du produit. Ce groupe partage les mêmes objectifs, motivations et types de comportements.

Elles répondent à plusieurs objectifs :

• Servir d’outil d'aide à la décision en mettant l’utilisateur final au coeur du processus de design
• Eviter les designs trop génériques en poussant à se focaliser sur un nombre réduit d’utilisateur-types ; certains préconisent même de choisir une seule persona majeure par projet
• Générer de l’empathie au sein des équipes et faciliter la discussion autour des besoins utilisateurs
• Synthétiser de manière claire et concise la recherche utilisateur

Cela peut paraître étonnant pour un concept aussi ancien et répandu. Cependant, nous avons pourtant constaté au cours de missions chez nos clients qu’il s’agissait d’un des outils liés au produit le plus mal utilisé (ou abusé), au point d’en devenir parfois contre-productif.

Problème n°1 : les personas ne reposent souvent sur rien

Le premier problème rencontré au niveau des personas, c’est que beaucoup d’organisations créent des personas par réflexe. Elles ne se posent pas la question du travail de recherche nécessaire. On aboutit à des proto-personas, purement descriptives, issues des intuitions de quelques-uns ou d’une prétendue connaissance interne des clients. Ceux qui font l’effort de construire des personas orientées objectif, mais toujours fondées sur l’intuition, adoptent souvent une vision tellement générique que leur persona pourrait être appliquée telle quelle à n’importe lequel de leurs concurrents.

Les équipes qui cherchent à collecter de l’information concrète sur les utilisateurs pour construire leurs personas se cantonnent souvent à de la recherche qualitative. Les product designers vont prendre le temps d’interroger une dizaine d’utilisateurs (au mieux, suivant les projets). Ils consolident ensuite des profils en fonction des typologies de répondants et de leur réponses. Mais la méthode qualitative présente des limites, d’autant plus dans un univers où il y aurait en réalité mille façon de “segmenter” les utilisateurs… pourquoi les utilisateurs interrogés seraient-ils représentatifs de l’utilisateur cible ? Comment les a-t-on choisi au départ ? Est-on sûr de ne pas tomber sur des cas très spécifiques ? Est-ce que Philippe, 45 ans, dont l’objectif principal consiste à gagner du temps en cuisine constitue réellement un archétype d’utilisateur parce que deux personnes interrogées lui ressemblent un peu ?

La recherche utilisateur qualitative est très efficace pour identifier les “pain points” des utilisateurs. Elle sert aussi à creuser des cas d’usages et comprendre certains métiers ou problématiques complexes. Elle permet de se faire une idée des questions prioritaires à résoudre et d’avancer rapidement en creusant les problèmes. Mais sont-elle suffisantes pour dresser un portrait robot de l’utilisateur type du produit  ? C’est discutable. La démarche qualitative de création des personas génère fréquemment des débats absurdes ; pour savoir si telle persona est plutôt “technophile” ou pas, le niveau de son “appétence mobile” et la liste des journaux qu’elle lit.

Les équipes produit plus larges et plus expérimentées (et à ce stade on n’en rencontre pas tant que cela) combinent la méthode qualitative à une approche quantitative. Elles explorent par exemple les analytics produit pour identifier des pattern d’usage et reconstruire des personas autour de ces données. Mais dans ce cas c’est l’aspect empathique des personas qui reste souvent biaisé ou douteux. Comment passe-t-on concrètement de “30% de nos utilisateurs utilisent essentiellement la fonctionnalité X, et ce sont des hommes à 60%” à “Didier, 35 ans, 2 enfants…” ?

Problème n°2 : les personas perpétuent des biais sur les utilisateurs

Pour les raisons exposées ci-dessus, les personas (au départ censées générer de l’empathie) renforcent souvent les biais de leur concepteur. Ils finissent alors par devenir une caricature fausse de l’utilisateur. Les équipes ont tendance à se concentrer sur des attributs peu cruciaux (critères socio-démographiques, “biographie”). Elles ne passent pas assez de temps à remettre en question le besoin ou l’objectif de cette persona. Pour des raisons (bien intentionnées) d’éthique ou de principe, on cherche souvent à varier arbitrairement les profils des personas (mélange d’hommes et femmes, de diverses origines sociales...) sans se préoccuper du tout de la cohérence de celles-ci avec la vraie typologie des clients du produit.

Problème n°3 : les personas sont très peu mises à jour

Au départ, on pensait les personas pour guider la conception d’un projet ou d’une fonctionnalité, pas d’un produit entier. Elles étaient volontairement rapides, caricaturales et visaient à débloquer rapidement des décisions de design.

Aujourd’hui, les personas restent rapides et caricaturales. Elles se réalisent toujours en début de projet. Cependant elles ont tendance à  perdurer dans le temps et s’imposer comme le référentiel de la “vision utilisateur”. Pourquoi pas, mais dans ce cas elles devraient s'étayer au fil du temps et de l’évolution de la base utilisateur, affinées, mises à jour. Certes pas chaque mois, mais sur plusieurs années on peut supposer que les utilisateurs du produit évoluent avec celui-ci.

Certaines équipes parviennent à faire ce travail, et revoient leurs personas après chaque session de tests utilisateur ; mais ce cas est malheureusement très rare. La plupart des personas rencontrées chez nos clients n’ont quasiment jamais été retouchées, propageant ainsi une vision fausse des utilisateurs. Ou alors on les met à la poubelle à chaque changement de Product Designer, et on les recréent mais sans continuité.

Problème n°4 : Les personas sont peu utilisées en pratique

Certes, l’empathie pour l’utilisateur est cruciale dans le travail d’UX et plus globalement dans la conception d’un produit. Mais, peut-être faute de les construire correctement ou d’expliquer leur intérêt au sein de l’entreprise, les personas ne s'utilisent pas si souvent au quotidien dans la conception, la priorisation et la prise de décision côté produit. Elles guident parfois une session de brainstorm, s'affichent souvent sous forme de poster sur les murs, mais guère plus.... En tant que PM, combien de fois vous référez-vous aux personas pour choisir entre le développement de la feature A ou B ? Avez vous déjà repensé une de vos User Stories pour mieux coller à une persona ? Souvent, des macros-personas correspondant en gros à des parcours utilisateur ou des groupes de besoins fonctionnels font l’affaire.

En tant que Designer, vous arrive-t-il de concevoir une interface spécifiquement pour une persona ? A présent que tous les sites et les applications mobiles sont conçus pour être modulaires, simples, utilisables par tous, et minimisant les frictions, quelle place pour la persona dans le travail de design ? En dehors d’applications visant des cibles bien particulières (enfants, personnes âgées...), combien d’équipes développent des versions complètement différentes d’un parcours adapté à différentes personas?

On peut se demander si il est pertinent d’investir autant de temps pour créer et mettre à jour des personas ; si celles-ci sont de facto mises de côté pendant le travail de conception.

Une démarche inadaptée ou un outil perfectible ? 🔭

Ces constats autour des personas sont suffisamment partagés pour faire l’objet de multiples articles sur medium ou ailleurs ; cependant, la réponse habituelle consiste à pointer que l’outil lui même reste pertinent (car parfois utilisé avec succès) ; mais que certains Designers ou Product Managers l'utilisent ou l'implémentent mal.

En effet, le concept de persona n’est pas forcément à remettre en cause en soi. Seulement quand on creuse, on voit que chaque Designer les utilise différemment. Le mode de création de la persona, les informations mises en avant, l’utilisation même de cette persona peuvent varier significativement. Ce flou, ajouté au fait que les personas sont souvent orthogonales avec d’autres segmentations présentes dans l’entreprise (segmentation marketing, segmentation revenu...), est lié intimement à l’outil. Il a également une tendance problématique à couper les équipes du contact avec l’utilisateur sous couvert de le remettre au coeur de la réflexion, les personas étant vécues comme “le projet des UX” et comme un livrable difficile à remettre en cause.

Les JTBD à la rescousse ? 🚑

Nous avons parlé un peu des Jobs To Be Done et de leur intérêt pour un Product Manager. Pour rappel, ceux-ci proposent une approche mécaniste d’analyse d’un besoin utilisateur donné, sous forme de Job décomposé en différentes étapes. A priori, rien de plus éloigné de la philosophie des personas... Mais pourtant ces deux outils sont souvent rapprochés voire mis en concurrence. Ne pourrait-on pas s’inspirer de l’approche JTBD pour solutionner certains des problèmes posés par les personas ?

Les JTBD se concentrent en premier lieu non pas sur qui sont les utilisateurs mais sur ce qu’ils souhaitent accomplir. En cela, ils sont plus proches d’un “Customer Journey” très large dépassant le cadre du produit. La théorie initiale des JTBD n’est pas spécialement prescriptive sur la façon de gérer la diversité des utilisateurs. En pratique, une “persona” d’un produit peut avoir plusieurs jobs ; et inversement un même job peut se réaliser de manière différente par différentes personas. De même, les jobs sociaux et émotionnels qui se rattachent au job principal peuvent être distincts d’un type d’utilisateur à l’autre.

Pour structurer un peu mieux l’approche utilisateur, la méthodologie Outcome Driven Innovation (l’une des variantes des JTBD) propose une méthode quantitative de segmentation, centrée sur les besoins utilisateurs :

• L’équipe commence (comme toujours…) par rencontrer des clients ; via une phase de recherche qualitative permettant de recueillir les attentes de ceux-ci par rapport au Job à accomplir. La méthodologie JTBD propose deux types d’interview pour cette étape. Les ‘Switch Interviews’ consistent à interroger des clients qui ont récemment changé de solution pour accomplir leur Job To Be done, afin d’identifier les forces attirant ou repoussant les clients vis à vis des différents produits du marché. L’approche Outcome-Driven Innovation consiste à faire abstraction des solutions existantes pour se focaliser sur un inventaire des attentes de chaque client vis à vis du Job.
• Ces attentes sont ensuite standardisées sous forme de “customer need statements” ; des phrases conçues pour exprimer la valeur telle qu’elle est perçue par l’utilisateur, donc les conditions (subjectives) de réussite du job. A ce stade, il est probable d’en identifier des dizaines ; certaines liées au Job principal et d’autres aux Jobs émotionnels et sociaux.

• On peut administrer ensuite sur la base la plus large possible (clients, prospects, panel externe) un questionnaire demandant aux répondants de qualifier le niveau d’importance qu’ils accordent à chaque “customer need statement” (de 1 à 5). Bien sûr,  on glisse également des questions socio-démographiques dans ce questionnaire pour mieux qualifier les répondants par la suite. En général, on en profite pour leur demander en même temps d’évaluer la performance de votre produit actuel ; ou de certains concurrents identifiés sur les mêmes critères. On peut ainsi déterminer quels besoins sont très importants pour certains utilisateurs et/ou mal servis par votre Produit.

L’analyse statistique (cluster analysis) de ce questionnaire permet de regrouper les clients en fonction de leurs réponses ; par groupe partageant les mêmes attentes et préoccupations vis à vis du job à accomplir. On obtient donc des segments utilisateurs orienté besoin ou objectif, soit...des personas !

Un exemple pour illustrer : considérons l’un des “Jobs” solutionnés par les taxis, Uber, ou le métro, que l’on pourrait décrire comme “effectuer un trajet court en milieu urbain”.

Des entretiens avec des personnes concernées par ce job (dans ce cas, la quasi totalité de la population urbaine…) pourraient rapidement faire apparaître quelques critères de succès de ce job, tous assez différents.

Par exemple :

• minimiser le temps d’attente pour obtenir un véhicule
• minimiser les détours inutiles
• maximiser les chances d’être assis durant le transport
• minimiser l’impact sur l’environnement du trajet
• minimiser le besoin de devoir retirer du liquide pour payer le transport
• réduire le prix payé
• minimiser les contacts nécessaires avec d’autres usagers / passagers
• ... et bien d’autres

Chaque personne peut juger ces critères plus ou moins importants... Administrer un questionnaire quantitatif permettrait d’identifier des groupes d’utilisateurs partageant des préoccupations communes, de creuser leurs besoins et pourquoi pas de concevoir une offre ou un produit pour chacun : ce qu’a fait par exemple Uber avec Uber Pool (ciblant les personnes peu pressées cherchant à optimiser le coût du trajet au détriment parfois de la durée et du confort) ou Uber Green (privilégiant les voitures moins polluantes).

Cette approche, certes coûteuse à implémenter, semble répondre à certaines des limites des personas “classiques” :

• l’analyse se centre toujours sur l’utilisateur. Néanmoins, elle mêle quantitatif et qualitatif ce qui résoud (en partie) le problème de la représentativité des personas
• la segmentation qui en résulte est issue d’un travail statistique ; et non d’un échantillon de personnes piochées au hasard parmi nos contacts
• on met de côté les notions de critères socio-démographiques qui empoisonnent souvent la construction des personas. Peut être que des grands parents et des adolescents peuvent se retrouver dans le même segment ; quand d’autres segments touchent de manière plus évidente une seule catégorie de la population. Dans tous les cas, on peut analyser a posteriori l’homogénéité de chaque groupe de besoin. Cela permettra d'aider à la formalisation d’une persona plus réaliste.

Dans ce cas, l’approche par le job-to-be-done peut servir à guider la création des personas (trouver les bons critères de segmentation) tout en limitant la part de “doigt mouillé” et de biais personnel.

Le plus délicat reste la définition du job proprement dit. Il s’agit d’un choix structurant et qui s’accompagne d’une part d’intuition. Le type de personas que vous obtiendrez à la fin dépendra de ce choix. La méthode JTBD semble donner de meilleurs résultats en définissant un job très large, dans une approche stratégique permettant d’identifier des opportunités d’innovations et des groupes d’utilisateurs peu ou mal servis par le marché. Mais en partant d’un job plus restreint, on peut aussi aboutir à des personas plus tactiques ; adaptées à la création d’une nouvelle fonctionnalité ou d’un MVP. L’idéal serait sans doute de commencer par une phase d’immersion auprès d’utilisateur cibles, sur plusieurs lieux et à plusieurs moments différents, et de lister les jobs identifiés à partir de cette phase d’observation.

La notion de contexte d’utilisation autour du job semble également un angle mort de la méthodologie. Si l’on reprend l’exemple du “effectuer un trajet court en milieu urbain”, il paraîtrait logique que les étapes du job, les attentes des utilisateurs et donc les profils de ceux-ci varient suivant, par exemple, le moment de la journée. Se rendre à un rendez-vous professionnel, ou rentrer de soirée à deux heures du matin représentent des contextes différents. Dans ce cas, la solution consisterait sans doute à considérer et étudier les 3 jobs séparément, le plus vaste / générique et chacun des jobs particulier... Les enseignements en serait probablement riches, mais cela devient plutôt chronophage !

Quelques conseils concrets pour faire de meilleures personas (en s’inspirant des JTBD) 😀

Quelques pistes de réflexion pour maximiser l’utilité des personas et mêler le meilleur des deux approches :

1- Commencer par essayer de définir le “Job” que votre produit cherche à accomplir.

Ce travail est structurant pour comprendre le problème que vous souhaitez adresser mais aussi pour avoir un première idée de qui pourraient être vos utilisateurs. Repartez le cas échéant de vos personas existantes, et identifiez leur Jobs to Be done et parcours clients. Visez un job plus ou moins large en fonction de si vous lancez le MVP d’une nouvelle fonctionnalité ou si vous possédez un produit déjà établi. Par exemple, Netflix expliquait récemment se sentir davantage en concurrence avec Fortnite (l’un des jeux-vidéo les plus populaire du moment) qu’avec des services de streaming comme Hulu  : son job est donc bien le divertissement au sens large et pas forcément la consommation de séries et films.

2- Toujours s’appuyer sur la rencontre et l’observation des utilisateurs

Que vous formalisiez des personas ou pas, et quel que soit leur usage final, vous devez toujours rencontrer, observer et discuter avec vos utilisateurs. Embarquez tous les profils de l’équipe dans la démarche, et partagez fréquemment le résultat de cette recherche. Un compte rendu synthétique couplé à une présentation orale vaut souvent mieux qu’un poster de persona finissant au fond d’un tiroir.

3- Mêler approche quantitative et qualitative

La recherche quantitative peut être longue et coûteuse, certains s’en sont rendu compte dans la douleur ; cependant, les allers-retours entre qualitatif et quantitatif ne peuvent que bénéficier à votre connaissance des utilisateurs. Le questionnaire JTBD - ODI peut être un bon moyen de segmenter vos utilisateurs par communauté de besoin, et de créer des personas moins caricaturales reposant sur de la data. Le plus simple consiste souvent à commencer par regarder vos analytics pour voir si des patterns d’utilisation se dégagent qui pourraient être explorés et validés sous forme de recherche qualitative ciblée.  

4- S'assurer du soutien du management et de l’équipe

Si vous tenez à créer des personas pour matérialiser la vision client, prenez la peine d’expliquer leur intérêt et leur utilité très largement dans l’organisation. Pour utiliser les personas, vos collègues doivent croire en leur qualité. Ils doivent se sentir investis dans le processus de création et comprendre d’où elles viennent et à quoi elles servent. Ne créez pas les personas en chambre, embarquez un maximum de personnes dans le processus des personas / JTBD et même plus largement dans la recherche utilisateur.