vendredi 3 avril 2015

Les Personas, une question d’émotion !

Les Personas, c’est quoi ?

« Personas provide you with the opportunity to integrate real User Experience all along your product development project » Alan Cooper in 1999 Intégrer de l’expérience utilisateur tout au long du développement d’un projet est une très bonne idée, d’ailleurs ça me rappelle quelque chose, cette « Review » que l’on fait à la fin de chaque sprint avec l’équipe Scrum et tous les gens impliqués dans le projet y compris les utilisateurs ! Ils sont là mes Personas ! Des vrais utilisateurs que je convie à chaque « Review » et qui vont me faire un retour en direct sur ce qui a été produit.

Voilà c’est tout, sujet suivant… à moins que



Inutiles vraiment ?

Posons-nous quelques questions simples :
  • Mes utilisateurs viennent-ils à chaque Review ?
  • Mon équipe a-t-elle toujours conscience qu’elle n’est pas l’utilisateur du produit qu’elle développe ?
  • Mon équipe est-elle vraiment engagée dans la réalisation du produit ?
  • La vision est-elle vraiment et charnellement comprise par tout le monde ?
  • Les user story « en tant qu’utilisateur… » sont-elles vraiment bien comprises ?
  • Suis-je capable de regrouper toutes les UserStory qui correspondent à un utilisateur type ?
Un bon moyen de répondre par la positive à toutes ces questions serait d’immerger complètement l’équipe Agile dans l’univers des utilisateurs du produit qu’ils développent mais encore une fois et même si c’est souhaitable ce ne sera pas toujours possible.  

Une première piste

En partant de ces questions, une première évidence vient assez vite à l’esprit. Puisque le Product Owner a bien fait son travail et qu’il a identifié des utilisateurs, que ces personnes existent vraiment  alors créons de simples fiches d’identité avec le prénom et la photo. Ajoutons sur ces fiches en quelques mots ce qui les motive dans l’utilisation de ce produit. Affichons ces fiches dans l’open space afin que l’équipe garde à l’esprit cette idée : « Les utilisateurs existent bien et voilà pourquoi ils veulent ce produit »

Allons plus loin

Je connais la motivation principale de mes utilisateurs, par exemple : Ils aiment boire du thé au bureau Ok, ils veulent boire du thé  au bureau et ça tombe bien, l’équipe développe une machine à thé. Restons du côté de nos utilisateurs et posons-leurs quelques questions supplémentaires : Cette machine, elle a quelque chose de plus ? Oui elle ne fait pas de gouttes Pourquoi voulez-vous acheter cette machine ? Parce qu’elle est design et que tous nos collègues vont nous l’envier ! Voilà des informations supplémentaires qui seront utiles à l’équipe. Ça nous donne :
  • « Paul »
  • Photo
  • Je veux une solution pour boire du thé au bureau
  • Je veux une machine qui ne fasse pas de goutte
  • Je veux une machine design qui fasse envie à mes collègues
  • J’ai envie d’être celui ou celle chez qui tous les collègues viennent boire un thé à la pause
Ma Persona tout en restant simple exprime des désirs, des motivations – elle créé une dynamique.  

Mais n’allons pas trop loin non plus

Attention la fiche Persona n’est pas un CV, savoir que l’utilisateur est né en Normandie et a fait l’Essec ne nous apportera rien (à moins de développer un outil pour commercialiser le camembert…) Seuls les éléments qui ont attrait à l’expérience que notre utilisateur aura avec le produit nous intéressent. De plus ces éléments doivent être partagés avec tous les utilisateurs du groupe, une information trop personnelle ne nous servirait à rien :
  •  « Paul » aime le rouge
  •  « Paul » met des costumes trop petits
 

Moi je n’ai pas d’utilisateurs, j’ai des Personas !

Vraiment pas d’utilisateurs ? Même pas un petit ? Un voisin ? Un ami d’enfance ? Sérieusement sans utilisateurs il n’y aura pas de bon produit et si par malheur vous découvrez que cette absence d’utilisateurs est palliée par des fiches Personas très remplies alors fuyez… Les Personas ne sont pas des personnes virtuelles dont on a inventé la vie, JAMAIS ! Il ne s’agit pas d’écrire des personnages de fiction, il s’agit de développer un produit utilisable et utile pour des gens qui existent !  

