Discovery Discipline - La méthode radicale pour exceller en discovery

Référence : Discovery Discipline - T.Charvillat R.Guyot

Le produit toboggan

Les produits les plus mémorables sont les produits dont on ne se souvient pas l’avoir utilisé, mais de l’expérience qu’elle nous a permis de vivre. Dans un produit s’adressant au grand public, mettant en relation les gens, ceux-ci se rappellerons de leur vécu avec d’autres personnes, et pas de la façon dont ils ont été mis en relation.

Dans l’image du toboggan, on ne se rappelle pas la forme, ou les couleurs du toboggan, mais du plaisir à descendre la pente. Tout les produits visent ce saint graal, alors qu’on part d’un besoin, et qu’une foule de solutions se présentent à nous.

Remarque : dans le cas d’un produit “B2B”, nos utilisateurs peuvent également vivre une expérience similaire, même si ça ne se présente pas de la même façon. L’utilisation du produit peut rester transparente, et l’objectif de l’équipe sera de permettre aux utilisateurs de se concentrer sur leur objectif, sans perdre de temps sur notre produit.

Atteindre un tel objectif nécessite une méthodologie permettant d’isoler “la” solution remplissant les attentes du client, tout en offrant la meilleure expérience, transparente, du produit.

Double Diamant

La solution la plus en vogue, en matière d’exploration produit, consiste à la diviser en deux grandes phases : l’exploration du problème, puis l’exploration de la solution. L’une comme l’autre consistent ensuite à explorer tout l’espace, puis à converger. Pour le problème, ce sera vers une expression tranchée du problème à traiter. Pour la solution, il s’agit d’éliminer tout le bruit pour se concentrer sur une seule solution.

Bien souvent, ces deux étapes sont court-circuitées, par manque de temps, par manque d’expérience, parce que la hiérarchie veut une solution précise, parce que le client vient avec une solution, et nous n’avons pas réussit à identifier son problème, … ou un mélange de tout ça.

Le principe est alors de fournir un cadre au processus d’exploration. Comme un fleuve à besoin de rives pour ne pas devenir marécage, le produit à besoin d’une méthode claire pour guider la créativité, et l’orienter vers la création de valeur.

FOCUSED

Il s’agit de 7 étapes reprenant à chaque fois un modèle similaire :

• une liste d’activités fournissant à la fois le cadre et la matière pour la créativité (autant le choix des activités que l’étape en elle-même fait la part belle à la créativité), puis
• un livrable court et précis, forçant la convergence (un cadrage au travers d’un livrable strict dans son format pour ramener de l’espace créatif à la discipline) et fournissant un point de départ à la prochaine étape.

L’objectif affichée est précisément de concentrer les efforts à chaque étape, pour avancer jusqu’à la suivante, et ainsi de suite jusqu’à la fabrication du produit. Et parce que les deux étapes du double diamant étaient trop flou, ce modèle propose 7 étapes :

• Frame : cadrer le produit sur la base de la stratégie, des métriques et de l’historique des produits, etc.;
• Observe : identifier le principal cas d’usage sur la base de retours concrets (clients, support, mise en situation,…);
• Claim : imaginer le positionnement narratif (en imaginant par exemple un communiqué de presse, donc imaginer la façon dont sera communiqué le produit);
• Unfold : Sélectionner les étapes clés de l’expérience utilisateur (cas d’usage parcours utilisateur, poser le context, le fonctionnement et les résultats attendus, …);
• Steal : s’inspirer des autres (analyser et décortiquer le fonctionnement chez les autres);
• Execute : élaborer une base d’évaluation de la solution (prototype, MVP, …)
• Decide : qualifier le produit en testant le modèle mis en place à l’étape précédente.

Remarque : l’idée dans cette discipline d’exploration est d’impliquer le point de vue utilisateur à chaque étape, et pas seulement là où c’est marqué “utilisateur”. Dans la logique Continuous Discovery, il est également question d’impliquer des utilisateurs tout le long de l’exploration, par exemple à l’occasion d’échanges hebdomadaires … y compris une fois en phase de développement.

Si leur structure globale est similaire - activités, puis livrable - chaque étape implique une expérience spécifique, en fonction de la nature de son livrable, et donc de l’objectif qu’elle doit permettre d’atteindre.

