Date de création : 2025-11-27 19:27:31+01:00 Dernière modification : 2025-12-02 18:38:36+01:00
Historique: voir le dépôt.

User Story Mapping — Jeff Patton

De la difficulté de s’assurer que tout le monde ait compris la même chose

Partager la compréhension, c’est comprendre ce que l’autre s’imagine et pourquoi il se l’imagine. Cela nécessite non seulement de coucher ses idées sur le papier, mais aussi — et surtout — les partager : montrer, décrire, échanger (questions/réponses), reformuler, …

Récit Utilisateur

Le but du récit utilisateur (« User Story ») est précisément de partager la même compréhension. En agile, la notion de récit renvoi à la façon dont le document doit être utilisé, pas ce qu’on va y écrire. Il doit permettre de raconter le récit de l’utilisateur (Remarque : ou encore pour raconter comment et pourquoi nous sommes arrivés à de telles conclusions).

Les documents doivent permettre de retrouver comment nous y sommes arrivés.

Nous commençons par observer la situation actuelle.
Nous observons les problèmes, difficultés, etc. que notre public cible rencontre (Opportunités potentielles).
Il nous viens des idées pour apporter de la valeur (initiatives : nouveautés ou évolutions sur l’existant).
Nous documentons notre idée pour la partager.
Ces documents donnent les informations pour réaliser l’innovation, qui sera livrée « plus tard » (de facto après la « situation actuelle »).
Nous espérons que tout ou partie (en générale une partie) de notre public sera satisfait par l’usage de notre solution.

Mesurer et exploiter les résultats

Mesurer la valeur qu’apporte notre solution, c’est mesurer à quel point les utilisateurs l’on adoptée, et dans qu’elle mesure ils sont satisfait.

Mesurer l’impact, c’est mesurer le bénéfice que l’entreprise tire de la satisfaction des utilisateurs. Ces bénéfices permettront d’investir dans les prochaines opportunités qui se présenteront à nous pour améliorer l’expérience des utilisateurs. La stratégie de l’entreprise va donc indiquer quels clients prioriser.

Pour quel utilisateur.
Qu’est-ce qu’il fait aujourd’hui.
Qu’est-ce qui aura changé dans le futur.

Finalement, l’objectif sera de minimiser le nombre de fonctionnalités, afin d’en maximiser la valeur ainsi que les bénéfices qu’elles apportent à l’entreprise.

La principale recommandation est de ne pas se laisser avoir par l’impératif du cahier des charges. Il exprime un prérequis et nous force à arrêter de s’intéresser à l’utilisateur et son problème, alors que l’important est précisément de résoudre son besoin.

Remarque :

Une autre façon d’interpréter l’idée et de minimiser la quantité, est de se dire que nous voulons minimiser le délai entre l’identification de l’opportunité et la livraisons de la solution de bonne qualité. Dans ce cas là, une piste de réflexion est de travailler sur un produit « minimum viable », permettant à la fois d’apporter un maximum de valeur avec un minimum d’investissement, et de récolter au plus tôt des retours permettant de confirmer l’apport de valeur à l’utilisateur et l’impact client.
Associer valeur <-> utilisateur et impact <-> client : l’idée sera de confirmer au plus tôt la valeur auprès de l’utilisateur, pour maximiser l’impact client.
Sans passer spécifiquement par le cahier des charges (particulièrement contraignant), il est quand même important d’arrêter l’exploration au moment opportun, pour faire le point, et passer à la réalisation.

Se raccrocher à la vision d’ensemble

De l’épopée au récit

Le récit complet décrit la vision d’ensemble. Nous irons ensuite parcourir ce récit pour le découper en petits récits qui pourrons être traités séparéments.

Une solution est de raconter le récit et de poser sur des cartes (post-it, etc.) tous les éléments clés, pour pouvoir y revenir par la suite : les cartes servent à la fois à « coucher les idées par écrit », s’assurer qu’elles ne se perdront pas, et à s’aligner sur la compréhension du sujet.

Nous n’écrieront pas seulement le récit, mais aussi les idées qu’elles nous inspirent, également pour être en mesure de les retrouver à posteriori.

Quelques questions à se poser pour bien identifier la valeur d’une idée :

Quel bénéfice pour le client ?
Quel bénéfice pour soi (son entreprise, son équipe) ?
Quel problème cela résoud pour l’utilisateur ?

Les cartes pourront ensuite être ordonnées en fonction de l’importance qu’elles revêtent.

Utilisateurs et parcours utilisateur

Nous portons ensuite les types d’utilisateur sur des cartes, puis nous listons pour chacun le type d’activités qu’ils réaliseront avec notre produit. Les utilisateurs et activités sont également triés selon leur importance. Idem pour les clients. Sur la carte de l’utilisateur ou du client, nous reportons ce qu’il veut faire, et pourquoi, en quelques mots.

À la fin de l’exercice, nous avons des récits, des idées, des clients, des utilisateurs, et des activités. Il faudra alors se concentrer sur un utilisateur, et recentrer tout le fruit des réflexions sur cet utilisateur, pour raconter son histoire.

Pour notre utilisateur donné, nous allons nous positionner dans le futur désiré, là où notre produit satisfait à ses attentes, et nous allons construire son parcours dans l’application, avec ses tâches, selon l’ordre dans lequel il les réalisera.

L’exercice mené jusque-là a permis à la fois de se concentrer sur un parcours, puis un récit donné, tout en partant de la vue d’ensemble de l’opportunité. Mais cet exercice a également permis d’identifier les faiblesses et manques, autant de la vision d’ensemble que du parcours prévu dans l’application.

Il nous permet également d’identifier les interactions avec d’autres utilisateurs potentiels, dont il faudra tôt ou tard dresser le parcours.

Chaque récit pourra être détaillé en fonction des idées qui nous viennent, mais ils devront être détaillés une fois le parcours global établi, en fonction des priorités.

Pour chaque étape du parcours, nous pourrons ensuite détailler

en quoi consiste l’action,
quels sont les alternatives qui se présentent à l’utilisateur,
qu’est-ce que nous pouvons apporter, et
comment s’en sortir en cas de problème.

