L’art de présenter une user story

En tant que PO/PM une part importante de notre travail consiste à présenter nos user stories (pour la suite on restera sur “US”) dans de multiples situations :– Avec l’équipe Tech en refinement (ah oui vous êtes au courant qu’on évite maintenant de parler de “grooming” ?)
– En sprint planning
– Avec les parties parties prenantes lors de sprint review
– Avec le management/top management

Vous pouvez bien sûr les présenter directement et de la manière la plus classique qui soit (modèle proposé par Connextra à l’XPDay 2001) : le fameux “En tant que/je veux/afin de”.

Chez Wivoo, nous restons convaincus que c’est une bonne approche (bien que ce ne soit pas le seul modèle à privilégier). Mais un simple énoncé, avec peu de contexte ne rend pas hommage aux problématiques que vous souhaitez résoudre. Alors pour que vos stories aient plus d’impact et impliquent vos interlocuteurs, nous avons décidé de rédiger cet article pour vous donner quelques tips pour présenter vos US comme des pros à base de “Start with why”, “Love the problem” et storytelling.

Juste avant de plonger dans le sujet, nous tenons à préciser que l’on parle bien ici de « présentation orale » (bien que certains concepts puissent parfaitement s’appliquer à l’écrit).

Commencez par le problème

Allez, pas plus de suspens vous venez de lire le titre : nous ne conseillons pas de commencer par l’énoncé de l’US mais de toujours commencer par présenter le problème que vous cherchez à résoudre !
Cela permet à tous de comprendre rapidement ce que l’on cherche à régler, et surtout implique bien plus vos interlocuteurs dans la recherche de solutions créatives. Là où un énoncé “En tant que/je veux/afin de” peut involontairement réduire le champs des possibles, commencer par présenter le problème aligne toute l’équipe et les parties prenantes.

Comparons les deux façons de présenter pour une problématique e-commerce :

- Énoncé basique : “En tant qu’utilisateur venant d’acheter un produit via la fiche produit, je veux qu’une micro-interaction se déclenche sur mon panier afin de m’indiquer que l’item a bien été ajouté”.

L’énoncé de l’US est clair et construit dans les règles de l’art. En revanche, il ne permet pas de faire comprendre l’urgence et l’importance du problème que l’on cherche à résoudre. De plus, il empêche immédiatement vos interlocuteurs d’envisager différentes solutions qui pourraient être plus efficaces et plus créatives.

Une façon de commencer la présentation de cette US en présentant le problème pourrait être :
- “De nombreux utilisateurs nous remontent qu’ils ne comprennent pas si un élément est ajouté à leur panier lorsqu’ils le sélectionnent”.

