Démarrer un projet avec la user story map

Connaître ses utilisateurs

Avant toute chose, il faut apprendre à connaître ses utilisateurs. Et pour cela, il est utile de concevoir des fiches personae.

Un persona est un utilisateur-type, une représentation fictive des utilisateurs cibles. Souvent utilisé en marketing, c’est un outil très utile pour le product owner.

Outre la connaissance des utilisateurs, l’avantage pour le product owner est qu’il pourra utiliser le point de vue de ces personae pour écrire ses fameuses “user stories”.

Il existe un grand nombre d’outils en ligne pour construire ces fiches d’identité personae, mais globalement, il s’agit de lui trouver un titre, un âge, de décrire brièvement sa typologie d’utilisateur et d’étudier ses motivations, ses frustrations et de fait ses buts et comportements et ce que cela implique.

Voici un exemple de template :

Par exemple, dans le cas d’un projet d’application de matching professionnel, on aurait les personae suivants :

Le recruteur, le candidat et l’administrateur de l’application.

Pour le recruteur on peut imaginer une fiche persona telle que :

Bien sûr, il est possible de différencier les profils de recruteurs et d’avoir des personae différents selon les profils (chasseurs de tête, RH d’une grande entreprise, etc.), mais pour simplifier nous allons partir sur ces trois archétypes.

On voit qu’avec ce template on fait immédiatement ressortir ce qui a de la valeur pour l’utilisateur et qu’on peut d’ores et déjà voir émerger des idées d’innovation pour répondre à ses frustrations.

Il convient de répéter l’exercice pour chacun des personae identifié.

Étudier le parcours de l’utilisateur

En marketing encore une fois (je suis une product owner issue d’une formation marketing, mais vous verrez finalement que bien que le métier puisse sembler éloigné de cette formation, de nombreuses méthodes marketing s’avèrent très utiles dans mon métier), on parle souvent de “parcours client” ; en développement informatique nous parlerons plutôt de parcours utilisateur (ou user journey en anglais). En effet, l’utilisateur n’est pas nécessairement le client. On le voit ici avec le persona de l’administrateur de l’application dans mon exemple précédent.

Il s’agit d’étudier les comportements et les interactions que l’utilisateur va avoir avec notre futur produit. Par exemple si nous reprenons le persona de Louis et que l’on imagine ses interaction avec une application de matching professionnel :

Il s’agit ici d’un parcours simplifié puisqu’on pourrait imaginer encors beaucoup d’actions de la part de ce persona, comme par exemple “parcourir les candidats” pour faire du sourcing exploratoire, etc.

Une fois de plus, la description du parcours utilisateur est à faire pour chaque persona identifiée. Je ne vais pas pour cet exemple le faire pour chaque persona mais pour illustrer mes propos, voici tout de même celui du persona du candidat :

Chaque action correspond à une fonctionnalité du produit qui pourra être développée de manière itérative via les user stories.

Par exemple, pour la fonctionnalité “Créer une offre d’emploi”, on pourra avoir plusieurs phases et donc plusieurs user stories comme “En tant que recruteur, j’indique la description d’une offre d’emploi afin de la publier” / “En tant que recruteur, j’upload une offre d’emploi au format PDF afin de la publier”, etc.

Identifier les thématiques principales

C’est à cette étape que l’on va dégager les thèmes principaux, qui correspondront au niveau Épopée (ou Epic). En effet, si on regarde de plus près nos parcours utilisateurs, cela finit par sauter aux yeux.

Pour le recruteur :

Pour le candidat :

On voit notamment que certaines thématiques sont communes aux deux parcours utilisateurs.

Démarrer le story mapping

Nous pouvons désormais passer au story mapping à proprement parler. Pour ce faire, c’est très simple. Nous allons placer les épopées et les fonctionnalités sur une matrice qui croise le temps (puisque les actions utilisateur sont effectuées dans un ordre “logique”) et la priorité de disponibilité de ces actions dans l’application (notion qui permet outre la mise en évidence des dépendances, introduit également la notion de valeur).

Cela peut sembler curieux d’avoir mis la gestion des utilisateurs en dernier dans l’ordre des épopées, mais finalement l’application peut être utilisée sans cette couche applicative : dès lors qu’il y a des offres d’emplois et des CV de candidats. Il fait donc sens de la placer en dernier.

Ensuite, on place les fonctionnalités, que l’on développera itérativement via les user stories que l’on détaille juste en dessous (ici j’ai zoomé sur les deux premières épopées pour une meilleure lisibilité) :

Et nous voilà déjà avec une ébauche de backlog structuré et une vision du futur produit !

Si on prend soin de réordonner les stories par priorité, on peut même d’ores et déjà voir se dessiner des versions de release du produit :

En bleu, la première version avec le minimum de fonctionnalités requises pour fonctionner. En gris, ce qui pourrait correspondre à une v2 avec plus de détails et de profondeur sur les fonctionnalités basiques.

Et enfin, en vert, une v3 plus innovante avec la gestion d’automatismes : algorithmes, import PDF, partage vers d’autres plateformes, etc.

Gladys NIARFEIX, Lyon, le 31/05/2022