F.O.C.U.S.E.D

Frame

Cadrer : définir les grandes lignes fixant les orientations d’un projet ou d’une politique.

Il s’agit ici de s’accorder sur un objectif clair et précis, et de laisser d’emblée de côté tout ce qui pourrait nous en détourner. On défini donc le fameux cadre de l’opportunité que nous allons adresser. Ce cadre doit permettre de prendre les bonnes décisions aux prochaines étapes d’exploration de notre opportunité. Il doit donc être assez précis pour éviter toute ambiguïté par la suite.

Le premier élément du cadre est le critère de succès que l’on souhaite remplir. Il repose sur trois éléments.

• L’indicateur, définissant la cible avec précision.
• La valeur ciblée, ou l’ambition, définissant la hauteur de notre objectif.
• La valeur actuelle, représentant notre point de départ.

Nous devons ensuite définir quel risque nous sommes prêt à prendre. Le risque se défini de la même façon que le critère de succès, c’est-à-dire par un indicateur, sa valeur cible, et sa valeur actuelle.

On défini ensuite un cadre temporelle, c’est-à-dire l’ordre de grandeur, ou le temps que l’on est prêt à investir pour explorer notre opportunité. Ce sera peut-être un nombre de jours, de semaines ou de mois.

Les trois dimensions - critères de succès, risque acceptable et cadre temporelle - doivent être cohérents, pour avoir un objectif pertinent à notre exploration de l’opportunité.

Les activités lors de cette étape permettront de contextualiser nos objectifs et notre projet.

• Faire le lien avec la vision : “comment” atteindre la vision permet de trouver la mission, “comment” remplir la mission permet de trouver la stratégie, “comment” adresser la stratégie permet de définir nos objectifs, et le projet est le “comment” pour nos objectifs; remonter dans le sens inverse doit être réalisable en retrouvant le “pourquoi” à chaque fois.
• On peut ensuite partir d’un objectif ambitieux, accessible dans le monde idéal, et chercher à trouver qu’est-ce qui pourrait nous en empêcher.
• Enfin, on va chercher dans les donnés disponible et notre historique quels sont les possibilités déjà explorées, le vécu de notre produit. Le but est d’en apprendre le plus possible et éviter les écueils déjà rencontrés.

Observe

Observer : considérer avec attention, par une approche scientifique et rigoureuse.

Il s’agit ici d’identifier le premier cas d’usage que nous souhaitons adresser, pour lui donner la meilleure réponse possible, et conserver les cas secondaires pour plus tard (les prochaines itérations de notre produit). En effet, vouloir adresser trop de besoins d’un coup amène rapidement à concevoir un produit trop complexe, et finalement inutilisable.

Il faut donc se rapprocher des utilisateurs, les observer, pour comprendre quel est ce premier cas d’usage suceptible de leur apporter le plus de valeur.

Le cas d’usage se formalise à la façon d’un récit utilisateur. Ici, on reprend :

• “je suis”, le profil de l’utilisateur type que l’on vise;
• “lorsque je”, l’action qu’il souhaite réaliser;
• “ce qui compte le plus pour moi”, pour quel besoin;
• “cependant, il s’avère que”, quels sont les problèmes qu’il rencontre; et
• “je dois donc”, comment il les contournes, aujourd’hui.

Problèmes et contournements confirment que nous avons bel et bien une opportunité pour améliorer l’expérience de notre utilisateur. La valeur pourra ici se rapporter au bénéfice perçu par rapport au coût du changement.

Remarque : bénéfice perçu et coût du changement sont d’autant plus difficiles à estimer que ce sont des notions abstraites et subjectives. On peut toutefois se ramener à des données mesurables, comme le nombre d’actions à réaliser avant/après, la différence de performance, le nombre de changements sur l’interface utilisateur,…

À cette étape, les activités doivent nous permettre d’identifier et qualifier l’expérience de l’utilisateur. Ce peut être en se mettant soi-même dans sa peau, en échangeant avec lui, par des questionnaires, etc. L’important est de bien maîtriser son sujet (grâce aux informations du cadre), d’identifier les questions pertinentes pour cerner le ou les problèmes, et de savoir creuser au-delà des premières réponses pour identifier le but de l’utilisateur.

