Personae : quand, pourquoi, comment ?

Ceci n’est pas un guide pour créer un persona 🙂 Il en existe beaucoup. Si c’est ce que vous cherchez, allez voir par exemple ce très bon article de Ben Ralph sur le blog Marvel.

Ici je souhaite plutôt vous expliquer quand, pourquoi, comment utiliser un ou des personae. Et en quoi cela va aider l’équipe projet à concevoir un produit user-centric, qui répondra à un vrai besoin.

Quand ?

Le plus tôt possible ! Commencer à concevoir un produit digital sans connaître son utilisateur, c’est le meilleur moyen de créer un produit qui ne sera jamais utilisé.

Nous avons tous rencontré ce cas de figure au cours de nos expériences professionnelles. Il m’est arrivé chez un client de devoir repenser complètement l’UX d’une application métier qui venait pourtant d’être entièrement mise à jour. Motif ? Les employés – et utilisateurs finaux de l’application – n’avaient absolument pas été intégrés à la conception de l’application. A sa sortie, la nouvelle application présentait des pain points énormes par rapport à l’ancienne version. Les employés, qui travaillaient sous haute pression – la vie d’autre êtres humains dépendait de leur travail, travail qui passait obligatoirement par l’app métier repensée – se sont tout simplement mis en grève pendant 40 jours afin de forcer la direction à revenir à l’ancienne version de l’app. Autant dire que la direction a compris le sens du mot user-centric et n’a pas hésité à intégrer ses employés à la conception de la mise à jour V2 !

Dans l’idéal, avoir déjà rassemblé un peu de matériel sur les utilisateurs finaux du produit avant même la phase de cadrage / framing / Sprint 0 / Design Sprint… va s’avérer extrêmement utile. L’équipe produit, les autres stakeholders vont pouvoir s’appuyer sur ce matériel afin de commencer à concevoir le produit. Cela ne dispense pas de vérifier les hypothèses élaborées lors de cette phase de cadrage tout au long de la conception du produit et après ! Rien n’est figé.

Pourquoi ?

Pour placer l’empathie avec l’utilisateur à la base de notre réflexion produit. Pour éviter de projeter nos propres schémas de compréhensions sur les utilisateurs. Ça fait partie des biais cognitifs auxquels personne n’échappe. C’est pour ça qu’un persona, de préférence affiché au mur, nous rappelle à l’ordre.

Que va-t-il se passer si l’on ne s’intéresse pas à l’utilisateur ?

Dans le cadre de la création d’un nouveau produit :

  • dans le meilleur des cas on aura du matériel récolté par une direction client, mais récolté quand, dans quelles conditions, avec quel parti pris : on prend le risque de baser notre conception produit sur une fausse idée de l’utilisateur,
  • dans le pire des cas, on aura juste une intuition du Product Owner ou autre décideur en charge de la conception produit, qui confond ses propres usages et ceux de l’utilisateur final : on prend le risque de concevoir une application sur mesure pour un seul utilisateur, le PO.

Dans le cadre d’une refonte :

  • dans le meilleur des cas on va refaire la même application que précédemment, répéter les succès et les échecs,
  • ou bien on va faire pire (cf anecdote au-dessus).

Comment ?

Dans l’idéal, aller à la rencontre de plusieurs key users (entre 5 et 10).

A défaut, se baser sur tout le matériel que l’on peut trouver : analytics, études… Attention, on n’aura pas le même résultat si l’on reste derrière son écran. Rien ne vaut la rencontre d’un utilisateur dans son « milieu naturel » pour comprendre le contexte d’utilisation du produit, les émotions, bref : avoir de l’empathie.

Les do

Le persona à la base de la conception produit

Pour moi, le persona se résume surtout à trois choses essentielles :

  • son but
  • ses pain points
  • le contexte d’utilisation

Connaître son but est important pour savoir sur quels triggers psychologiques on pourra jouer : qu’est-ce qui le motive, l’influence…

