Est-ce que « en tant qu’internaute j’ai accès à un fil d’Ariane sur chaque page du site » c’est une user story ?
J’ai dû me poser des centaines de fois cette question depuis que j’exerce mon métier. On me l’a à nouveau posé récemment, et pour la première fois j’avais une réponse.
Note : un fil d’ariane, ou breadcrumbs en anglais, est un composant qui facilite la navigation sur un site internet. Plus d’information sur le site d’Opquast.
Ma définition préférée d’une user story, ou histoire utilisateur, est :
A user story is a placeholder for a conversation.
Ma compréhension est : c’est un ensemble d’éléments qui vont donner lieu à une conversation à propos d’un problème rencontré par un utilisateur (de notre service, de notre logiciel…).
Il s’agit donc de discuter pour déterminer quel est le problème de l’utilisateur, et comment le résoudre de manière à créer un impact positif pour nous.
De quels éléments avons-nous besoin ? C’est à chacun·e de le déterminer. Quelques idées :
Le fameux format “En tant que (qui), Je veux (quoi), Dans le but de (pourquoi)” est un exemple qui reprend une partie de ces éléments.
Le framework “Jobs To Be Done” est une autre illustration qui se concentre sur le “Où/Quand” plutôt que le “Qui”.
Le seul élément absolument nécessaire est le pourquoi. Pourquoi faut-il résoudre ce problème ? C’est dans ce pourquoi que se cache la valeur de notre travail, si l’on ne sait pas le déterminer, on ne sait pas pourquoi on fait ce que l’on fait.
On peut donc répondre à la question initiale : ce n’est pas une user story, puisqu’il n’y a pas de pourquoi !
Si j’avais vu cette histoire utilisateur, ma première réaction aurait été de demander à son auteur “pourquoi veux-tu un fil d’Ariane ?”. J’aurais certainement eu une réponse de l’intéressé, qui aurait sûrement évoqué d’autres questions, et ainsi de suite. N’est-ce pas la définition même d’une conversation ?
Le jour où j’ai réalisé que s’il était primordial de déterminer le “pourquoi” on fait ce que l’on fait, il était souvent compliqué de commencer par là. Il est bien plus simple de parler d’une solution (un fil d’Ariane) que du problème qu’elle résout (faciliter la navigation et le repérage sur un site internet). C’est humain, c’est normal, et c’est notre rôle en tant qu’équipe produit (dans laquelle j’inclus toutes les personnes qui touchent de près ou de loin au produit) de faire émerger le “pourquoi”.
C’est la raison pour laquelle je trouve la définition citée plus haut intéressante : la conversation est le moyen de faire émerger à la fois le problème à partir d’une solution, ou bien une solution à partir d’un problème. Et de faire des allers-retours entre les deux au fur et à mesure que notre compréhension s’améliore.
Dans l’exemple du fil d’Ariane, le problème est de faciliter la navigation et le repérage sur un site. Une fois qu’on l’a compris, on peut se poser la question : le fil d’Ariane est-il la solution la plus adaptée ? Doit-on plutôt revoir notre hiérarchie visuelle ou l’emplacement et le style du menu ?
La conversation peut avoir lieu avec des utilisateurs finaux, avec des membres de votre organisation, avec de potentiels utilisateurs. Il ne faut pas se restreindre. Je dirais même qu’il faut plusieurs conversations avec un mélange de tous ces acteurs.
Dans notre exemple du fil d’Ariane, faut-il vraiment se faire des nœuds au cerveau ? Après tout, un fil d’Ariane est une affordance reconnue, présente par défaut dans la plupart des systèmes de gestion de contenu. Faut-il systématiquement faire l’effort d’aller chercher le pourquoi ? Est-ce pertinent pour chaque fonctionnalité ? Je ne pense pas.
Deux dimensions à garder en tête :
Si l’investissement global devient délirant à cause d’un coût de conception élevé, alors ce n’est pas pertinent. Pensez au temps passé à préparer, réaliser, et analyser un questionnaire client ou une étude qualitative de terrain. Très souvent sous-estimé (en tout cas à titre personnel).
Si la solution en place est suffisamment simple pour être modifiée, enrichie, supprimée plus tard, alors mitiger les conséquences d’une erreur est aisé.
C’est pour cette raison qu’on dit souvent qu’il faut faire la version la plus simple possible, puis itérer. Cela limite l’investissement global tout en réduisant le coût de se tromper. Malheureusement, il faut des boucles de feedbacks courtes pour que cela fonctionne, et ce n’est pas mon cas aujourd’hui (pour plein de bonnes et de mauvaises raisons).
J’ai donc adapté mon mode de décision comme ceci :
Est-ce que la fonctionnalité est au cœur de ma proposition de valeur ?
J’équilibre donc entre conception appuyée et développement rapide afin de minimiser la boucle de feedbacks. C’est très lié à mon contexte.
Dans tous les cas, les notions d’investissement en conception et de risque sont liées à un point central : l’incertitude.
Un des problèmes du format “En tant que…je veux….dans le but de….” est qu’il masque totalement l’incertitude associée. Quand on réalise un développement, on fait le pari qu’il va changer (positivement) le comportement de l’utilisateur, et qu’en retour nous en tirerons de la valeur.
Par exemple :
Ou alors :
Toute la démarche agile consiste à réduire l’incertitude et minimiser le risque de se tromper. Encore faut-il rendre visible l’incertitude et expliciter le chemin d’apprentissage. Ce n’est pas toujours simple, et pour cause, tout le monde n’est pas à l’aise avec l’incertitude, à commencer par la personne à l’origine de la demande qui est persuadée du bien fondé de sa requête.
Changer la façon de présenter le problème, par exemple en utilisant le mot “pari” est un début pour changer la façon de le penser et avoir des conversations intéressantes.
- Pourquoi tu parles de pari ?! Je suis SÛR que ça va marcher
- Ah oui, pourquoi ?
C’est une des pistes que je mets petit à petit en œuvre au sein de mon organisation. Je pense que c’est un réflexe collectif sain mais difficile à acquérir.
Une histoire utilisateur évolue donc dans le temps en fonction de ce qu’on apprend et qu’on réduit l’incertitude. Elle peut changer, se transformer, voir même donner lieu à de nouvelles histoires !
Une des difficultés pour écrire des histoires utilisateurs est la taille du problème qu’on cherche à résoudre. C’est pour cela qu’on parle d’epics et de user stories. Une epic est une grosse histoire qu’on découpe en plusieurs sous-histoires. La distinction concrète ne m’a jamais aidé jusqu’à présent, mais j’apprécie la métaphore du rocher pour illustrer la problématique. Un rocher éclate en plusieurs pierres, chacune d’entre elles éclatent et forment des graviers.
On peut suivre le même raisonnement pour une histoire utilisateur. Quelle est la taille idéale ? Je pense qu’il y a deux niveaux différents :
Dans les deux cas ce sont des discussions à avoir : avec la direction pour le premier, et avec l’équipe pour le second.
C’est l’histoire de Mathilde. Elle est sur notre site directement sur la page qui l’intéresse grâce à un bon référencement (75 % de notre trafic provient des moteurs de recherche). Elle apprécie de la trouver rapidement. Malheureusement, une fois qu’elle a obtenu ce qu’elle cherchait, nous nous apercevons qu’elle quitte le site alors que d’autres informations pourraient l’intéresser. Nous le savons, car nous avons fait des entretiens récemment. Mathilde se sent “perdue” (75 % des gens dans les entretiens) et ne comprend pas quelles autres informations pertinentes elle pourrait trouver (85 % des gens dans les entretiens). Après explication de ce que nous proposons, 50 % des personnes sont intéressées par au moins une autre page du site. 10 % d’entre elles ont même dégainé leur téléphone pour regarder immédiatement.
Notre hypothèse est qu’un fil d’Ariane faciliterait la compréhension de la structure et la navigation au sein du site, et inciterait Mathilde à parcourir d’autres pages de notre site plutôt qu’à le quitter. Nous évaluerons le succès au bout de deux semaines, grâce à la diminution du taux de rebonds sur ces pages de 20 points et l’augmentation du nombre moyen de pages vues par visite à 3 pages contre 1,1 aujourd’hui.
Une histoire utilisateur est avant tout une histoire. Une bonne histoire est percutante, ses protagonistes sont attachant·e·s, elle a un enjeu. On a tendance à traiter les histoires utilisateurs comme des tâches dans une liste et c’est nier une de leurs principales forces. Je suis le premier coupable.
Toutes les informations ne sont pas utiles ou disponibles et ce n’est pas grave. Un tel travail n’est pas adapté à tous les sujets et c’est normal. Je fais beaucoup mention de mesures qualitatives et quantitatives, elles permettent de réduire le risque et illustrent un chemin d’apprentissage.
La valeur d’une histoire est la discussion qui suit avec nos utilisateurs et nos collègues. Les questions qu’on se pose sur la valeur du problème à résoudre, de l’adéquation de la solution. Sur ce qu’on sait qu’on sait, et qu’on sait qu’on ne sait pas.
Alors, plutôt que de se demander si l’on est en train d’écrire une histoire utilisateur ou autre chose, demandons-nous avec qui nous allons en discuter !