Dans l’idéal, on cherchera à partir des thèmes relatifs à notre opportunité, et d’utiliser les leviers de la communication assertive, comme les questions ouvertes, porter de l’intérêt aux frustrations et sources de satisfaction, explorer des expériences concrètes, etc.

Lorsqu’on a l’opportunité de prolonger l’expérience avec l’utilisateur, il est important de capturer en détail son expérience du produit, car c’est là que se cachent les pistes d’amélioration. Le ressenti dans ces moments là sera représentatif de l’expérience utilisateur (Remarque : cette note est pertinente pour une interface web, une application, ou une expérience “physique” avec le produit, comme pour une console de jeu, ou un téléphone, ou pour des interactions avec des personnes, etc. Dans le cas d’une API, c’est un peu moins évident, à moins d’identifier des scénarii d’utilisation de l’API ou d’explorer la façon dont sont utilisés les outils basés sur notre API).

Claim

Déclarer : faire connaître ses intentions d’une façon claire et manifeste.

Après les deux phases précédentes, on commence à voir se dessiner une idée de solution. Avant d’aller plus loin dans sa conception, nous allons réfléchir à la façon dont nous allons la promouvoir. Aborder l’aspect marketing aussi tôt nous pousse à réfléchir aux engagements que nous allons prendre sur notre produit, et ainsi guider nos décisions dans la suite de la conception.

L’objectif de cet étape est d’arriver à exprimer la valeur que l’on souhaite apporter aux utilisateurs en une phrase courte et percutante : l’équivalent d’un tweet. Cette contrainte nous pousse d’ailleurs à faire des choix sur la cible que nous souhaitons atteindre… On peut n’exprimer qu’une valeur bien précise, en une dizaine de mots, surtout si on se contraint à trouver les mots qui vont directement inspirer l’utilisateur. On restreint donc de facto la taille de cette cible.

Remarque : un récit utilisateur correctement écrit devrait atteindre un objectif identique. Il décrira un cas d’usage précis, correspondant à un besoin précis, et donc à une cible précise. Donc il faut une définition précise de notre utilisateur (eg. persona). Autre point : on part clairement d’un secteur du marché aussi restreint que possible, avec une cible précise.

Pour un produit existant, on va renforcer sa proposition de valeur. Pour un nouveau produit, on devra s’intégrer dans la proposition de valeur des autres produits, et donc rester en accord avec les valeurs et la vision de l’entreprise. Il est également bon de consulter le marché pour voir comment les autres acteurs ont vendu leur solution sur les opportunités similaires. Enfin, l’équipe produit va pouvoir réfléchir à des idées originales.

Afin de consolider et faire le tri dans toutes les idées, nous pourrons commencer par rédiger un communiqué de presse. Sa structure est généralement la suivante :

• un titre rappelant le nom de l’entreprise, le segment de marché visé, le problème et la proposition de valeur,
• une accroche décrivant le problème et la solution,
• un développement donnant la date de livraison, la description du problème et de la solution et son fonctionnement,
• des citations d’utilisateur, et
• une FAQ.

Une fois qu’on a construit un communiqué de presse satisfaisant, on peut le soumettre à revu, idéalement de clients. Les commentaires permettront alors de retrouver exactement ce que les utilisateurs attendent de notre solution. Autrement dit, ce que nous allons mettre dans notre livrable (le tweet).

Remarque : citations utilisateurs et FAQ pourraient être constitués après avoir eu des retours clients? On peut imaginer quelques allers-retours pour affiner notre communication.

Au cours de cette étape, l’un des écueils est de conserver du jargon interne à l’entreprise, alors qu’on imagine une communication destinée aux clients et utilisateurs.

Unfold

Se dérouler : suite d’événements ou de pensées prenant place dans le temps.

L’idée est de réfléchir à la façon de communiquer aux utilisateurs le fonctionnement et l’utilisation de notre solution. Il s’agit donc d’une part de dérouler le parcours dans le produit, mais également “autour” du produit, c’est-a-dire d’intégrer les canaux de communication par lesquelles nous pourrons atteindre l’utilisateur. À cette étape, deux choses importantes à garder à l’esprit : l’utilisateur aura moins de temps qu’escompté à nous accorder, et aussi plus d’exigences qu’escompté.