On voit que la présentation du problème est bien plus impactante et laisse place à la discussion (ce qui reste la base d’une US, rappelez-vous les 3C. Vous pouvez (et devez!) ensuite énoncer l’US qui permet de régler ce problème.

Bon… on ne va pas se mentir… présenter le problème de cette manière est un bon début, mais vous serez d’accord pour dire que l’on peut surement faire mieux!

Illustrez, illustrez, illustrez !

Et oui! Loin de nous l’idée de ressasser ici des clichés “une image vaut mille mots”, ou “une démo vaut mille images” (bon ok ça c’est de nous), mais illustrer les problèmes de vos utilisateurs ne peut que donner plus de poids à vos présentation d’US.
Si vous cherchez à éliminer des “pain points”, montrez-les directement via une démo produit. Plus efficace encore, une session de replay d’enregistrement de tests utilisateurs ou d’enregistrement Hotjar.

Une autre possibilité très impactante : si vous disposez de data ou d’insight utilisateurs (voir le Wi-binar de Savinien), utilisez-les pour bien ancrer les problématiques.

Si vous présentez une nouvelle fonctionnalité, montrer en quoi elle va améliorer la vie de vos utilisateurs peut aussi se faire via des démos produit. Comme ce n’est pas toujours possible (nouveau produit par ex), vous pouvez illustrer les parcours utilisateurs et l‘expérience souhaitée via des prototypes ou des wireframes. Attention tout de même à laisser le plus de portes ouvertes pour ne pas brider la créativité des équipes.

Notre utilisateur ce héros

Dans tous les cas, pour bien présenter le problème, utiliser des techniques de storytelling ne peut que donner plus de force à vos récits.
L’idée ici est de captiver vos interlocuteurs pour approfondir leur implication.

Pour faire simple, le storytelling est l’art de raconter une histoire et fait appel à l’universalité de construction d’une bonne histoire.

Entre nous : il existe de nombreuses techniques de storytelling. Nous ne prétendons pas ici à exposer une liste exhaustive, loin de là, mais quelques éléments efficaces dans nos contextes de PO/PM.

Présentez votre personnage

Commencez par présenter votre personnage. C’est plus simple si vous utilisez déjà des personae partagés par l’ensemble de votre entreprise. Si ce n’est pas le cas, donnez lui un nom et précisez son statut. L’idée est que vos interlocuteurs se fassent une idée claire de qui il est, physiquement et mentalement et créer un lien empathique avec votre héros.

Décrivez le décor

Décrivez ensuite le décor où et dans quelle situation se trouve-t-il ?– où se trouve votre personnage? Chez lui après le travail? Dans les transports?
– A quel moment de la journée?

Basez-vous sur des éléments réalistes en restant simple (pas de description à la Victor Hugo SVP).

La grande aventure

A ce stade, vous avez fait naître une vision claire de qui est votre personnage et de l’environnement où il se trouve. Il est temps d’entrer dans le vif du sujet : la quête et les péripéties.
Pour cela, nous allons suivre le framework “3D” qui présente une aventure en 3 phases : Désir → Difficultés → Dénouement

- Désir : Votre héro doit avoir un désir, un besoin. C’est encore mieux s’il est déclenché par un élément perturbateur : réception d’un mail, affichage d’une notification ou une urgence à traiter.

- Difficulté : Seulement ce désir, qui semblait simple de prime abord, va se révéler compliqué à combler. C’est là que vous présentez le problème, en prenant bien soin de l’illustrer comme nous l’avons vu plus haut. Restez sur un aspect “récit”, c’est votre personnage qui a un problème.

- Dénouement : C’est ici que vous pouvez présenter votre user story : ce que vous voulez et pourquoi. Grâce à elle votre héro va pouvoir terminer sa quête.

Pro tips :
Pour ceux qui voudrait explorer encore plus loin cet aspect “Schéma narratif”et donner encore plus d’intensité à leurs récits, vous pouvez utiliser une “Storygrid”, concept inventé par Shawn Coyne (livre ici et playlist de 5 vidéos là).

Pour notre contexte, on simplifie en plaçant sur une grille les différentes étapes des parcours et les émotions positives ou négatives associées.

On peut y retrouver un léger air de les customer journey map, mais ici nous restons plus simple et centré sur le récit.Reprenons notre problème e-commerce vu précédemment et appliquons ce que nous venons de voir :

"Marcel commande ses écouteurs"
A la manière d’un conteur, adoptez une intonation “narrateur” et lancez-vous :
"Je voudrais vous parler de Marcel. En couple sans enfant, il navigue la plupart du temps sur notre site le soir après le dîner. Posé sur le confortable fauteuil de son salon, il commande souvent des articles tech via sa tablette.

Hier soir, il a reçu un mail l’avertissant d’une promotion sur des écouteurs bluetooth sur lesquels il lorgnait depuis quelque temps. Il se connecte donc sur notre site et arrive directement sur la page produit via le lien du mail."

(Par exemple vous pouvez ici illustrer le parcours que vous allez décrire en effectuant en live le parcours utilisateur)

"Satisfait de constater qu’il s’agit bien de ces écouteurs, il clique sur le bouton “Ajouter à mon panier”. Jusque là l’expérience est nette et sans coutures. Marcel est dans un état de satisfaction profonde et se voit déjà écouter sa musique préférée."

Mais que se passe-t-il maintenant?

La page produit est toujours affichée et le bouton “Ajouter à mon panier” semble le narguer. Marcel commence à douter : les écouteurs ont-ils été ajouté à son panier? Doit-il cliquer une nouvelle fois sur le bouton d’ajout au risque de se retrouver avec plusieurs fois le produits dans son panier? Plus très sûr de lui, il se dit que finalement il n’y a pas d’urgence et reviendra dans les prochains jours finaliser peut-être sa commande.

Là vous pouvez maintenant sortir du schéma narratif et insister sur le problème avec des données montrant que x% des utilisateurs ajoutent des produit en double ou abandonnent leur achat immédiatement suite à l’ajout dans le panier. Vous pouvez aussi jouer des sessions Hotjar montrant ce problème.

A ce stade, vos interlocuteurs devraient avoir saisis ce que vous cherchez à résoudre et vous pouvez présenter votre story de manière plus classique et comment vous pensez résoudre le problème (ou comment il a été résolu si c’est ce que vous présentez).

Bonus : Story grid de Marcel

Derniers conseils

– Adaptez votre discours à vos interlocuteurs (équipe tech vs top management)
– Restez focus sur l’outcome (le bénéfice utilisateur) et non pas output (la fonctionnalité tech que vous souhaitez développer).

– Variez les personnages et les situations

– Variez la narration : point de vue “narrateur” ou personnage

– N’en faite pas trop non plus dans le suspens et le drama au risque de desservir vos propos.

Pour finir

Alors évidemment nous ne vous conseillons pas de commencer la présentation de toutes vos US de cette façon. D’abord car cela prendrait trop de temps et surtout vous finiriez pas lasser votre auditoire. Réservez-là pour des stories importantes.
Nous savons que la façon de présenter vos US dépend aussi de votre personnalité et de vos interlocuteurs. Il n’y a pas d’universalité dans les façons de faire.

Nous restons convaincus que la présentation des US est une des compétences fondamentales d’un PO/PM et savons que chacun d’entre vous à ses propres façon de faire et tips.

‍