Exemples de mise en place

Lister les épopées : commencer par poser le parcours global, sur l’ensemble du produit, de gauche à droite, en haut.
Parcours détaillés : sous chaque étape de notre parcours global lister les récits de l’épopée correspondante.
Associer les utilisateurs : pour chaque récit, indiquer l’utilisateur concerné, son besoin et ses actions, les étapes clés du récit et les idées (plus on ajoute d’éléments à ce récit, plus il est important).

Une approche alternative consiste à associer un profil d’utilisateur à une étape du parcours global.

Remarque :

j’ai déjà eu l’occasion d’observer que le parcours global pour une entreprise reprends certaines étapes du « funnel d’acquisition » (« AARRR » en anglais) : Activation, Acquisition, Rétention, Promotion, Revenus (Conversion).
Idée : on parle d’épopée pour rassembler plusieurs récits. Mais lorsqu’il y a plusieurs parcours différents au sein d’une même épopée, on pourrait parler d’intrigues : Une intrigue reprendrait un ensemble de récits issus de l’épopée dans un parcours cohérent, pour un profil donné d’utilisateur (ce pourrait être un moyen de structurer son produit lorsqu’il devient plus complexe).
Pour avoir un vocabulaire propre, on peut parler d’opportunité pour désigner les besoins, difficultés, voir les manques du marché qu’on peut adresser. On peut ensuite affiner ces opportunités, si elles sont très haut niveau (e.g. un marché entier), puis sur une opportunité donnée, on construit la cartographie des récits utilisateur. L’ensemble des récits sera l’épopée, et les parcours spécifiques les intrigues. À ce point de l’exercice, des idées auront pu émerger, mais elles auront été conservées sur le côté, et aucune solution n’a été posée.

Plusieurs équipes

Dans une entreprise portant plusieurs produits, chaque équipe a tendance à mener sa propre cartographie sur son propre produit. Cependant, lorsqu’elles reprennent l’exercice en commun, un cran au dessus, elles découvrent des trous et des recouvrements, sur le parcours de l’utilisateur. Ils s’identifient et s’adressent en cherchant à voir ce qu’il se passerait si tel ou tel service ou fonctionnalité ne se comporte pas comme attendu, ou si un utilisateur différent (avec un but différent) arrive sur le produit.

Construire moins

Élaborer un parcours utilisateur implique de savoir s’arrêter. Une fois le parcours global établi, il faut s’intéresser aux étapes les plus importantes pour se concentrer dessus, et ainsi éviter de trop s’investir sur des éléments secondaires, qui supporteraient peu de valeur au produit.

Premiers lots

Pour savoir où s’arrêter, il faut se concentrer sur la valeur apportée et l’impact sur les parties prenantes, plutôt que sur la quantité de services et fonctionnalités : le but est de fournir une réponse satisfaisante au besoin.

Sur la base de la cartographie de notre produit, nous pouvons remonter la priorité des besoins les plus forts (les actions les plus importantes/bloquantes pour que l’utilisateur atteigne son objectif) et des fonctionnalités les plus visibles/marquantes du produits. Les actions pourrons ensuite être réparties en plusieurs lots, les plus importantes étant dans le premier lot : le Produit Minimum Viable (MVP).

Pour aider à se concentrer sur l’essentiel, une date limite à la livraison du lot est nécessaire.

Lorsque nous sommes capables de fixer une date pour plusieurs lots (e.g. les trois premiers), nous sommes capables de proposer une feuille de route des versions à livrer, avec les actions utilisateur qui seront adressées à chaque fois.

Derrière la valeur apportée se trouvent des comportements spécifiques affectant des utilisateurs engagés dans des activités spécifiques. Nous ne pourrons pas satisfaire tout le monde, il faut donc prioriser les utilisateurs ayant le plus fort impact et les besoins les plus importants.

Identifier exactement le nécessaire pour notre produit minimum nécessite d’exprimer de façon claire et concise (e.g. 2~3 phrases) ce que notre principal utilisateur veut. Cette simple démarche permet de cibler précisément ce qui est absolument nécessaire au produit, rien de plus.

Remarques :

Voir aussi l’exercice « si je n’ai que 10 minutes, qu’est-ce que je vais faire? Si je n’ai que 5 minutes…? » etc.
Beaucoup d’exemples montrent des tableaux de centaines de post-its représentant des heures — voir des journées entières — de travail, juste pour la préparation. Si ces équipes priorisent au fil de la progression de la cartographie, il est possible d’éviter une trop grosse perte de temps à aller trop loin dans trop de détails et progressivement recadrer la focale.
Idée : un système de vote sur les post-its permet d’identifier les priorités. Nous pouvons commencer par le profil d’utilisateur le plus important, ce qui permet d’éliminer les parcours des autres, puis reprendre le même exercice de vote sur le parcours global (besoins), le parcours détaillé, les actions, etc.
Ce qui serait quand même pertinent, ce serait d’identifier des profils adjacent, potentiellement intéressés par certaines actions, dans leur propre parcours (donc peut-être ne pas les éliminer trop vite), cela peut influencer l’importance d’une action donnée. À noter aussi que les actions doivent être converties en récit utilisateur « untel souhaite faire action afin d’atteindre besoin ».

Produit/Solution Minimum Viable

« Viable » implique qu’on vise le minimum par lequel le produit / la solution est viable, càd qu’il apporte la valeur attendue par l’utilisateur (ce que l’utilisateur attend avant toute chose du produit).

Lorsque nous livrons la première itération d’un produit ou d’une solution, nous sommes réduit à nous appuyer sur des hypothèses, faute de retours d’utilisateur.

Le minimum viable est aussi le minimum nécessaire pour (in)valider nos hypothèses.

Remarque : rien ne nous empêche de mener nos premières enquêtes, nos premiers prototypes, en amont de la recherche des premiers besoins à adresser, pour informer nos choix.

PO selon Jeff Patton

Compréhension de l’idée

