Grace au Lean UX Canvas, nous allons voir comment définir un MVP en 8 étapes.
Durant la formation PSU, on nous a présenté le Lean UX Canvas afin de faire le pont entre les techniques UX design et le développement agile (plus particulièrement avec scrum) de manière « lean ».
Le constat initial est simple, le développement d’un produit est un processus complexe, les clients/utilisateurs changent régulièrement d’avis et, même en scrum, les organisations exigent encore de la divination de la part de leurs équipes afin de produire des roadmaps à moyen/long terme.
Les processus de développement scrum et d’UX design étant très proche, il est donc naturel de se nourrir des techniques UX afin d’optimiser les cycles de feedback utilisateur.
Lean UX propose d’optimiser l’effort requis pour avoir du feedback utilisateur, en se basant sur la « Truth curve », on voit qu’il existe des expériences peu chères permettant de valider les hypothèses de développement. En effet, tout développement réalisé sans feedback utilisateur n’est qu’hypothèse, aussi bien sur le fait que la solution répond bien au besoin ou encore que les clients soient prêts à payer pour la solution, et il est démesurément risqué d’avoir son premier retour utilisateur lors de la mise en production du produit.
1. Business problem
Durant ses expériences, Jeff, l’auteur du canvas, a trouvé qu’il était très intéressant pour les équipes de cadrer les développements autour d’un problème business à résoudre. En effet, cette formalisation permet à l’équipe de se focaliser dessus (plutôt que sur une fonctionnalité/solution), ce qui leur permet de faire preuve de plus de créativité et d’innovation, et qui les fait se concentrer sur ce qui compte (la résolution du problème, pas la livraison de la fonctionnalité). Il est recommandé d’identifier 3 parties dans la formulation du problème :
Le but du produit
Sur quel sujet le but n’est pas atteint
Une demande d’amélioration explicite sans solution
Exemple : "Le Nexus a pour but de fournir une plateforme d’échange entre professionnels de santé afin que des experts diagnostiquent des patients d’autres établissement.
Cependant, on observe que les administrateurs mettent beaucoup de temps à habiliter les utilisateurs, ce qui créé un délai pour l’introduction de nouveaux experts dans la plateforme (aussi bien sur une nouvelle activité que sur un nouveau marché), ce qui ensuite réduit l’attrait de la plateforme pour les nouveaux demandeurs.
Comment peut-on faire pour améliorer le process afin de minimiser le temps d’habilitation ?"
2. Business outcomes
Ici, le but est de se poser la question « comment on sait qu’on a résolu le problème business ? ». C’est une partie importante de la réflexion car elle permet de se mettre les bonnes mesures de succès. En effet, la livraison d’une fonctionnalité ne garantit en rien que le problème sera résolu, c’est nécessaire mais non suffisant.
Exemple : Temps pour habiliter un utilisateur < 2 min, appels au support concernant les habilitations – 70%
3. Users
Dans cette section, nous définissons qui sont les utilisateurs qui sont impactés par ce problème, il y est recommandé d’y mettre les personas.
Exemple : André, administrateur, 40 ans, doué en informatique. Il a beaucoup d’outil à gérer et donc peu de temps par outil.
4. User outcomes and benefits
Ici, nous devons caractériser quels changements dans le comportement des utilisateurs à la suite de la résolution du problème business. De manière général, nous ne sommes pas capables de mesurer ce changement directement, cette section est donc plutôt tournée vers le qualitatif. De plus, le client pouvant être différent de l’utilisateur, il peut être utile de le considérer ici.
Exemple : Réduction de la frustration de l’administrateur et des utilisateurs en attente d’habilitation. L’activité de l’établissement croît plus rapidement.
5. Solutions
La partie que tout le monde a envie de faire, trouver une solution permettant de résoudre le problème ! C’est une section de brainstorm, toutes les solutions, même les plus farfelues, sont à considérer.
Exemple : Ajout d’une vidéo de formation sur l’habilitation au début du workflow, création d’un chat bot d’aide à l’habilitation, une refonte de l’IHM et du workflow…
6. Hypotheses
Cette section permet de faire une synthèse des sections précédentes, elle assure que le tout est bien cohérent. Les hypothèses font le lien entre :
Le business outcome : la métrique qu’on a défini comme notre mesure de succès
L’utilisateur : le persona qu’on adresse
L’user outcome : le changement de comportement qu’on s’attend à ce que le persona adopte
La solution : la fonctionnalité qui a été défini pour répondre au problème
Exemple : Nous pensons que le temps d’habilitation va passer en dessous des 2 min si la frustration que procure l’outil à André est réduite par la refonte de l’IHM d’habilitation.
7. What is the most important thing we need to learn first?
Pour chaque hypothèse, il faut faire la liste des risques qui lui sont associés. De ces risques, il faut ensuite déterminer lequel est le plus risqué. Suivant le résultat, on détermine la prochaine étape :
Exemple : la nouvelle proposition de workflow permet à l’administrateur de faire des habilitations sans aide du support ni formation.
8. What is the least amount of work we need to do to learn the next most important thing?
Finalement, c’est dans cette section que nous allons définir notre MVP. Les livres « lean startup » et « lean UX » redéfinissent le MVP comme étant l’itération minimal permettant d’acquérir de la connaissance. En reprenant la « truth curve » du début du post, on peut distinguer 2 types d’expériences suivant où on se situe dans le cycle de développement du produit.
En effet, tant que le besoin et la solution n’est pas éprouvé par des utilisateurs, il n’est pas nécessaire de s’engager dans le développement.
Les techniques proposées sont les suivantes :
Conversations : des interviews avec les utilisateurs ayant un profil correspondant au persona défini dans la section 3
Landing page (non présent sur le schéma) : création d’une page d’accueil avec une description du produit et de sa vision afin de voir la potentielle traction qu’il aura. C’est le modèle Kickstarter (on peut aussi, par exemple, demander l’adresse mail des personnes intéressés)
Feature fake (non présent sur le schéma) : création d’un bouton proposant la fonctionnalité mais ne réalisant pas, un message d’information communiquant à l’utilisateur que c’est une fonctionnalité arrivant prochainement (à utiliser avec parcimonie, car cela peut engendrer de la frustration de la part des utilisateurs)
Paper test : un prototype papier permettant à des utilisateurs de simuler les interactions qu’ils auront avec la solution (exemple : https://www.youtube.com/watch?v=isKvctKuWFk)
Prototype : ici, on est dans une simulation d’interaction avec des pages statiques, mais celles-ci ressemblent au design final.
Wizard of Oz : l’utilisateur est cette fois fasse au prototype, cependant celui-ci renvoie des données dynamique, mais celles-ci sont remplies par un humain « behind the scene » (exemple https://www.businessinsider.com/the-inside-story-of-how-amazon-created-echo-2016-4?IR=T )
Exemple : Réaliser un prototype papier du nouveau workflow d’habilitation et le faire tester à des administrateurs afin de le valider.
En conclusion, grâce à ce canvas, on a pu aborder les concepts permettant de se poser les bonnes questions afin d’optimiser la définition de son MVP !