Connaître le contexte d’utilisation est important pour l’UX design : devices utilisés, design émotionnel, accessibilité…

Last but not least : connaître ses pain points est important pour la conception produit. Qu’est-ce qui va créer de la valeur pour l’utilisateur ?  Est-ce que le produit résout un problème de temps, argent, satisfaction… Dans ce cadre, le persona sera l’outil idéal pour amorcer une product vision ou un impact mapping.

Se baser sur les pain points plutôt que sur les but avoués pour concevoir son produit

Parce que l’utilisateur sait mieux ce qui le gêne que ce qu’il veut. Parce que son métier n’est pas de concevoir des applications.

Parce qu’on casse nos propres règles.

Dans Modern Romance, Aziz Ansari explique pourquoi Tinder a gagné la bataille du dating en ligne.

« While we may think we know what we want, we’re often wrong. According to Dan Slater’s history of online dating, Love in the Time of Algorithms, the first online dating services tried to find matches for clients based almost exclusively on what clients said they wanted. The client would usually fill out a survey indicating certain traits they were looking for in a partner. For example, if a man said he was looking for a tall, blond woman with no kids and a college degree, the company showed him everyone who fit this description. But pretty soon online dating companies realized that this wasn’t working. In 2008 Match.com hired Amarnath Thombre as its new “chief of algorithms.” Thombre set about figuring out why a lot of couples that Match.com’s algorithm said were a perfect fit often didn’t make it past the first date. When he began digging into the data, he discovered something surprising: The kind of partner people said they were looking for didn’t match up with the kind of partner they were actually interested in.

Thombre discovered this by simply analyzing the discrepancy between the characteristics people said they wanted in a romantic partner (age, religion, hair color, and the like) and the characteristics of the people whom they actually contacted on the dating site. “We began to see how frequently people break their own rules,” he told Slater. “When you watch their browsing habits—their actual behavior on the site—you see them go way outside of what they say they want.” »

Prioriser, prioriser, prioriser

Prioriser les personas, prioriser les pain points, prioriser les solutions.

Très simple à écrire, très dur à faire, du début à la fin d’un projet. C’est pour ça que le persona et l’impact mapping sont de très bons outils pour garder le cap tout au long du projet. Attention ! On peut toujours changer de cap si l’on se rend compte qu’on fonce tout droit sur le phare !

Les don’t

Un persona par user

J’ai déjà vu des PO débutants exiger la production d’un persona pour chaque key user rencontré. C’est un non-sens.

Un persona n’est pas le descriptif d’un seul user, il représente une population d’utilisateurs. Le travail de l’UX consiste à choisir des keys users représentatifs de la cible que le business souhaite atteindre. Et ensuite, à isoler les informations à la fois pertinentes pour le produit, et qui se répètent de manière significative sur l’échantillon de key users choisi. On fait l’hypothèse qu’il sera représentatif de toute la cible du produit, par extension. Si l’on a plusieurs cibles, on peut faire plusieurs personae, du moment qu’on les priorise entre eux.

Au début d’un projet (bon, après aussi), tout n’est qu’hypothèse : ce sont les limites de l’exercice et le début de l’itération / pivot.

Le marketing a peut-être identifié une population cible pour le produit, sur laquelle s’est basée l’UX pour constituer le groupe de key users. Mais lors de la conception ou du développement du produit, tout peut être remis en cause. Un nouveau problème à résoudre pour le produit, une nouvelle cible… Tout est lié. Ce n’est pas grave, du moment que l’on ne cède pas aux sirènes de l’escalade de l’engagement.

Les personae qui suivent un template ultra détaillé

Le fond avant la forme. Ne cherchez / gardez que les informations judicieuses.

Est-ce que le job de mon persona est pertinent pour trouver les problématiques que mon produit va résoudre ? Oui : on garde. Non : on enlève de la persona.

Simple. On gagne du temps. On garde des forces pour la suite 🙂