En déroulant ce parcours, nous identifierons des points de contact par lesquels notre communication aura lieu. Il faudra alors se limiter aux 5 les plus importants pour se concentrer dessus. Une fois identifiés, il s’agira d’en donner un aperçu “grosses mailles”, sans rentrer dans les détails. Nous pourrons alors voir si nous communiquerons notre message clé par la répétition, ou en le déroulant telle une narration.

Pour construire notre livrable, il s’agira de :

• parcourir notre principal cas d’usage pour se représenter, approximativement, le contenu de chaque étape;
• inventorier les canaux de communication à notre disposition pour en ressortir les plus important;
• s’intéresser à ce qu’il se passe “avant” et “après” l’expérience de notre solution, en remontant à chaque fois le plus loin possible, pour explorer le contexte d’utilisation et s’y intégrer au mieux;
• rechercher les moments forts de l’expérience utilisateur, typiquement en repartant de la cartographie de l’expérience utilisateur, car ce seront des points de contact clés avec lui.

Remarque : il en ressort que les moments clés seront essentiellement ceux du début et de fin d’expérience, et ceux correspondant aux moments forts à l’utilisation de l’application. À cela, on peut ajouter le moyen par lequel on va introduire notre solution à l’utilisateur, c’est-à-dire le principal canal de communication, et les interactions avec le support (le cas échéant).

Il est important de rester concentré sur l’expérience utilisateur. Les enjeux techniques viendront après (surtout que les points forts de l’expérience utilisateur ne coïncident pas forcément avec les étapes dont les aspects techniques sont complexes).

Steal

Voler : s’emparer de quelque chose pour s’en faire sien.

Explorer les solutions proposées permet de retrouver les éléments, ces petits détails, qui les rendent agréables à utiliser. Il ne s’agit pas forcément de notre concurrence directe, mais de tout produit susceptible de partager des éléments d’expérience utilisateur (applications mobiles, sites web, façon d’organiser son API, …). L’idée ici est d’optimiser notre propre solution pour s’intégrer au mieux aux habitudes de nos utilisateurs pour réduire les frictions à l’usage.

On va ensuite chercher à identifier les cinq plus belles pépites pour les appliquer en priorité à nos principaux points de contact de l’expérience utilisateur (mais pas que : certaines pépites pourraient s’appliquer à des étapes de l’expérience moins critiques, mais l’apport en vaut la chandelle). Ces cinq pépites pourrons ensuite être représentées à l’aide d’illustrations (e.g. capture d’écran, etc.) et d’une description de l’idée qu’elles représentent.

L’idéal est de commencer par découper notre solution selon les étapes du parcours utilisateur, les éléments constituant l’interface, etc. On va ensuite plus ou moins se focaliser sur telle ou telle partie particulièrement critique. Cela va nous donner un cadre pour nos recherches.

On va ensuite commencer nos investigations par les ténors, tels que Google, Apple, etc., pour ensuite élargir notre scope, et étudier à chaque fois leurs produits phares. Le but sera d’en extraire les meilleurs morceaux en reproduisant à chaque fois la même démarche de découpe sur leurs solutions. On peut techniquement aller chercher notre solution n’importe où, y compris sur des sites où des designers partagent leurs idées, car l’essentiel est qu’ils ont adressé le même petite problème spécifique pour lequel on cherche une solution.

L’investigation peut amener un flot considérable d’idées inédites, de nouvelles pistes de réflexion, etc. L’important est de rester sur notre principal cas d’utilisation, et sur ses étapes clés : ce sont eux qui fournissent le cadre. Après, il peut être bon de garder les autres découvertes sous le coude, et constituer une banque de bonnes idées à exploiter sur d’autres explorations

Execute

Exécuter : accomplir et mener à son terme un projet ou une décision, selon un plan.

Au point où nous en sommes, nous avons suffisamment d’éléments pour concrétiser notre solution. Il n’est pas encore question de se confronter à toutes les problématiques d’architecture technique, de détails d’implémentation, etc. Mais de se concentrer sur la solidité, d’un point de vue fonctionnel (utilisation) de notre solution.

Nous allons donc formaliser le parcours clé, construire un prototype permettant de le parcourir, et élaborer trois hypothèses, de sorte à pouvoir valider notre prototype, et donc notre solution, si elles sont confirmées.

