Persona : pourquoi continuer à en faire (ou pas) ?

Les personas sont devenus un “classique” de la recherche utilisateur. Protéiformes, ils règnent en mètre étalon des bonnes pratiques des méthodologies UX. Pour autant, outre atlantique, les Jobs-to-be-done se présentent en challenger.

Photo by Steinar Engeland on Unsplash
Photo by Steinar Engeland on Unsplash
Rarement remis en question, les personas sont ils réellement utiles ? C’est la question que nous souhaitons discuter avec vous. Poser un regard critique sur nos pratiques pour les approfondir et en créer de nouvelles, tel est aussi l’objectif que nous poursuivons à travers notre blog.
Et quand des designers posent les questions qui construiront l’Experience Utilisateur de demain, nous partageons le fruit de leur réflexion.
Ainsi, Page Laubheimer, UX Specialist chez Nielsen Norman Group, ouvre le débat sur les personas vs les jobs-to-be-done. Voici la traduction de son article.

Personas vs Jobs-to-be-done

Les jobs-to-be-done se concentrent autour des difficultés et des besoins des utilisateurs. Les personas bien réalisés quant à eux, incluent en plus des détails sur le comportement et l’attitude des utilisateurs.
Les personas ont longtemps été à l’honneur dans le processus de conception centrée sur utilisateur ; mais ces dernières années, les jobs-to-be-done, une technique axée sur les besoins du client, ont vu leur place prendre une importance significative.

Définition

Les jobs-to-be-done (“missions à accomplir” en français) sont un ensemble d’outils basé sur l’idée que chaque fois que les utilisateurs « embauchent » (« to hire » en anglais) un produit, ils l’utilisent pour mener à bien une mission spécifique (les fameux “jobs”) et donc, obtenir un résultat particulier. Chaque JTBD correspond en fait à la liste complète des besoins des utilisateurs.

Photo by Clark Tibbs on Unsplash
Photo by Clark Tibbs on Unsplash
La popularité grandissante des jobs-to-be-done fait dire à certains que les personas peuvent être abandonnés, les JTBD étant une technique plus utile. Cet avis repose sur une mauvaise compréhension de départ sur l’objectif des personas. Je m’explique : les personas seraient principalement des représentations démographiques des utilisateurs, ne tenant pas compte des facteurs comportementaux. Ces facteurs sont pourtant essentiels pour produire de bons personas dans l’UX Design et la stratégie produits.

JOBS-TO-BE DONE : UNE RESSOURCE UTILE

Axée sur les résultats plutôt que sur les fonctionnalités, la technique des JTBD est fondée sur une représentation des besoins des utilisateurs. Elle est obtenue par des études qualitatives menées auprès des utilisateurs (enquêtes de terrain, entretiens ou encore tests d’usabilité simplifiés).
Une des étapes consiste à déterminer quelles sont les motivations des utilisateurs dans « l’embauche » d’un produit (rappelez-vous, ils ont des missions à mener à bien). Elle permet également, dans l’idéal, de découvrir les produits concurrents existants dont les utilisateurs sont prêts à se passer en faveur du nôtre. Gardant tout cela à l’esprit, l’équipe en charge du produit peut se concentrer sur la nature des contraintes et des besoins fondamentaux des utilisateurs. Puis, sous un angle nouveau, concevoir les fonctionnalités qui correspondent le mieux au besoin principal des utilisateurs.

Un exemple : les services de livraison

Photo by Viktor Kern on Unsplash
Photo by Viktor Kern on Unsplash
Si une analyse de tâches traditionnelles permet de découvrir que des livreurs ont souvent besoin d’imprimer les instructions de navigation entre chaque arrêt sur leur parcours quotidien, il est probable que les développeurs tenteront de simplifier au maximum le format et les instructions d’impression. Une approche axée sur les JTBD quant à elle, mettra l’accent sur la « mission » du livreur (c’est-à-dire obtenir des conseils de navigation tout en conduisant) et cherchera des solutions à ce problème (comme un système GPS à guidage vocal).
Les outils jobs-to-be-done suggèrent que l’innovation et un design de qualité proviennent de l’évaluation des besoins réels des clients et de la création d’une solution qui n’est pas entravée par les produits qui y répondent déjà. Cependant, une position aussi radicale sur l’innovation peut se révéler être une stratégie coûteuse et risquée pour l’amélioration d’un produit. Et pour cause, voici la citation favorite des partisans des JTBD :

