#2 – 🕵🏻‍♂️ DĂ©finir et tester le parcours clĂ© de Festview

[Ce billet est le 2ème volet de la Saga Festview – Mettre en ligne un WikipĂ©dia de la musique]

Dans l’Ă©pisode prĂ©cĂ©dent, 1. Consolider la vision de Festview , on a vu que :

  1. Lors d’une session exploratoire de navigation, je n’avais pas rĂ©ussi Ă  comprendre le projet global de Festview car jusqu’Ă  ce jour, il n’avait Ă©tĂ© prĂ©sent que dans l’esprit du fondateur
  2. Que les business qui Ă©crivent et diffusent leur vision ont de meilleures chances de rĂ©ussite ; d’autant plus lorsqu’ils portent attention aux 6 paramètres majeurs d’une vision efficace
  3. Un atelier de 2h nous a permis de rédiger une plateforme de marque, contenant la vision, et de la publier sur le site
  4. Cette dĂ©marche avait crĂ©Ă© un gain de confiance, de motivation, d’alignement ; ainsi que de nouvelles idĂ©es fortes pour Festview

Dans cet opus, je vais parler de l’urgence numĂ©ro 1 qui, Ă  mon sens, doit prĂ©occuper un Product Manager lorsqu’il prend un nouveau produit en main : identifier son parcours clĂ©. C’est-Ă -dire l’expĂ©rience utilisateur qui porte la promesse du projet avec le plus de puissance. Je vais raconter comment, pour Festview, nous avons imaginĂ© ce parcours clĂ©, puis comment nous avons menĂ© une grande phase de tests d’utilisateurs pour mesurer l’efficacitĂ© de ce parcours.

Le parcours clé 🎵

Après avoir clarifiĂ© le positionnement de Festview avec une vision bien rĂ©digĂ©e et publiĂ©e, il fallait dĂ©sormais proposer l’expĂ©rience adĂ©quate aux utilisateurs.

Nous rĂŞvions notamment de complĂ©ter le parcours de l’Ă©poque avec une brique supplĂ©mentaires : donner des rĂ©compenses aux utilisateurs qui gagnent des points grâce Ă  leurs contributions.

Cette fonctionnalitĂ© n’Ă©tait pas encore prĂ©sente sur le site ; il fallait l’implĂ©menter. Et cela allait prendre du temps Ă  construire…

  • Permettre aux administrateurs de crĂ©er des rĂ©compenses – 1 semaine
  • Permettre aux utilisateurs de consulter, trier et filtrer des rĂ©compenses – 2 semaines
  • Permettre aux utilisateurs de consulter, liker et partager le dĂ©tail d’une rĂ©compense – 2 semaines
  • Permettre aux utilisateurs d’obtenir leur rĂ©compense contre leurs points – 1 semaine
  • Livrer la rĂ©compense aux utilisateurs – 1 semaine
  • Trouver des partenaires business intĂ©ressĂ©s pour faire leur promotion Ă  travers des rĂ©compenses – 3 semaines

Pour une expĂ©rience utilisateur complète et bien faite, ce chantier reprĂ©sente Ă  lui seul une charge de travail de plusieurs mois. Or nous n’avions pas ce temps lĂ .

Story mapping : se concentrer sur l’essentiel 🎵

Nous avons donc retravaillĂ© ensemble la feature de « RĂ©compenses » Ă  l’aide d’un Story Mapping. A mon sens, c’est le meilleur outil dans ces cas lĂ  : il permet d’identifier ce qui est vraiment nĂ©cessaire pour que la feature fonctionne, versus tout ce qui est superflu. Le but est de garder l’essentiel, et de remettre Ă  plus tard tout le reste.

L’exĂ©cution s’est traduite par un atelier de 2 heures :

  1. Introduction au Story Mapping, avec l’exemple de la routine matinale*. Super simple et efficace : en 20min nous Ă©tions parfaitement alignĂ©s sur la mĂ©thodologie
  2. Listing des grandes fonctionnalité et des sous-fonctionnalités du parcours
  3. Réduction du parcours aux fonctionnalités et sous-fonctionnalités indispensables

*Je publierai prochainement un contenu Ă  propos de cet atelier « Routine Matinale », car je n’ai pas trouvĂ© de ressources solides dessus. C’est un atelier bien connu qui consiste (1) Ă  imaginer collectivement une routine matinale parfaite. Câlin dans le lit, cafĂ©, tartines, journal, salle de bain, choix des vĂŞtements,… (2) puis Ă  la dĂ©grader sous la pression d’une panne de rĂ©veil. Il en ressort « un parcours minimal » qui ressemble souvent Ă  « je m’habille, je brosse mes dents et je file ».