Alors finalement une Persona c’est quoi ?

Une Persona est la représentation d’une réalité et non pas la supposée réalité. Une Persona est un moyen de créer de l’engagement et de l’empathie dans l’équipe Scrum. Une Persona est un moyen de définir une compréhension commune de l’utilisateur final.  

Comprendre mon utilisateur ?

Oui il s’agit bien de le comprendre mais comment être certain que nous l’avons toujours bien compris ! Certains canevas de Personas proposent des outils de mesure, des graphiques, des codes qui permettent en un coup d’œil de ranger la Persona dans une case. Pourquoi pas, nous pouvons aller très loin dans l’analyse comportementale, sociétale de notre utilisateur, peut-être même que dans son contexte de vie nous allons comprendre pourquoi il aime le thé et il a la phobie des gouttes qui tombe sur le bureau… Mais posons-nous la question de savoir si ces informations seront-utiles à l’équipe. Le sont-elles ? Je ne sais pas encore Bien entendu nous ne le savons pas par avance car il est fort probable que la fonctionnalité anti-goutte de notre machine à thé ne sera développée qu’au Sprint 12 et que son impact sur l’usage devra être connu à ce moment précis en prenant en compte ce qui a déjà été produit. Alors demandons aux utilisateurs ce qu’ils ressentent vis-à-vis d’une fonctionnalité au moment où nous la développons et pas avant.

Faisons un pas vers l’expérience utilisateur (UX)