Il prend une idée (ou un ensemble) concernant un ou plusieurs utilisateurs et leurs besoins, et se l’approprie : l’idée découle alors sur une initiative. Pour cela, avec les cadres, le PO cherche à répondre à plusieurs questions afin de s’assurer que tout le monde partage la même compréhension de l’idée :

Quelle est l’idée ?
Qui est le client (personne physique ou morale qui va payer) ?
Qui est l’utilisateur ? Et quel usage auras t’il du produit / de la solution ?
Pourquoi en voudrait-il ? Quel problème doit-on résoudre ? Quel bénéfice pour le client ?
Pourquoi construire le produit ? Qu’est-ce que cela va nous apporter ?

Le PO va ensuite s’efforcer de valider ou invalider l’idée (à ce niveau, c’est une hypothèse : l’initiative va évoluer).

Rencontrer les clients et utilisateurs pour mieux les connaître, s’assurer que le problème existe (que ce soit un blocage ou qu’il existe des solutions, mais de contournement coûteuses), et qu’ils sont prêt à investir dans une solution qui résoudrait ce problème.
Constituer une base de clients « partenaires », motivés pour expérimenter le nouveau produit.

Une fois l’idée validée, il doit aider l’ensemble de l’équipe à s’approprier cette idée, pour la concrétiser.

Le PO embarque un petit groupe de personnes (UX / Product designer) avec lui dès la recherche sur les utilisateurs et clients (donc avant validation).
L’équipe cartographie les récits de l’initiative pour explorer toutes les pistes, et prioriser les parties du besoin initial qui devront être adressées dans le produit minimum viable, par lequel l’initiative pourra être validée concrètement.
Avant de se lancer dans cette première version du produit, passer par les étapes de maquette, prototype, etc. que nous soumettrons à l’utilisateur au plus tôt pour valider la valeur et l’usage de notre solution (Et c’est la première étape où nous commençons à parler de solution).

Le PO va chercher à éprouver sa première solution au plus tôt. Pour cela, il va soumettre ses maquettes et prototypes aux clients et utilisateurs partenaires du développement qu’il a réussi à identifier lors de ses enquêtes. Il cherchera par la même occasion à en faire ses primo-adoptants.

Remarque : * le PO ne maîtrise pas la source de l’idée, du coup. Au mieux, savoir d’où vient l’idée va l’aider à mieux la comprendre ou se l’approprier, mais c’est tout. L’initiative existe déjà quand elle arrive entre ses mains. Il va juste la compléter et la faire évoluer. * En tant que PM, nous pouvons émettre des idées, les formaliser à partir des échanges avec le client, une analyse du marché, des collectes de données, etc. Le PM identifie des opportunités et les planifie, pour ensuite les soumettre au PO pour la valider, la compléter, et la faire évoluer. * PM : responsable de l’initiative; PO référent de l’initiative. * Remarque dans la remarque : la distinction entre PM et PO n’est pas universellement admise. Beaucoup de mondent la considère comme artificielle.

Priorisation et Planification

Le Product Owner identifie les sujets à intégrer dans la prochaine release. Ces sujets sont ensuite planifiés pour les prochains sprints. Lorsque des sujets sont sélectionnés pour le prochain sprint, ceux-ci sont revus, affinés et re-découpés sur la base du bénéfice apporté à l’utilisateur. Le fruit du découpage — les sujets plus précis — sont alors priorisés pour que les développeurs sachent par quoi commencer (i.e. qu’est-ce qui apportera le plus de valeur).

Chaque nouvelle version du produit est ensuite livrée et mise à disposition des clients partenaires pour recueillir leurs retours, base sur laquelle le PO alimente et met à jour son tableau de sujets à traiter. Il pourra considérer que son produit à atteint le « minimum viable » lorsque ses partenaires l’utilisent régulièrement, mais surtout lorsqu’ils sont prêt à en faire la promotion. À ce moment là, le produit est prêt pour être officiellement commercialisé.

L’important est de livrer le plus tôt possible un produit fonctionnel, même si l’expérience utilisateur n’est pas encore au rendez-vous. Celle-ci va se construire sur la base des retours des utilisateurs, par une boucle d’apprentissage (les nouveaux sujets, et mises à jour de sujets, sur la feuille de route). Au cours de cet apprentissage, nous en apprendront progressivement plus sur le besoin du client, ce qui permettra de mettre à jour l’orientation de notre produit.

Remarques : * sur la base des retours des utilisateurs, il n’y aura pas de changement majeur (et encore moins disruptif) de la progression du produit. Au maximum, l’accumulation des retours vont agir comme un faisceau de preuves pointant un problème majeur à traiter. Les vrais changements majeurs susceptibles d’amener une rupture dans l’orientation du produit sont les retours d’analyse du marché (donc un cran plus haut) ; * lorsqu’on priorise pour un sprint, on ajuste la charge pour que tout les tickets soient traités dans le sprint ; du coup, certains tickets ne seront potentiellement jamais traités, car n’apportant pas assez de valeur ; mais cette situation n’est pas forcément rédhibitoire, justement parce qu’on s’est assuré que les tickets apportant le plus de valeur sont forcément traités dans le sprint.

Prochaines itérations

Le marché ciblé va orienter la façon dont on va prioriser les besoins : les clients et utilisateurs de ce marché, la valeur que nous souhaitons leur apporter.

Boucle d’apprentissage : cf. Lean. Chaque itération est possible parce qu’elle passe par une expérimentation sur le produit minimum viable. Le but de l’itération n’est plus de livrer le produit qui répond à toutes les attentes, mais d’apprendre quelles sont ces attentes et comment les satisfaire. L’itération peut donc se focaliser sur un besoin spécifique et sur sa compréhension. Ce peut également être un moyen pour isoler une partie du produit du reste (e.g. l’interface de la base de donnée), de sorte à pouvoir travailler — en collaboration avec le client — cette fameuse partie, sans impact sur le reste (ou alors pouvoir traiter lesdits impacts séparément).

Remarque : l’objectif du produit reste de se rapprocher au maximum de la meilleure réponse possible au besoin, mais les itérations en soit visent à apprendre comment réaliser cet objectif. Tel que tourné par l’auteur, l’apprentissage ne concerne pas forcément un besoin utilisateur … Du coup, ce pourrait également être une expérimentation technique (i.e. un « spike »).