« Les gens ne veulent pas acheter une mèche de 60 mm, ils veulent un trou de 60 mm » – Théodore Lewitt

Plutôt que de se concentrer sur une liste de fonctionnalités pour un produit, le cadre des jobs-to-be-done oblige les concepteurs à réfléchir aux résultats :

  • Les utilisateurs seront-ils en mesure d’effectuer (facilement et agréablement) la mission pour laquelle ils ont « embauché » le produit ?
  • Cette solution offre-t-elle un meilleur résultat que les solutions existantes ?
Photo by Naphtali Marshall on Unsplash
Photo by Naphtali Marshall on Unsplash
L’approche des JTBD ne prescrit pas un format ou un produit livrable particulier. Mais le plus souvent, le job-to-be-done est défini par une phrase indiquant ce que les utilisateurs doivent faire, ainsi qu’un ensemble d’informations sur le contexte, telles que pourquoi et à quel endroit ils le font.
Enfin, une description des jobs-to-be-done rassemble généralement deux types de critères. Les premiers sont les critères de réussite fonctionnelle (le but de la mission, les consignes claires pour y parvenir). Les seconds sont les critères de réussite émotionnelle (que l’on peut diviser entre les critères émotionnels individuels des utilisateurs et les considérations sociales, comme la façon dont ils s’imaginent qu’ils seront perçus par les autres).
Les jobs-to-be-done sont généralement résumés en une seule phrase décrivant ce que l’utilisateur doit accomplir et tout contexte important qui pourrait avoir une incidence sur la mission (dans l’exemple suivant, voyager pour un congrès plutôt que pour des vacances). Les jobs-to-be-done comprennent également des renseignements sur les critères objectifs de réussite fonctionnelle ainsi que les critères subjectifs de réussite émotionnelle qui contribuent à une bonne expérience.
Les critères émotionnels sont souvent divisés en deux volets : critères personnels et considérations sociales.

DES PERSONAS BIEN CONÇUS SONT PLUS QU’UN RÉPERTOIRE DE DONNÉES DÉMOGRAPHIQUES

La plupart des arguments avancés pour suggérer que les personas sont devenus inutiles avec l’arrivée des jobs-to-be-done reposent sur la fausse-idée que ces derniers sont principalement des représentations démographiques des utilisateurs.
En outre, les données démographiques sont problématiques pour la prise de décision dans la conception de produits, car elles ne fournissent pas de données sur les comportements et les attitudes des utilisateurs, et sont surtout adaptées pour les objectifs du marketing et de la publicité.

Photo by Simon Launay on Unsplash
Photo by Simon Launay on Unsplash
En fait, les personas sont censés être des représentations complexes des utilisateurs, et aller au-delà des simples données démographiques ou personnelles.
La plupart des personas bien conçus comprennent une multitude d’informations, dont :

  • Les détails démographiques, tels que l’âge, l’état civil et les revenus ;
  • Les détails personnels, tels qu’une courte biographie, une photo et un nom ;
  • Les détails cognitifs ou d’attitude, tels que l’information sur le modèle mental du persona, ses points de douleur et sa perception des tâches à accomplir ;
  • Les buts et motivations pour l’utilisation du produit ;
  • Les détails comportementaux sur la façon dont le persona a tendance à agir lors de l’utilisation du produit.

Les détails démographiques et personnels existent pour deux raisons principales :

  • Afin que les membres de l’équipe de projet créent de l’empathie envers l’utilisateur
  • Comme technique mnémonique pour aider à le rendre mémorable pour l’équipe.