Cette étape va consister en l’exploration d’idées pour la conception, et la sélection des idées les plus prometteuse, en procédant de façon itérative, à chaque fois sur la base des idées de la veille. Nous allons également alterner idées ambitieuses et idées prudentes, et ainsi progresser au travers du parcours clé. Dans ce processus, le concepteur va travailler avec le concours d’un contributeur, tantôt un développeur apportant des contraintes techniques (mais aussi des idées de contournement, tantôt un utilisateur capable d’apporter des critiques constructives, etc.

Il faut biensûr régulièrement faire le ménage dans les idées pour écarter le bruit. Pour celà, on peut employer la méthode “COEUR” : Cacher, Ordonner, Eliminer, Uniformiser, Réduire. On peut également utiliser différentes méthodes d’échanges utilisateurs pour collecter des avis et ainsi aider à éliminer les idées les moins pertinentes.

Enfin, il s’agit de concevoir le prototype que nous avons défini. Il doit reprendre les étapes du parcours clé et le contenu envisagé pour chacune de ces étapes. On doit également penser à du contenu supplémentaire pouvant aider à valider la solution, comme des animations ou illustrations de la solution… Sans oublier nos hypothèses.

Il est important de produire un prototype suffisamment complet pour couvrir les cas d’usage réels de notre solution, sans quoi nous risquons de manquer des éléments clés de décision… À l’évaluation du prototype, il faut éviter d’imposer trop de contrainte à l’utilisateur, et plutôt jouer sur une situation qui pourrait l’intéresser.

Decide

Décider : choisir par l’exercice de son jugement.

C’est l’ultime étape de convergence. Sur la base des bonnes questions, elle consiste à soumettre notre prototype aux utilisateurs pour obtenir les réponses permettant de valider la solution choisie. Ces réponses peuvent également nous permettre d’identifier certains problèmes de notre solution. Mais comme il s’agit d’un échantillon d’utilisateurs, ces problèmes ne seront pas forcément représentatifs des principales améliorations à apporter à notre solution…

Cette étape repose sur la validation des hypothèses formulées à l’étape précédente. C’est l’équipe, sur la base des retours de test, qui va se concerter pour valider les hypothèses. Et pour chaque hypothèse où subsistent des doutes, elle doit se concerter pour décider si la solution passe en phase de livraison tel que, ou si les hypothèses remises en question méritent de repasser par une phase d’exploration.

Certains cas de doute peuvent également amener l’équipe a produire des versions alternatives du parcours clé, afin de s’appuyer sur des techniques comme l’A/B test, pour éprouver l’hypothèse ou en selectionner une alternative.

Quoi qu’il en soit, il ne faut pas être rebuté par un doute sur une hypothèse, car cela ne voudra pas forcément dire que la solution elle-même est mauvaise.

Étant donné que cette étape repose sur des tests utilisateurs, l’essentiel du travail pour en tirer les bénéfices repose sur les échanges objectifs et pertinents avec les testeurs, leurs observations durant les phases de test, ou encore la collecte de commentaires. La consolidation de tout ces éléments, par hypothèse, permettront enfin de prendre une décision informée sur chacune d’entre elles.

À titre d’exemple de question pertinente, on peut demander aux testeurs de donner leur compréhension de son utilisation, des avantages et inconvénients qu’ils y trouve, etc.

Le principal risque de cet étape vient de la façon dont on perçoit les retours négatifs. Ceux-ci ne sont pas rédhibitoire, et il faut savoir en extraire l’élément constructif pour les besoins de notre prise de décision.

Quelques recommandations d’ordre général

• Utiliser un vocabulaire commun permet de s’assurer que tout le monde est aligné.
• Chaque étape à son livrable, et chaque livrable à son responsable… Et la validation de l’étape repose sur ce responsable, pas sur un consensus.
• Chaque livrable doit être parfaitement documenté, car ils suivront le produit dans ses développements futurs, et ils serviront de support de communication pour les choix qui ont été fait.
• Le temps passé et les ressources investies sur chaque étape dépendent des moyens dont on dispose. On peut expédier chaque étape en prenant une dizaine de minutes pour chacunes, puis en repassant un peu plus de temps pour les moins satisfaisantes; ou bien on peut mobiliser une équipe dédiée durant plusieurs mois… Ou n’importe quelle situation intermédiaire.