Comment finir dans les temps

La cartographie ne va pas nécessairement se faire sur l’intégralité du produit (Rq: surtout si on démarre l’exercice pour un produit déjà bien avancé). Elle doit concerner en priorité la partie du produit qui concerne la discussion en cours.

Découper une fonctionnalité insécable

Un premier lot permettant de voir l’intégralité fonctionnant d’un bout à l’autre (e.g. uniquement le parcours de base, sans les cas d’erreur, uniquement l’affichage et les actions sans backend, les éléments essentiels qui soient les plus risqués, pour réduire le risque le plus tôt possible, etc.). La connaissance pour identifier les principaux risques viennent de l’équipe.
Tester le parcours et identifier les risques sur la suite de l’implémentation.
Étendre le fonctionnel à chaque itération, en tirant les leçons des difficultés rencontrées pour préparer la prochaine itération. Intégrer les contraintes du métier, tester la performance, mise à l’échelle, d’usage, etc. (Possibles à partir d’un parcours complet).
Terminer par les derniers ajustements, les derniers risques à éliminer, etc. C’est à partir de là que nous disposons de données concrètes pour obtenir des résultats issus de tests grandeur nature. C’est aussi à partir de là que nous pouvons améliorer/peaufiner l’expérience utilisateur.

L’équipe doit être impliquée dans le découpage et l’estimation des tâches et lots, de sorte à tirer profit de leur expertise, et s’assurer que la compréhension est partagée entre tous.

Estimation et alignement

La livraison n’intervient pas à chaque itération, mais lorsque le délai imparti pour l’élaboration de la fonctionnalité est atteint. Plus le découpage du besoin sera fin, plus l’estimation sera précise. Il est également nécessaire de gérer proprement son budget (temps disponible, personnes disponible, etc.) afin de suivre à chaque itération le rapport entre le degré de réalisation de la fonctionnalité et le budget restant disponible. Logiquement, il s’agira de traiter en priorité les éléments dont le risque est le plus élevé.

Le développement d’un produit ne se fait pas comme fabriquer un mur, mais comme peindre un tableau : nous partons d’une maquette de l’illustration, que nous affinerons par couche successives, jusqu’à obtenir le tableau final. Nous adoptons une démarche itérative (e.g. Scrum) pour faire évoluer le produit de façon incrémental (expérimentation/évolution).

NB : dans l’exemple, le PO livre une version experimentale du produit une fois toute les deux itérations. * La première sert à traiter les tâches identifiées comme les plus risquées. * Dans la seconde, le PO priorise ce qui permettra de rectifier les éventuels difficultés de la précédente itération.

Remarque : le délai accordé pour une fonctionnalité peut être en sprint, ou bien selon une date fixée à l’avance. Le choix dépend de l’organisation et/ou du contrat avec le client. Le mode de priorisation sert justement à s’assurer que ce qui apporte le plus de valeur soit forcément livré dans les temps.

Quelques clés pour élaborer son parcours

Pour la rédaction du parcours

Identifier chaque tâche indépendante (réalisée par l’utilisateur) constituant le parcours de l’utilisateur.

Une tâche = un verbe d’action + un objectif.
Conserver les tâches spécifiques que certains utilisateurs peuvent remonter.
Qualifier les tâches :
- une tâche de base est une tâche ne pouvant être interrompue (e.g. prendre une douche) ;
- certaines peuvent être raffinées en sous-tâches ;
- certaines tâches sont en réalité de plus haut niveau.

Respecter la narration : organiser les tâches dans l’ordre naturel de réalisation, et compléter les trous qui ressortent dans le parcours (les tâches manquantes).

Alimenter avec les parcours alternatifs : c’est-à-dire

les différentes façons d’arriver au même but,
qu’est-ce qui se passe en cas de problème,
le cas idéal (i.e. ce qu’on aimerait également faire, inenvisageable aujourd’hui),
etc.

Il est même possible de mettre plusieurs variantes du récit en parallèle (e.g. parcours type, idéal, en cas d’urgence,…).

Rassembler les tâches similaires, ou qui sont des alternatives les unes aux autres. On pourrait même construire le parcours comme un livre dont on est le héro (un ensemble de choix à chaque étape).

S’il y a débat dans l’ordre au niveau de certains détails, peut-être que ces derniers ne sont pas si important, et simplement suivre la majorité.

Identifier les activités, c’est-à-dire des ensembles de tâches visant un objectif commun. Ce peut être des tâches destinées à être traitées ensemble. Ces activités vont alors donner une vision plus haut niveau du narratif de notre parcours utilisateur. Les activités doivent être nommées telles qu’elles seraient nommées par les clients et utilisateurs.

Dans le cadre de notre parcours, penser au critère le plus important pour déterminer la valeur du résultat obtenu à la fin du parcours (Rq : l’équivalent du « comment se préparer en 10 minutes »), puis déterminer quelles tâches sont absolument nécessaires pour obtenir cette valeur à la fin du parcours. Ce n’est pas grave si une activité n’a aucune tâche absolument nécessaire, il s’agira du coup de réfléchir au minimum vital pour accomplir l’objectif de cette activité, malgré la contrainte imposée.

La cartographie peut être utilisée pour dresser un état des lieux à l’instant donné, et/ou pour l’état que nous souhaitons atteindre à terme. Pour l’état des lieux à l’instant donné, nous pouvons ajouter, pour chaque activité :

qu’est-ce qui ne convient pas, les frictions (Rq : ce qui bloque, ou qui est difficile) ;
qu’est-ce qui convient, qui plaît ; des questions sur le pourquoi, qu’est-ce qui se passe, etc. ;
des idées sur ce que les utilisateurs pourraient, ou voudraient faire, qu’est-ce qui permettrait d’éliminer les frictions.

Synthèse d’une cartographie du récit