Malheureusement, nombre de personas (qui sont en réalité des segments marketing que l’on fait passer pour tels) ne vont pas plus loin que le niveau démographique ou personnel. C’est pourquoi cet outil reste souvent considéré comme moins utile que les JTBD pour les prises de décisions pendant la conception.
Un persona optimal repose en grande partie sur des caractéristiques comportementales complexes, des données sur l’attitude et des modèles mentaux, nécessitant également une recherche qualitative auprès d’utilisateurs réels, pour découvrir les raisons derrière le comportements des utilisateurs. Ces personas complexes incluent généralement des renseignements liés à des objectifs précis que les utilisateurs doivent atteindre lorsqu’ils utilisent le produit. Ces objectifs sont directement comparables aux renseignements trouvés dans la définition des JTBD.

Photo by Ashim D’Silva on Unsplash
Photo by Ashim D’Silva on Unsplash
Les personas bien conçus incluent des détails sur les objectifs des utilisateurs similaires à ceux des descriptions des jobs-to-be-done, mais sont enrichis de données comportementales, contextuelles et personnelles qui peuvent fournir un ensemble complet de pistes de réflexion pour guider les designers UX et les équipes de produits dans leur prise de décision. (Nous avons constitué le persona suivant comme exemple dans un rapport sur le développement efficace de produits Agile UX, mais il est représentatif des personas développés pour des projets qui utilisent une approche axée sur l’utilisateur pour la conception.)

LE MOINS : LES JOBS-TO-BE-DONE NE FAVORISENT PAS L’EMPATHIE

L’une des principales raisons pour lesquelles les personas se sont d’abord concentrés sur des représentations réalistes des utilisateurs, était de s’éloigner d’un modèle trop formel de l’Expérience Utilisateur articulé autour de listes de tâches et conditions à remplir.
Cela permet de réfléchir à ce que devrait être l’Expérience pour l’utilisateur. En effet, les JTBD prennent malgré tout quelques considérations sur le contexte émotionnel et social des motivations des utilisateurs. Cependant, ils généralisent ces informations pour la base entière des utilisateurs.
En conséquence, nous passons à côté de la notion clé du contexte d’utilisation précis de la cible et les designers perdent l’opportunité de créer de l’empathie envers l’utilisateur.

Photo by Samuel Zeller on Unsplash
Photo by Samuel Zeller on Unsplash
 

PRIORISER LES DIFFÉRENTS UTILISATEURS AVEC LES PERSONAS

Imaginons le scénario suivant : nous faisons partie d’une équipe de designers qui conçoit la nouvelle version d’une application de bureau de productivité. Ces dernières années, des concurrents sont entrés sur le marché avec des produits innovants et la direction de notre entreprise veut revoir le design de son produit afin d’être plus compétitif sur le marché. Bien qu’il soit utile d’interroger vos nouveaux clients existants et potentiels pour savoir quels JTBD sont importants pour eux, il est également intéressant de noter les différences essentielles parmi ces deux groupes.
Si nous partons de zéro pour le re-design de l’application, nous contraindrons les utilisateurs existants et fidèles à se re-former sur son utilisation, à cause d’une modification du parcours qu’ils avaient l’habitude d’emprunter. Cela aura en plus un impact négatif sur leur productivité. Si nous modifions complètement le design d’une ancienne fonctionnalité (ou, comme le suggère souvent la technique “jobs-to-be-done” : créons une solution entièrement différente et innovante pour le problème), nous risquons de pénaliser la base d’utilisateurs actuelle.

Photo by jose aljovin on Unsplash
Photo by jose aljovin on Unsplash
Durant la conception, il faut trouver l’équilibre entre les diverses options possibles selon le type d’utilisateurs, qui ont souvent des motivations différentes. Alors que tous les acheteurs d’une perceuse ont la même mission à accomplir (percer des trous), un professionnel regardera la durabilité de son outil, tandis qu’un amateur qui souhaite accrocher quelques cadres chez lui sera plus attentif au prix. Ces deux considérations étant conflictuelles, il est nécessaire de différencier et prioriser les utilisateurs si nous ne voulons pas nous retrouver avec une solution novatrice mais probablement insatisfaisante.
Alors que le même job-to-be-done peut avoir des exigences différentes pour différents groupes d’utilisateurs, l’inverse est également vraie : un groupe d’utilisateurs (ou persona) peut « embaucher » le produit pour différentes missions dans différents contextes.