Voilà le résultat de notre travail ce jour là :

Impliquez l’Ă©quipe 🎵

Construisez-vous les story maps de vos projets de fonctionnalités directement avec votre équipe de développement ?

Je pense qu’il le faut. Peut-ĂŞtre pas pour faire la dĂ©composition de Tous les projets de features qui entrent dans le backlog. Mais au moins pour les features majeures ; celles qui mĂ©langent du back-end, du front-end, du design,… Grâce Ă  cet exercice, les prioritĂ©s sont bien comprises par tout le monde. L’Ă©quipe – ici, l’unique dĂ©veloppeur de la boite – peut se mettre au travail immĂ©diatement en sachant exactement pourquoi elle dĂ©veloppe chacune des briques de la fonctionnalitĂ©. En un mot :

Construire la story map d’une feature avec son Ă©quipe, c’est la promesse d’un passage fluide des idĂ©es au dĂ©veloppement.

Ainsi, mon ami a entamé aussitôt la construction de la feature minimale que nous avions définis ensemble. La semaine suivante, cette dernière était livrée :

Tests utilisateur 🎵

Reprenons. Vision ⇒ Positionnement ⇒ IdĂ©es de parcours ⇒ FonctionnalitĂ© ⇒ Dev ⇒ …. il restait plus qu’Ă  savoir ce que les utilisateurs en pensaient.

Grâce aux outils adaptĂ©s (voir partie outils plus bas), en un jour nous avons bookĂ© 20 rendez-vous avec des proches susceptibles d’ĂŞtre intĂ©ressĂ©es par Festview. Pourquoi 20 ? La thĂ©orie dit qu' »entre 20 et 30 entretiens sont nĂ©cessaires avant d’ĂŞtre capable de savoir Ă  l’avance ce que vont dire les utilisateurs Ă  propos du produit. Une fois que c’est le cas, c’est qu’il n’y a plus rien Ă  apprendre, et qu’on peut se mettre au travail.« (Ash Maurya – Running Lean)

J’ai prĂ©parĂ© un script d’entretien, comme le suggère la mĂ©thode. Avec une intro, des questions et une conclusion. La rĂ©pĂ©tition schĂ©matique du mĂŞme script Ă  chaque interview favorise la dĂ©tection des propos intĂ©ressants des utilisateurs. J’ai Ă©galement prĂ©parĂ© des outils permettant de rĂ©ceptionner correctement toute la masse d’informations que nous allions recevoir.

Le contenu du test utilisateur Ă©tait relativement libre. Voici ce que nous souhaitions obtenir :

  • un ressenti gĂ©nĂ©ral de l’utilisateur sur le concept. Que pensait-il de l’articulation entre encyclopĂ©die, recherche de contenu, contribution, points, rĂ©compenses,…)
  • un ressenti sur la fluiditĂ© de la navigation
  • une dĂ©tection des bugs les plus rĂ©currents et les plus embĂŞtants

Pour obtenir ces informations, nous avons optĂ© pour une navigation semi-guidĂ©e. L’utilisateur Ă©tait libre de ses mouvements sur l’app, et racontait Ă  voix-haute ce qui lui passait par la tĂŞte, et de temps en temps, nous demandions d’aller spĂ©cifiquement sur une fonctionnalitĂ© pour complĂ©ter l’expĂ©rience.

Nous lançâmes, donc, cette sĂ©rie d’entretiens.

A la fin de chacun des 5 premiers entretiens, nous prenions toujours un court moment avec le fondateur sur notre mĂ©thodologie, afin d’affiner le script. Et au terme de chaque jour de travail nous dĂ©briefions des apprentissages majeurs de la journĂ©e.

Au bout de 5 à 8 entretiens, nous avions déjà détecté le plus gros problème à corriger.

Au bout de 15, ce problème devenait aussi visible que le nez au milieu de la figure.

Au bout de 21 (oui nous en avions fait un p’tit dernier pour la route), nous mourrions d’envie de passer Ă  l’Ă©tape d’après pour rĂ©gler ce soucis qui avait concernĂ© 100% des utilisateurs.

Débrief des interviews 🎵

« Je ne comprends pas trop comment ça fonctionne »