Cadrage du problème : pour qui et pourquoi.
Vision d’ensemble : les grandes lignes du parcours, à ce jour.
Explorer : d’autres points de vues sur les difficultés que les utilisateurs peuvent rencontrer.
Découper en lot : qu’est-ce qui apporte le plus de valeur aux utilisateurs, le plus d’impact pour l’entreprise (via les clients).
Le produit minimum viable est une hypothèse … jusqu’à preuve du contraire : identifier le minimum pour expérimenter.
Stratégie de développement : après avoir un minimum viable, itérer sur les composants essentiels en priorisant ce qui aidera le plus à maîtriser les risques techniques.

Idée pour identifier les grandes itérations après expérimentation : « good enough / better / best ». Identifier l’essentiel, puis ce qui améliorerait l’expérience, et enfin ce qui rendrait l’expérience exceptionnelle (Rq : variante de priorisation).

Le parcours peut également être constitué pour un produit existant : on va dérouler les actions de l’utilisateur sur le produit, et pour chaque étape, identifier des remarques (idées, difficultés rencontrées, etc.). Les étapes avec le plus de remarques, et dont l’usage est le plus fréquent, sont les opportunités les plus importantes (avec le plus de valeur potentielle).

Pour améliorer l’expérience

Ron Jeffries, « Extreme Programming Installed » : les 3C.

Cartes avec la liste des attentes, l’idéal visé.
Conversation pour échanger sur le produit à construire, et se mettre d’accord sur une compréhension partagée.
Confirmation en se mettant d’accord sur le résultat. Typiquement sur la base d’un ensemble de critères d’acceptation.

Visualisation : maquettes, diagrammes, photos, etc.

Format des récits utilisateur comme point de départ aux conversations : « en tant que profil je veux action afin de valeur »

Remarque cas d’usage (associés au récit) : « Étant donné contexte je fais action et j’obtiens résultat ». Voir aussi le format Gherkin (Given/And / When/And ; Then/And).

S’imposer un modèle trop strict de parcours ou de récit bride les possibilités et oriente les échanges sur le récit utilisateur. Au mieux, il peut guider au lancement ; mais il vaut mieux l’abandonner rapidement, s’il devient trop contraignant.

Ne pas se limiter à un « utilisateur » générique : distinguer les profils, penser aux parties prenantes entourant l’utilisateur (le client, les partenaires, son entreprise, etc.).

Remarque : après la question du profil de l’utilisateur, c’est la raison pour laquelle il réalise ses actions qui est importante. C’est à partir de là que nous pouvons identifier de nouvelles façons d’arriver au même gain, et potentiellement de façon plus efficace.

Conserver une capture aussi précise que possible des échanges autour du parcours utilisateur et des récits, de sorte à être capable de s’y reporter en cas de doute, pour éviter d’avoir à rejouer tout ou partie des débats.

Au niveau d’une opportunité, on cherche le problème, les bénéfices de l’entreprise à le traiter, des pistes de réflexion sur la solution, mais aussi une estimation « à la louche » de la charge de travail.

Déterminer ce qu’on est prêt à investir dépend de la valeur qu’on espère apporter à l’utilisateur et/ou de l’impact pour l’entreprise, d’où l’importance de savoir mesurer valeur et impact : qu’est-ce qu’on doit mesurer, comment le mesurer, comment interpréter, … ?

Pour améliorer les récits utilisateurs

Au moment d’alimenter les récits utilisateurs, prendre en compte le point de vue des différents métiers intervenant sur notre produit permet de tirer les bénéfices de leur domaine d’expertise (technique, conception, organisation, connaissance du marché, des utilisateur, des enjeux de l’entreprise, etc.). Par contre, le récit utilisateur à proprement parler doit rester suffisamment clairs et concis pour rapidement retrouver ce dont il s’agit. Les détails seront bien mieux organisés dans des documents dédiés (Remarque : spec technique, analyse d’impact / de risque, cas de test, etc.).

La carte d’un récit utilisateur devrait se limiter à

un intitulé (quelques mots),
au récit à proprement parler (qui / quoi / pourquoi), accompagné
des repères de suivi (date de création / mise à jour, statut, priorité = gain / complexité, …) et
des références : des documents contenant les détails, et des récits directement liés à celui-ci.

Nous pouvons éventuellement ajouter les métriques permettant de mesurer la valeur apportée. Remarque : au niveau d’un récit spécifique, ce peut être compliqué ; ça dépend de la granularité visible et réalisable.

De la même façon que pour le parcours, garder un maximum d’informations issus des ateliers (i.e. les documents de travail) permet de s’y référer à postériori, au besoin.

Il faut bien garder à l’esprit que seul ceux qui ont travaillé sur le récit ont une comprehension complète du sujet. Tout les documents de travail et captures conservées sont efficaces à partager l’information, certes, mais cela reste à un niveau inférieur à celui atteint par les participants : les documents aident à se rappeler, pas à apprendre.

L’idéal est d’impliquer au plus tôt les personnes en charge de la conception et de l’implémentation de la solution, et se baser sur la communication à l’oral, pas seulement les documents, pour échanger tout au long du processus de développement. Les échanges devraient se prolonger jusqu’à l’inspection des résultats (développements réalisés et retours d’utilisateurs), en particulier dans le cadre d’une approche agile (les retours permettent de faire évoluer la solution dans le temps).

« Je ne perds jamais, soit je gagne, soit j’apprends » disait Nelson Mandela. Le but de l’itération elle-même est d’apprendre pour ensuite réussir. Donc même si la version livrée en bout d’itération n’est pas viable, l’essentiel est qu’elle permette d’apprendre.

Remarque : la démarche rejoint le PDCA de Lean. Pour chaque itération, on identifie quelque chose qui ne va pas et on pose une hypothèse de solution (plan), on applique le changement (do), on évalue (check) et on adapte (act) d’après ce qu’on a appris.

La réalisation du récit utilisateur nécessitera la réalisation d’un certain nombre de tâches techniques qu’il faudra lister pour être sûr de les avoir traitées. Les tâches ne devraient pas être identifiées tout de suite, mais a postériori : l’échange pour comprendre le besoin doit avoir lieu avant de travailler sur la solution.