Un exemple : les réservations en ligne

Je peux utiliser un même site de réservation pour des vols de déplacements professionnels et de loisirs. Ces types de voyage sont en fait des jobs-to-be-done distincts apportant des réflexions très différentes, mais mon modèle reste le même face au système qui m’est présenté, de même que mon attitude et mon comportement – que je me rende à une conférence NN/g UX ou faire une randonnée au Pérou. Mes comportements et mes attitudes sont susceptibles de ressembler à ceux de certains groupes d’utilisateurs comme de se différencier totalement de ceux d’un autre groupe. C’est pourquoi nous créons plusieurs personas : pour réfléchir aux différences entre utilisateurs qui nous permettent d’équilibrer les besoins et de les prioriser parmi les personas.
 

PERSONAS & JOBS-TO-BE-DONE : IT’S A MATCH !

Tandis que certains pensent que les JTBD peuvent remplacer totalement les personas, les deux sont en réalité compatibles. Selon les besoins du client et si l’équipe en charge du produit utilise déjà des personas ou des jobs-to-be-done, ils peuvent être utilisés de façon complémentaire : les informations apportées par l’outil JTBD peuvent être intégrées aux personas.

Photo by Jason Rosewell on Unsplash
Photo by Jason Rosewell on Unsplash
Pour les entreprises qui utilisent déjà les JTBD, il n’est pas nécessaire de dupliquer une tâche avec des personas : des personas précis peuvent compléter les JTBD existants avec des informations uniques et différenciatrices sur des critères de réussite fonctionnelle et/ou émotionnelle.
Et vice-versa : si ce sont les personas qui existent déjà au sein de l’entreprise, mais qui ne comportent pas les motivations complexes ainsi que les données comportementales essentielles pour un persona efficace, nous pouvons commencer par les améliorer avec des informations similaires aux JTBD. Commençons par améliorer les personas avec des informations similaires aux jobs-to-be-done : au lieu d’énumérer les buts de l’utilisateur, envisageons-les comme des objectifs à réaliser. Demandons-nous ce que l’utilisateur tente d’accomplir. Quelles sont les considérations de réussite clés (fonctionnelles et émotives) pour ces missions ?
S’il y a beaucoup de résistance au sein de l’entreprise pour la création de personas (si nos collègues sont sceptiques ou que notre hiérarchie peine à donner son feu vert), mais qu’il est toujours possible d’influencer le design de l’application grâce à une appétence et des moyens existants pour la conception centrée sur l’utilisateur, les JTBD peuvent être une alternative utile. En effet, la médiatisation autour de cet outil prisé peut susciter un certain engouement chez le client. Nous avons également pu constater que les JTBD peuvent tout à fait être utilisés en combinaison des personas dans un second temps.
 

Take Away

  • Faire appel à des utilisateurs représentatifs et leur confier des tâches représentatives pour réaliser des tests valides. Un design peut être parfait pour un groupe tout comme terrible pour un autre.
  • Différencier les publics ciblés et leurs motivations durant la conception d’un produit évite l’apparition de mauvaises fonctionnalités durant le processus. Utilisateurs et buts : les ingrédients nécessaires d’un UX Design réussi !
  • Comprendre l’utilité d’un persona bien exécuté permet de se représenter les besoins spécifiques des utilisateurs. Les informations complexes qu’il regroupe favorise l’empathie durant la conception d’un produit.

Source

Persona vs jobs-to-be-done, Page Laubheimer @Nielsen Norman Group

Références

Mise en contexte : Sébastien Faure, UX Content Manager @UX Republic @sebfaureUX / Phonesavane Soulivong, UX Communication & Marketing @UX Republic @psvn_soulivong / Traduction : Eric Bossin