[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 :
- 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
- 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
- Un atelier de 2h nous a permis de rédiger une plateforme de marque, contenant la vision, et de la publier sur le site
- 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 :
- 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
- Listing des grandes fonctionnalité et des sous-fonctionnalités du parcours
- 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.
Micro-scope 