Pour le découpage du récit

Si un récit s’avère trop complexe/coûteux à traiter, le premier réflexe devrait être de prendre du recul, repartir de la valeur que nous voulons apporter, et tenter une solution plus simple. Le second réflexe, lorsque nous sommes déjà sur la meilleure solution à notre portée, sera de redécouper le récit. Dans ce cas là, le but à viser est d’être en mesure de valider l’hypothèse la plus importante (ou critique, ou risquée, …) le plus tôt possible (puis la 2è, puis la 3è, …).

La dimension du récit dépend de notre interlocuteur : ils donnent différents niveaux de granularité.

Du point de vue commercial, un récit complet réalise l’impact voulu : vision haut niveau, grand format.
Du point de vue de l’utilisateur, c’est un récit qui répond complètement à son besoin : vision de l’utilisateur (ou ensemble de), plus spécifique.
Pour le développeur, c’est un récit réalisable et pouvant être testé en quelques jours : vision court terme, atomique.

Le terme d’épopée peut servir à distinguer le récit au niveau client ou utilisateur des récits manipulés au niveau de l’équipe qui va réaliser le produit. Les récits d’une épopée peuvent être rassemblés selon leur thème (un récit peut être dans plusieurs thèmes), par soucis de cohérence, pour définir le contenu d’une livraison, pour symboliser leurs dépendances, etc. Remarque : ne pas se laisser avoir par les termes, c’est la démarche qui compte.

L’allégorie d’Asteroids : plutôt que cartographier toutes les opportunités, se focaliser sur une à la fois. Sinon, on se retrouve très vite saturé, perdu dans les priorités. L’avantage de la vraie vie par rapport au jeu, c’est que nous pouvons rassembler les récits sous l’épopée ou l’initiative, et se recentrer sur l’initiative ou épopée en cours.

Les acteurs du récit

Le Responsable Produit (Product Owner ou Product Manager) ne peut pas assumer à lui tout seul la rédaction du récit utilisateur du fait de la complexité et de la variété des connaissances à mutualiser : métier du client, de l’utilisateur, expérience utilisateur, implications techniques, etc. La responsabilité ne peut pas non plus être partagée entre tout les acteurs, sinon nous n’avancerions pas. Le Responsable Produit devra donc assumer la décision finale, mais après s’être entouré des bonnes personnes et des bons avis pour que sa décision soit informée.

Le Responsable Produit va donc constituer une petite équipe dédiée à l’exploration (besoin et solutions) et la conception du produit.

La solution doit impacter la croissance de l’entreprise, donc des clients : une personne capable d’apporter la compréhension des intérêts de l’entreprise. Celle-ci, le Responsable Produit lui-même, doit apporter son expertise sur les enjeux de l’entreprise, la stratégie de son produit, et l’état de l’art du marché où se situe son produit.
La solution doit être utilisable : une personne capable de comprendre les besoins, attentes et difficultés de l’utilisateur. Cette personne sera capable de mener des entretiens utilisateur et de rassembler les données grâce auxquelles élaborer l’expérience utilisateur du produit (UX ou Product Designer).
La solution doit être réalisable : un expert technique, ou architecte, apportant la connaissance des moyens techniques mis en œuvre pour le produit.

Au delà de ce premier cercle se trouvent également les parties prenantes, décideurs, experts sur des métiers spécifiques attenants au produit, les clients et utilisateurs eux-mêmes, … dont l’expérience et les connaissances sont essentielles pour identifier le besoin, le comprendre, et élaborer la solution.

Enfin, le Responsable Produit doit être capable de comprendre les contraintes techniques et communiquer au client sur les limites techniques, quitte à le dire quand c’est impossible. Remarque : concrètement, il s’agit d’être transparent sur les délais et sur les raisons, même si cela amène à mettre de côté une opportunité trop coûteuse.

La phase d’exploration au service d’une compréhension partagée

Elle vise à mieux comprendre le besoin, qu’est-ce qui peut apporter de la valeur, qui soit utile et utilisable, par l’apprentissage. Il s’agit de poser les bonnes questions aux bonnes personnes, de formuler des hypothèses, de les expérimenter avec les personnes concernées, d’analyser les résultats et ainsi d’en apprendre plus sur les besoins, attentes, etc.

Tout les détails qu’on apprend de cette façon vont alimenter l’intitulé des récits utilisateurs, qui vont constituer la cartographie du parcours de l’utilisateur. Ces récits vont à leur tour déclencher de nouvelles discussions, aboutissant à un découpage plus fin et de nouveaux récits, qui vont entraîner de nouvelles discussions, etcætera, etcætera, etcætera. Et dans toute cette démarche, l’important n’est pas d’avoir plein de récits, mais des récits sur lesquels tous partagent la même compréhension.

Cadrer les opportunités selon les intérêts de l’entreprise (positionnement marché, visibilité, bénéfices, etc.).
Comprendre le client (quel bénéfice il escompte) et l’utilisateur (son profil type, comment il travaille, quelles difficultés il rencontre, ce qui lui manque, …).
Concevoir, cartographier la solution, sur la base du parcours de l’utilisateur dans le produit tel qu’on l’envisage, et d’illustrations de ce produit (maquettes, prototypes, …).
Réduire à l’essentiel et planifier.

La cartographie du parcours utilisateur doit nous permettre de penser à toutes les étapes clés et ce qui s’y produit, sans laisser notre imagination combler les trous (ce qu’on s’imagine n’est pas forcément partagé).

Impliquer les équipes techniques tôt dans la phase d’exploration permet de rapidement voir venir les difficultés techniques et d’anticiper les risques, et d’éviter ce moment désagréable, pendant le développement, où les développeurs rencontrent un problème compromettant pour la solution … L’équipe peut alors investir du temps à expérimenter : comprendre l’utilisateur et son besoin, cibler les priorités, réaliser un prototype, tester, … Le parcours utilisateur peut également servir dans les échanges avec l’équipe technique, pour leur donner une vision d’ensemble du sujet (cela peut influencer les choix techniques).