VoilĂ , le problème c’est que les utilisateurs, ne comprennent pas immĂ©diatement le fonctionnement gĂ©nĂ©ral de l’application. [je reprends la narration au prĂ©sent, car c’est lĂ  oĂą nous en sommes !] Les diffĂ©rents verbatims que nous avons rĂ©coltĂ©s Ă  ce sujet ressemblent Ă  cela :

  • [depuis la page d’accueil, dès les premières secondes] « Okaaay, donc lĂ  je vais lancer une recherche, mais je ne sais pas tellement ce que ça va donner. Mais c’est beau en tout cas ! »
  • [depuis la page d’un artiste, après quelques secondes de navigation] « Hmm… en fait je crois que j’ai pas trop compris le système de points. Je suis content de voir qu’il y a des contributeurs et que c’est participatif, mais je ne sais pas comment faire pour en gagner moi aussi« 
  • [depuis la page des rĂ©compenses, après plusieurs minutes de navigation] « Aaaaah d’accoord, donc en fait on crĂ©Ă© des pages, on gagne des points et ensuite on peut Ă©changer contre des rĂ©compenses… ça marche ! Mais c’est trop bien ! Pourquoi vous ne le dites pas dès le dĂ©but ?« 

Ce sont des retours très encourageants : les utilisateurs ont systĂ©matiquement approuvĂ© le concept et donnĂ© des feedbacks spontanĂ©s très riches sur ce qu’ils trouvaient de positif dans l’application. Il faut simplement mieux mettre en avant notre parcours clĂ©. Il faut plonger l’utilisateur dans ce parcours clĂ© dès sa première visite, dès ses premières secondes de navigation, pour lui faire comprendre et apprĂ©cier tout le projet de Festview en quelques manipulations.

Je décrirai précisément le projet de feature que nous avons élaboré grâce à ces retours dans les épisodes à venir. Pour la fin de cet opus je préfère terminer de détailler la fin de la méthode de récolte de feedbacks, très importante pour la suite.

En tout et pour tout, nous avons rĂ©coltĂ© 104 insights diffĂ©rents avec ces tests. Par 104 insights, il faut comprendre 104 remarques diffĂ©rentes qui ont Ă©tĂ© formulĂ©es sur Festview. Par exemple, les 21 utilisateurs qui ont chacun dit « le positionnement de l’app n’est pas clair pour moi dès la page d’accueil« , cela ne compte que pour 1 insight.

Naturellement, un insight qui a Ă©tĂ© formulĂ© par plusieurs utilisateurs paraĂ®t plus important qu’un insight qui n’a Ă©tĂ© mentionnĂ© qu’une seule fois.

Grille de User Impact Score 🎵

Mais, pour ĂŞtre prĂ©cis dans la priorisation, chaque insight doit ĂŞtre pondĂ©rĂ© avec un User Impact Score. C’est-Ă -dire qu’il faut prendre en compte l’importance qu’avait cet insight pour l’utilisateur qui l’a formulĂ©. C’est nĂ©cessaire car si tous les insights avaient le mĂŞme poids, on pourrait se retrouver avec des incohĂ©rences comme :

"Je trouve que la couleur du bouton ne va pas avec le reste" x 21 utilisateurs

↓ a le même poids que ↑

"Je ne peux pas créer la page d'un artiste car le formulaire ne fonctionne pas" x 21 utilisateurs

Dans la majoritĂ© des cas on souhaitera donner un poids total plus important au second insight de cet exemple. L’utilisateur semble bloquĂ© dans sa tâche, contrairement au premier insight, oĂą il semblerait qu’il ne s’agisse que d’une prĂ©occupation esthĂ©tique.

Pour arranger cela, on va donc multiplier par un score allant de 0 Ă  3 Ă  chaque fois que l’utilisateur mentionne un bug ou une suggestion d’amĂ©lioration, en suivant cette grille :

En appliquant cette grille Ă  l’exemple utilisĂ© plus haut on obtiendrait :

« Je trouve que la couleur du bouton ne va pas avec le reste » x 21 x 1 = 21 points

« Je ne peux pas crĂ©er la page d’un artiste car le formulaire ne fonctionne pas » x 21 x 3 = 63 points

Il faut noter que tous les utilisateurs n’ont pas le mĂŞme regard sur les problèmes qu’ils rencontrent. Certains ont par exemple des exigences particulières en termes de graphisme, tandis que d’autres seront davantage dĂ©rangĂ©s par la syntaxe ou la fluiditĂ© de la navigation. Il faudra donc ĂŞtre capable de mettre en avant ces diffĂ©rences de perception, comme dans ce nouvel exemple :

« Les artistes ne sont pas triĂ©s par ordre alphabĂ©tique » a Ă©tĂ© dit par 14 utilisateurs au total.

Pour 7 d’entre eux, c’Ă©tait très dĂ©rangeant. Pour 5 autres, ce n’Ă©tait pas grave. Enfin, les 2 derniers ont dit que ça pourrait aller, si seulement le tri Ă©tait alĂ©atoire, sans ĂŞtre surs que ça leur plairait.

Poids total de l’insight = (7 x 2) + (5 x 1) + (2 x 0) = 19 points