«L’expérience utilisateur fait référence à l’ensemble des évènements, des situations, des sensations, que sera amené à vivre l’utilisateur face à un produit et qui marquera de manière durable,  positivement ou négativement ses souvenirs. » (http://www.gerardngoundji.com/blog/?p=65) Peter Morville grand spécialiste de l’UX décompose l’expérience utilisateur en critères qui donnent de la valeur au produit :

  UX

Le désir, l’utilité, la crédibilité, accessibilité… nous parlons là aussi de « ressenti » ! Si je comprends bien, je dois m’intéresser au ressenti de l’utilisateur fasse à mon produit pour améliorer l’expérience qu’il en aura ? Et oui ! Mais pour connaître ce ressenti, je dois lui faire tester le produit ? Et oui ! Mes utilisateurs devront dont être disponibles durant tout le développement du produit ? Et oui !   Le Sprint 12 est terminé, la fonctionnalité anti goutte est développée, l’équipe est très fière ! « Paul » teste la machine et effectivement aucune goutte ne tombe sur son bureau C’est génial ! Sauf que… La fonctionnalité anti-goutte est moche et Paul dit : C’est obligatoire ce gros truc sur le côté-là ? Et l’équipe répond : Oui c’est pour la fonctionnalité anti-goutte, on a pas eu le choix… « Paul » répond : Je trouvais la machine plus jolie avant… C’est perdu… « Paul » ne trouve plus la machine aussi cool qu’avant et il ne l’achètera pas, il en prendra une autre qui fait peut-être parfois des gouttes mais qui lui donnera le ressenti qu’il attend car au fond c’est ce qui est le plus important pour lui ! Ce n’est pas l’utilisateur qui adapte son ressenti au produit, c’est le produit qui procure à l’utilisateur le ressenti qu’il attend (même inconsciemment)

Comprendre le ressenti de l’utilisateur

Les utilisateurs auront certainement beaucoup de mal à définir le ressenti qu’ils attendent du produit lors de la phase de réflexion. Pour cela il peut être intéressant de leur poser des questions qui vont les amener à exprimer des émotions :
  • Pensez-vous que ce produit va changer votre vie ? Va vous aider à changer de vie ?
  • Quel type d’émotion ce produit va-t-il vous procurer ? (bonheur, fierté, tranquillité…)
  • Ce produit doit-il être simple à utiliser ?
  • Allez-vous l’utiliser fréquemment ?
  • Ce produit va-t-il vous aider à trouver une information précise ?
  •  Ce produit va-t-il vous aider à conquérir le monde ?
Noter que « Allez-vous l’utiliser fréquemment ? » nous renseigne indirectement sur l’émotion que ressentira l’utilisateur si le produit nécessite par exemple de remplir le réservoir d’eau après chaque thé ! Les questions vont permettre de questionner les utilisateurs sur le ressenti qu’ils ont vis-à-vis des fonctionnalités qu’ils attendent : « Si la fonctionnalité anti-goutte était absente seriez-vous ? » « Indifférent, déçu ou très déçu ? » Et mixer ce résultat avec la besoin exprimé pour la fonctionnalité « Pour vous, la fonctionnalité anti-goutte est-elle : » « Pas importante, importante ou très importante ? » Ces deux questions vont nous donner deux informations très complémentaires qui vont permettre de mieux comprendre l’utilisateur, un produit peut-il se passer d’une fonctionnalité « pas importante » mais dont l’absence serait perçue comme « très décevante » ? A contrario ne faudrait-il pas remettre en cause une fonctionnalité « très importante » mais dont l’absence laisserait l’utilisateur « indifférent » ? Les réponses à toutes ces questions vont nous permettre d’écrire petit à petit l’expérience utilisateur sous forme d’une histoire avec des bonheurs et des drames… une dramaturgie en trois actes :

Acte 1

C’est l’hiver, Paul arrive au bureau et une collègue lui dit de garder son manteau parce qu’il fait froid, le chauffage est en panne.Paul pense immédiatement à sa nouvelle machine à thé anti-goutte et il se réjouit ! Mais il se souvient aussi vite qu’il a fini sa dernière capsule hier, il est désappointé ! Il arrive dans son bureau et découvre sur la table un colis rempli de capsule à thé. La fonctionnalité de re-commande automatique a fonctionné ! Paul se dit que cette machine est géniale et qu’il va pouvoir se faire un thé.

Acte 2

Il choisit son thé avec envie mais se bat quelques instants avec l’emballage «préservation de saveurs » des capsules, ses ciseaux ont encore disparu ! Enervé, il déchire l’emballage avec les dents. Il allume la machine et un message lui indique « ERROR-03 », Paul est furieux ! Il se précipite sur le site internet du fabriquant, il trouve tout de suite l’onglet « Support » en haut de page et arrive en deux clics sur la liste des erreurs. « Le réservoir d’eau est vide » Paul est soulagé, ce n’est pas grave et il a trouvé la solution très rapidement.

Acte 3

Paul rempli le réservoir et se fait un thé. Alors qu’il prend son mug une goutte de thé tombe sur un contrat très important exactement sur la signature qui devient illisible. C’est la catastrophe, Paul maudit cette machine et se dit qu’il aurait bien mieux fait de prendre le modèle moins design mais qui ne goutte pas. Sa collègue entre dans le bureau, elle s’extasie sur la machine qu’elle trouve vraiment super belle. Paul lui parle du contrat tâché et elle lui avoue que la veille elle est venue se faire un thé pendant qu’il était en réunion et qu’elle en avait profité pour faire une copie du contrat pour s’en inspirer ! La machine à thé fait envie à ses collègues .

Final

Paul sourit et lui offre un thé !
  L'utilisation du produit est une succession de "problèmes" auxquels le produit apporte une "solution" et qui laisse à l'utilisateur un certain "ressenti". La machine à thé s’inscrit dans l’histoire de Paul, elle joue un rôle, elle lui procure des émotions positives et négatives mais au final elle l’amène à bon port et c’est pour cela qu’il l’aime et qu’il continuera de l’utiliser.

Conclusion

L’histoire s’écrit en même temps que le produit se développe, les utilisateurs expérimentent, le produit évolue et la Persona est une photographie de l’état émotionnel des utilisateurs vis-à-vis du produit à un instant  T. La description de la Persona doit toujours rester minimale et suffisante par rapport à l’état d’avancement du produit : Just In time Persona



1 commentaire:

  1. Tiens, mon précédent commentaire n'a pas fonctionné ? Article très intéressant Basile, tout comme ce nouveau blog, mais cela ne m'étonne pas... A bientôt ? Bises

    RépondreSupprimer