Plutôt que des réunions chronophages et peu productives, privilégier les ateliers, grâce auxquels non seulement nous construisons la compréhension partagée, mais en plus nous construisons le bon produit. Plutôt qu’une grosse réunion pour traiter tout les tickets prévus, plutôt travailler avec de petits ateliers auxquels les membres intéressés de l’équipe peuvent participer.

Une fois qu’il s’agit d’estimer et planifier, toutes les discussions ont déjà eu lieu.

Parce qu’au bout du compte, on fait tout ça pour apprendre…

À la fin d’un cycle (e.g. itération en Scrum), on fête la réussite, mais surtout on fait le point sur les leçons apprises durant l’itération. Cela peut donner lieu à de nouveaux récits utilisateur, que nous traiteront maintenant, ou plus tard.

Rétrospective d’itération : le point de fin d’itération doit permettre de revoir la qualité du produit (expérience utilisateur, fonctionnel, technique), la planification et les processus. Ce point se fait uniquement avec l’équipe du produit.

Revue d’itération :

le point sur l’analyse des opportunités / initiatives, la recherche de solution, la conception fonctionnelle, pour éviter de trop s’investir avant d’apprendre qu’on est sur une fausse piste.
les solutions livrées au cours de l’itération, pour montrer les progrès concrets sur le produit, en repartant du « pour qui », et du « pourquoi ».

Bien penser à expliquer la raison de l’état dans lequel ils verront le produit (on ne va pas forcément montrer quelque chose de livrable à chaque itération, et encore moins d’abouti).

Suivant les retours, nous pouvons être amenés à ajouter de nouveaux récits utilisateur, voir de nouvelles opportunités à étudier. Il faut également savoir identifier le moment où suffisamment de briques (récits) sont traitées pour répondre à un objectif donné (entreprise, client, utilisateur, ou apprentissage). Il est donc important de faire le point sur ces objectifs avec les intervenants concernés pour voir si on les valides, ou voir ce qui manque.

Un logiciel n’est jamais terminé : il y a toujours mieux à faire. D’où l’importance de savoir quand on en a assez fait. Nous n’aurons jamais de garantie absolue de tirer les bénéfices attendues et/ou d’apporter toute la valeur prévue, même si on fait de notre mieux. Enfin, c’est lorsque les utilisateurs utilisent le produit (qu’on les voit l’utiliser et qu’on en parle avec eux) qu’on peut apporter les améliorations qui créent le plus de valeur.

Chaque initiative, épopée et récit pourra être évalué en regard de nos objectifs pour mesurer à quel point on tend vers celui-ci, et potentiellement se concentrer sur les tâches qui en sont le plus loin.

Et ne j’aimais oublier : il sera toujours possible d’en faire plus, le tout est d’avoir fait l’essentiel.

Annexes — Remarques et idées

Approche haut niveau, façon Continuous Discovery

À voir comme une vision au niveau du processus, ou bien pour des équipes plus matures et confrontées à plus d’incertitude.

Évaluer l’opportunité (idée de fonctionnalité, service, produit, problème, point de friction, etc.) -> go/no-go
Concevoir de quoi travailler sur un MVP (analyse du besoin, moyens de contournement, réflexions, conception, maquette, prototype, …), cartographie du récit correspondant -> prioriser les récits identifier les pépites et sujets à traiter en priorité (pour le gain et/ou le risque potentiel)
Évaluer d’un point de vue technique : affiner avant, et pendant leur réalisation/implémentation avec les équipes, évaluer la qualité et l’adéquation avec le besoin en sortie (revue et retrospective de sprint en Scrum).
Évaluer du point de vue des parties prenantes, à chaque fois qu’il y a assez de composants pour évaluer l’ensemble (e.g. un ensemble suffisant pour évaluer une portion significative du parcours) pour les utilisateurs et clients, pour communiquer dans notre progression vers notre vision pour le client et la direction (les jalons du produit susceptible d’avoir un impact commercial).
Livrer, et continuer d’apprendre : donnés d’utilisation, observations, échanges, nouvelles opportunités, … Et nouvelles itérations.

Parcours plus granulaire — Scrum enrichi pour inclure la Discovery

Parcours détaillé, plutôt adapté à des équipes plus grandes et nécessitant plus de prévisibilité technique. Ce cadre est également plus rigide du fait même d’être plus détaillé …

Opportunité : on identifie un besoin, un problème ; on évalue le bénéfice pour l’utilisateur, pour l’entreprise, et la complexité « macro ».
go/no-go : on priorise l’opportunité par rapport aux autres, on décide si on conserve cette opportunité.
L’opportunité qu’on conserve devient une initiative : on lance une démarche d’exploration, càd recherche utilisateur, maquettes, parcours utilisateur, fonctionnement actuels, points de frictions, contraintes techniques, priorités.
Les priorités deviennent une liste de récits utilisateurs, ordonnées de la plus importante à la moins importante. Chaque récit doit être re-découpé en fonction des différents éléments qui la composent.
Penser aux dépendances fonctionnelles (e.g. création/suppression, en voyant bien que l’un et l’autre possèdent des éléments nécessaires et optionnels) et techniques (e.g. on ne peut pas proposer la suppression si on n’est pas en mesure de lister les ressources). La valeur doit permettre d’identifier des composants absolument nécessaires (le plus de valeur, critique, imposés, etc.).
On commence à réfléchir à des solutions candidates : parcours cible, prototypes, etc.
On évalue la complexité de chaque récit en fonction du volume de travail à prévoir (e.g. nouvelle page, nouvelle base de donnée, changements sur le schéma existant, etc.) en prenant en compte le risque (niveau de confiance).
On rassemble ceux qui doivent être traités ensemble sous une épopée.
On ordonne les épopées en fonction de la valeur, de la complexité, et des dépendances (on peut rediscuter du découpage des épopées pour prendre en compte les découvertes lors de l’exploration des solutions possibles).
On valide les solutions retenues pour les récits de la première épopée à traiter.
On affine le travail en mettant à jour les maquettes/prototypes, en ajoutant une spécifications technique, une analyse d’impact technique, …
On évalue les tâches techniques pour les planifier sur le (ou les) prochains sprints.
On implémente les tâches techniques au cours du sprint, on suivant la progression au niveau des récits utilisateur.
On fait le bilan en fin de sprint : est-ce qu’on a suffisamment avancé pour livrer une version à exposer pour évaluation utilisateur, ou est-ce que c’est un incrément d’expérimentation technique ?
On évalue (valeur, complexité, risque) les récits restant par rapport aux épopées en attente et on planifie le prochain sprint.