Pour Festview, nous avons terminĂ© la phase de tri et de priorisation avec un user impact score total de 620 points pour l’ensemble des 104 insights relevĂ©s.

Tri des insights 🎵

Dans ProductBoard, nous avons ensuite rattachĂ© chaque insight Ă  des projets d’amĂ©lioration. Ces projets sont dĂ©coupĂ©s :

  • …en plusieurs composants (components)
  • …chaque composants est dĂ©coupĂ© en fonctionnalitĂ©s (features)
  • …chaque fonctionnalitĂ© est Ă©ventuellement dĂ©coupĂ©e en sous-fonctionnalitĂ©s (sub-features)

🟥Components : 11

đź”´Features : 104

🔺Sub-features : 17

Les components sont triĂ©s de bas en haut selon leur poids. C’est grâce Ă  ce tri qu’on identifie les projets de dĂ©veloppement prioritaires.

Mais quels sont ceux qu’il faut commencer Ă  traiter dès aujourd’hui ? Quels sont ceux qu’il faut remettre Ă  plus tard ?

Combien peut-on en traiter simultanément ? Et pendant combien de temps ?

Prendre trop d’items simultanĂ©ment pourrait s’avĂ©rer contre-productif. Et en prendre trop peu pourrait retarder la date de la prochaine version du produit…

Conclusion 🎵

Vision ⇒ Positionnement ⇒ Idées de parcours ⇒ Fonctionnalité minimale ⇒ Développement ⇒ Test ⇒ Pondération et tri des insights ⇒ [priorisation]

Ce parcours de product management quasi-scolaire établit un cadre méthodologique très saint : grâce à cette méthode, on acquiert chaque jour un peu plus de certitudes quant aux choix que nous faisons et pourquoi nous les faisons.
Dans cette partie, nous avons vu comment faire ressortir des idĂ©es d’amĂ©liorations sur le parcours clĂ©, suite aux retours des utilisateurs. 104 idĂ©es qu’il est impossible de traiter simultanĂ©ment. Il faut donc dĂ©sormais prioriser.

Dans le prochain opus, 3 – DĂ©finir les objectifs stratĂ©giques de Festview, nous verrons comment ce travail de recherche auprès des utilisateurs vient s’articuler avec l’avancement gĂ©nĂ©ral du projet. Comment l’Ă©quipe dĂ©finit un panels d’objectifs Ă  atteindre pour un temps donnĂ©. Car c’est grâce Ă  ces objectifs qu’elle pourra sĂ©lectionner un nombre correct d’items Ă  dĂ©livrer pour l’application de manière Ă  servir ces objectifs. On passera notamment par la mĂ©thodes des Objectives and Key Results – OKRs.

Outils

Comme promis, voici les outils utilisés dans cette phase de définition du parcours clé puis de recherche utilisateur.

  • Atelier story mapping : Miro, permet manipuler des post-its, Ă  distance s’il le faut. L’outil dispose mĂŞme de templates pour ce type de travaux
  • Booking des interviews : Calendly, permet de dĂ©clarer des disponibilitĂ©s dans un calendrier et de laisser son contact choisir le moment qu’il prĂ©fère parmi ces disponibilitĂ©s
  • Trame des interviews : Google Form. On ne le prĂ©sente plus. Pour les questionnaires quanti directement remplis par les utilisateurs, j’aurais utilisĂ© Typeform, bien plus classe
  • Visio avec les Ăźeta-testeurs : Whereby. Ancien appear.in, on ne peut pas faire plus simple : le site gĂ©nère un lien, les utilisateurs qui cliquent sur ce lien se retrouvent dans la mĂŞme pièce virtuelle en visio.
  • Report, pondĂ©ration et tri des insights : ProductBoard. C’est le seul outil de gestion des insights que j’ai utilisĂ© jusqu’Ă  prĂ©sent, je le trouve parfait. A l’exception de son prix, trop Ă©levĂ© après l’expiration du mois gratuit : 49$/mois/user. Sachant que pour un projet qui dĂ©marre, on n’utilise pas ce genre d’outils tous les jours après une phase de recherche. On peut cependant utiliser la version gratuite et exporter tout le contenu avant qu’elle n’expire.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez Ă  l’aide de votre compte WordPress.com. DĂ©connexion /  Changer )

Photo Google

Vous commentez Ă  l’aide de votre compte Google. DĂ©connexion /  Changer )

Image Twitter

Vous commentez Ă  l’aide de votre compte Twitter. DĂ©connexion /  Changer )

Photo Facebook

Vous commentez Ă  l’aide de votre compte Facebook. DĂ©connexion /  Changer )

Connexion Ă  %s