La User Story, ou comment mieux exprimer le besoin de l’utilisateur ?

Dans la phase de conception d’un projet numérique, il est important de comprendre la vision globale du projet. C’est l’objectif du premier atelier du Product Design Sprint tel que nous le pratiquons chez Tymate.

Lors de nos ateliers, plutôt que de décrire des besoins comme c’est le cas dans un cahier des charges traditionnel, nous définissons l’usage sous forme de User Stories. On vous explique le pourquoi du comment.

La définition de l’usage précis

Une User Story est une description simple et compréhensible d'un usage. Elle doit être centrée sur la création de valeurs pour l’utilisateur en répondant aux questions : Qui ? Quoi ? Pourquoi ?

En tant que ... (Qui?)

Je souhaite ... (Quoi ?)

Afin de ... (Pourquoi ?)

Une User Story ne doit en aucun cas être une simple description fonctionnelle ou technique car elle risque de ne pas spécifier correctement le besoin et peut être interprétée de manière différente.

Exemple d’une approche descriptive :

• Le produit doit fonctionner avec un moteur à essence, 

• Le produit doit être équipé de 4 pneus gomme, 

• Le produit doit disposer d’un volant,

• Le produit doit avoir une structure en acier.

Après ces quatre descriptions fonctionnelles, à quoi pensez-vous ? 

Une voiture 🚗 ? Un camion 🚚 ? Un quad 🏍 ? Un tracteur 🚜

Prenons le même produit décrit cette fois avec un scénario utilisateur (User Story). 

“En tant qu’homme de 60 ans, je souhaite tondre ma pelouse en étant assis afin de ne pas me fatiguer et gagner du temps.”

Aucune place au doute, une seule réponse précise : une tondeuse autoportée 🌱

Cette user story répond spécifiquement aux trois questions citées ci-dessus :

• “QUI ?” : En tant que : Homme de 60 ans

• “QUOI ?” : Je souhaite : Tondre ma pelouse en étant assis

• “POURQUOI ?” : Afin de : ne pas me fatiguer et gagner du temps

Les critères d’une bonne User Story

Pour prioriser une User Story le plus objectivement possible, nous l'évaluons selon le modèle INVEST :

Independant / Indépendante : Est-ce que la User Story correspond à une fonctionnalité unique, est-elle dépendante d’autres fonctionnalités ? Negociable / Négociable : Est-ce que la User Story est claire et validée par les équipes ?

Valuable / Valorisable : Quelle est la valeur ajoutée de la User Story ? La pertinence d’une User Story réside dans le bénéfice utilisateur. Chaque User Story doit répondre à un besoin spécifique. Estimable / Estimable : Quel est le coût de développement technique estimé pour la User Story ? Il faut trouver le bon équilibre entre valeur ajoutée et complexité technique.

Small / Précise : Est-ce que la User Story est assez précise ? Si ce n’est pas le cas ou qu’elle est trop longue, il sera nécessaire de la découper. Testable : Quels sont les prérequis (techniques, éditorial, performance, …) nécessaires pour tester le bon fonctionnement du scénario ?

En conclusion…

Définir un projet à l’aide de User Stories est une approche beaucoup plus performante qu’un système descriptif, souvent retrouvé dans un cahier des charges. Focalisée sur l’usage, la valeur ajoutée, l’humain, l’expérience, la finalité recherchée, cette approche s’émancipe du produit et de la technique pour se concentrer sur l’expérience et le besoin. Enfin, côté développement, cela permet aux équipes de prendre du recul sur la fonction pour se concentrer sur la finalité.