Des évaluations régulières du point de vue des parties prenantes doivent être intégrées, dès qu’il y a assez de composants pour évaluer l’ensemble du produit. Ces évaluations ont lieu idéalement à chaque sprint (quitte à évaluer un prototype / une proposition). À noter que le sprint doit être aussi court que possible (dans la pratique, souvent entre 2 et 4 semaines, mais pourraient être plus courts).

Version plus « Lean »

Parcours plus adaptée à des start-ups, ou pour une petite équipe ou de taille moyenne, avec un fort focus utilisateur et réduction du risque au plus tôt.

Identification d’une opportunité : problèmes récurrents, analyse du marché, blocage, etc. Cadrer l’opportunité (nom, objectif, périmètre)
Estimation du bénéfice client, de la valeur utilisateur et du gain pour l’entreprise : revenu futur, porté, impact (profil, rôle, travail à faire, …)
Cartographie du parcours de l’utilisateur (étapes clés, points de frictions)
Identification et priorisation des points de friction côté utilisateur, scénarii d’utilisation.
Identification des risques côté technique : complexité, sécurité, légalité, …
Pistes d’étude : maquettes et/ou prototype (graphique ou API sans backend) et/ou diagramme d’activité
Validation de l’hypothèse : retours utilisateurs
Conception technique
Si nécessaire, redécouper sur la base de la valeur apportée, des risques techniques et des dépendances et chercher un minimum à expérimenter pour la prochaine itération.

Remarque : en mode itératif, on a forcément plusieurs cycles imbriqués. Au niveau des opportunités/initiatives, au niveau des récits « haut niveau », entre cartographie/besoins/risque pendant l’exploration du besoin, entre les pistes d’étude et la validation d’hypothèse pour l’exploration des solutions, entre la conception technique et l’implémentation, …

Version très proche du « Design Thinking »

Échanges avec les utilisateurs pour identifier des problèmes pertinents à traiter.
Mettre au clair et cibler un profil cible et l’ensemble de problèmes sélectionnés (petit nombre de problèmes). Remarque : liste priorisée de problèmes (comme ça on sait ce qu’on veut absolument résoudre), voire utiliser un MuSCoW.
Identifier autant de solutions que possible, réalistes ou non.
Réaliser des prototypes sur la base des idées.
Tester ces prototypes avec les utilisateurs pour (in)valider les hypothèses.

NB : également de l’approche Lean Startup combiné au Design Thinking, du fait de l’apprentissage au fil des itérations (Lean), et la recherche constante à mieux maîtriser le besoin du client et de l’utilisateur au fil des itérations (Design Thinking).

Un changement majeur par rapport à « avant » (i.e. approche projet), c’est qu’on assume qu’on part d’une hypothèse, on ne prétend pas qu’elle soit absolument juste, mais on admet que c’est une intuition (plus ou moins informée, plus la passion, et l’expérience), etc. Et qu’on doit la tester pour la prouver.

Un autre changement majeur consiste à construire le minimum experimentable, plutôt que directement « le » produit fini.

Une fois le récit affiné et découpé, il devient facile à prédire le temps nécessaire à sa réalisation. Du coup, à l’échelle d’une itération, nous sommes capables de prédire ce que nous livrerons.

Démarche pour évaluer des idées

Présenter l’ensemble des problèmes et prendre le temps de s’aligner sur leur compréhension (e.g. parcours utilisateur & co).
Laisser chaque participant proposer autant d’idée que possible en quelques minutes, chacun de son côté.
Partager les idées, regrouper les idées similaires.
Voter avec 3 points à distribuer chacun.
Suivant les résultats, prototyper 1~3 premières idées de sorte à pouvoir les proposer aux utilisateurs.
Suivant les retours soit reproposer un ou deux prototypes plus élaborés, ou bien directement passer à la première itération, sur la base du prototype validé.
La première itération après prototypes ne devrait pas viser une première version à mettre entre les mains des utilisateurs, mais servir à identifier les risques.

Dans un cadre Scrum, les étapes 1~5 devraient tenir sur une itération (Refaire des prototypes peut faire l’objet d’une seconde itération).

Remarque : la majeur partie du temps, on s’adressera à des gens qui ont déjà une façon de traiter leur besoin. Donc la plupart du temps, on parlera de la façon de travailler actuelle (avec notre produit, ou des produits du marché) et des difficultés qu’ils rencontrent aujourd’hui. Et potentiellement, on trouvera une facon radicalement différente de faire les choses, et donc un nouveau produit (ou ensemble de).

Valeur « Business »

Quel est l’impact le plus important pour l’entreprise : reconnaissance, acquisition, rétention, dégager des bénéfices, etc.
Profils de client et/ou utilisateurs qui correspondent à la priorité de l’entreprise (ou produit).
Quels sont leurs objectifs et activités les plus importantes.
En dernier lieu, quelle fonctionnalité traiter en premier.

Calcul de la valeur d’un récit

Si on introduit le risque dans l’équation de la valeur, et si on suit la logique de Jeff Patton (i.e. traiter les éléments les plus risqués en priorité), il doit être sur le dividende, à côté des bénéfices entreprise et utilisateur. Du coup, le score totale n’est plus le score de valeur.

On pourrait poser l’équation générale :

Priorité = Valeur * Risque, avec

Valeur = Gain-entreprise + Gain-utilisateur / Complexité

i.e. plus un récit est risqué, plus il faut le traiter rapidement (a.k.a. « dérisquer ») et potentiellement, sa priorité va baisser une fois le risque écarté. À noter aussi la notion d’incertitude, qui représente en soi une forme de risque.