Comment rédiger des récits d'utilisateurs (avec exemples et critères d'acceptation)
Un récit d'utilisateur est une courte description d'une fonctionnalité du point de vue de l'utilisateur : « En tant que [type d'utilisateur], je veux [objectif] afin de [raison]. » Sous le récit, vous rédigez des critères d'acceptation, quelques conditions précises qui doivent être vraies pour que le récit soit considéré comme terminé. Gardez chaque récit assez petit pour être construit et testé d'un seul coup, et rédigez les critères de façon que n'importe qui puisse les vérifier.
Les récits d'utilisateurs ont été popularisés par les équipes logicielles agiles, mais ils sont tout aussi utiles quand vous construisez seul avec un générateur d'applications IA. Un bon récit est une bonne requête.
Le format
Un récit d'utilisateur comporte trois parties :
En tant que [qui], je veux [quoi] afin de [pourquoi].
- Qui est un type précis d'utilisateur : un visiteur qui arrive pour la première fois, un membre payant, une réceptionniste de clinique, un administrateur. Pas « l'utilisateur ».
- Quoi est ce que la personne veut faire, dans ses propres mots. Pas la façon dont l'écran fonctionne.
- Pourquoi est le résultat qui lui importe. C'est la partie que l'on oublie souvent, et celle qui vous empêche de construire la mauvaise chose.
Exemple :
En tant que membre de gym, je veux annuler une réservation de cours depuis mon téléphone afin que quelqu'un sur la liste d'attente puisse prendre ma place et que je ne sois pas facturé de frais d'absence.
Le « pourquoi » vous indique deux choses que le « quoi » ne disait pas : cela doit fonctionner sur téléphone, et les règles de la liste d'attente et des frais entrent en jeu.
Critères d'acceptation
Un récit dit ce qui est souhaité. Les critères d'acceptation disent quand c'est terminé. Ils doivent être assez précis pour que deux personnes puissent s'accorder sur la réussite de chacun.
Une façon courante de les écrire est Étant donné / Quand / Alors :
- Étant donné une situation de départ
- Quand l'utilisateur fait quelque chose
- Alors voici le résultat
Pour le récit de réservation de gym :
- Étant donné que j'ai une réservation dans plus de 12 heures, quand je touche Annuler et confirme, alors la réservation est retirée et je vois « Réservation annulée ».
- Étant donné que j'annule une réservation et que le cours a une liste d'attente, quand l'annulation est enregistrée, alors la première personne sur la liste d'attente obtient la place et un courriel.
- Étant donné une réservation dans moins de 12 heures, quand je touche Annuler, alors je vois qu'des frais d'annulation tardive s'appliquent avant de confirmer.
- Étant donné que je suis sur un écran de la largeur d'un téléphone, alors le bouton Annuler est visible sans défilement horizontal.
Une simple liste de contrôle fonctionne aussi, tant que chaque élément est vérifiable. « Annuler est facile » n'est pas vérifiable. « Annuler prend au maximum deux touches depuis la liste des réservations » l'est.
Étape par étape : rédiger un bon récit
Étape 1 : Partez d'un vrai utilisateur et d'un vrai problème
Choisissez un type d'utilisateur et quelque chose avec lequel il a du mal aujourd'hui. Si vous avez fait des entrevues avec des clients, utilisez leurs mots. « J'oublie toujours d'annuler et je me fais facturer » est un meilleur point de départ que « ajouter une fonctionnalité d'annulation ».
Étape 2 : Rédigez le récit en une ligne
Remplissez le modèle. Si vous ne parvenez pas à écrire un « afin de » convaincant, demandez-vous si la fonctionnalité est vraiment nécessaire.
Étape 3 : Ajoutez trois à six critères d'acceptation
Couvrez d'abord le cas de réussite principal, puis les variantes importantes : un autre rôle, un état vide, une limite, une erreur. Si vous en écrivez plus de six, le récit est probablement trop gros.
Étape 4 : Notez ce qui est hors périmètre
Une ligne vous épargne beaucoup d'allers-retours : « Hors périmètre : remboursements pour les cours payants ; annulation par les administrateurs au nom des membres. » Cela empêche le récit de grossir pendant la construction.
Étape 5 : Vérifiez-le avec INVEST
INVEST est une liste de contrôle courante pour les bons récits. Un récit doit être :
| Lettre | Signifie | Test rapide |
|---|---|---|
| I | Indépendant | Peut être construit sans attendre un autre récit |
| N | Négociable | Décrit le besoin, pas une conception figée |
| V | Valorisable | Un utilisateur remarquerait s'il était livré |
| E | Estimable | Vous pouvez deviner approximativement sa taille |
| S | Petit | Construit et testé en une séance |
| T | Testable | Chaque critère d'acceptation peut être vérifié |
Vous n'avez pas besoin de noter chaque récit. C'est surtout utile quand un récit semble mal et que vous voulez savoir pourquoi.
Exemples bons et mauvais
| Récit faible | Problème | Meilleur récit |
|---|---|---|
| En tant qu'utilisateur, je veux un tableau de bord. | Aucun utilisateur précis, aucune raison, non vérifiable | En tant que propriétaire de boutique, je veux voir les commandes et les revenus du jour sur un seul écran afin de savoir d'un coup d'œil si la journée se passe bien. |
| En tant qu'administrateur, je veux que la base de données ait une colonne d'état. | Décrit l'implémentation, pas un besoin | En tant qu'administrateur, je veux marquer les commandes comme expédiées afin que les clients cessent de nous écrire pour demander où elles en sont. |
| En tant que client, je veux gérer mon compte. | Trop gros : couvre plusieurs fonctionnalités | En tant que client, je veux changer mon adresse courriel afin que les reçus aillent à ma nouvelle boîte de réception. |
| En tant que visiteur, je veux que le site soit rapide. | Ce n'est pas un récit ; c'est une qualité que tout le monde attend | Rédigez-le comme un critère sur chaque récit, ou comme un objectif de performance distinct. |
Comment découper un récit trop gros
Les gros récits sont là où les projets s'enlisent. Façons courantes de les découper :
- Par rôle d'utilisateur. Les membres annulent leurs propres réservations ; le personnel annule celles de tous.
- Par étape du parcours. Parcourir les cours ; réserver un cours ; recevoir un rappel.
- Cas simple d'abord. Annuler un cours gratuit maintenant ; gérer les frais et les remboursements dans un récit ultérieur.
- Par variation de données. Prendre en charge un seul emplacement d'abord, plusieurs plus tard.
- Cas de réussite, puis erreurs. Faire fonctionner d'abord, puis ajouter la gestion des cours complets, des laissez-passer expirés, etc.
Chaque morceau doit rester quelque chose qu'un utilisateur peut utiliser et remarquer.
Utiliser les récits d'utilisateurs comme requêtes
Un récit d'utilisateur avec critères d'acceptation se rapproche beaucoup d'une bonne requête pour un générateur d'applications IA. Il donne à l'IA le qui, le quoi, le pourquoi et une définition de terminé. Envoyez un récit par message :
En tant que membre de gym, je veux annuler une réservation de cours depuis mon téléphone afin que quelqu'un sur la liste d'attente puisse prendre ma place. Critères d'acceptation :
- Annuler figure sur chaque réservation dans Mes réservations, avec une étape de confirmation.
- Annuler plus de 12 heures avant le cours retire simplement la réservation.
- Moins de 12 heures avant, affiche « Des frais d'annulation tardive de 5 $ s'appliquent » avant de confirmer, et enregistre les frais sur la réservation.
- Si le cours a une liste d'attente, la première personne obtient la place et un courriel.
- Fonctionne sur un écran de la largeur d'un téléphone. Hors périmètre : remboursements, annulations par le personnel au nom des membres. Construis ceci, puis vérifie chaque critère dans l'aperçu et dis-moi lesquels passent.
Vous pouvez aussi demander à l'IA de rédiger des récits à partir d'une idée approximative, puis les modifier vous-même :
Voici mon idée d'application : [deux ou trois phrases]. Rédige les récits d'utilisateurs pour une première version, regroupés par type d'utilisateur, chacun avec 3 à 5 critères Étant donné / Quand / Alors. Indique lesquels sont essentiels au lancement et lesquels peuvent attendre.
Lisez et modifiez toujours le résultat. L'IA ne connaît pas vos utilisateurs ; vous, si.
Les critères d'acceptation servent aussi de plan de test. Une fois le récit construit, parcourez vous-même chaque critère. Notre guide sur tester votre application avant le lancement s'appuie sur cette démarche.
Où les récits d'utilisateurs s'insèrent parmi les autres documents
- Un document d'exigences produit décrit l'ensemble du produit : le problème, les utilisateurs, le périmètre. Les récits d'utilisateurs en sont les pièces détaillées. Voir comment rédiger un PRD avec l'IA.
- Un rapport de bogue décrit quelque chose de cassé par rapport à un récit déjà construit. Voir comment rédiger un bon rapport de bogue.
- Un MVP est le plus petit ensemble de récits qui livre la valeur essentielle. Voir qu'est-ce qu'un MVP.
Erreurs courantes
- « En tant qu'utilisateur… » Trop vague. Nommez le type d'utilisateur réel.
- Omettre le « afin de ». Sans la raison, vous ne pouvez pas faire de compromis judicieux.
- Écrire la solution au lieu du besoin. « Je veux une liste déroulante » fige une conception avant que quiconque ait réfléchi au problème.
- Des critères impossibles à tester. « Facile », « rapide » et « intuitif » sont des souhaits, pas des critères.
- Des récits qui sont en fait des épopées. « Gérer mon compte » représente dix récits.
- Rédiger tous les récits à l'avance. Rédigez les prochains en détail ; gardez le reste en une ligne jusqu'à ce que vous y arriviez.
Les récits dans Mythex
Dans Mythex, le mode Plan est un bon endroit pour transformer une idée en récits : l'agent discute de l'approche avant de modifier quoi que ce soit. Quand un récit est prêt, passez en mode Construire et collez-le, un récit par message. Après chacun, /test peut cliquer dans l'aperçu et vérifier le parcours, et vous pouvez annuler toute réponse avec Revenir à ce point si elle prend la mauvaise direction. Voir requêtes efficaces dans la documentation, et notre guide sur la rédaction de requêtes pour les générateurs d'applications IA.
Liste de vérification des récits d'utilisateurs
- Nomme un type d'utilisateur précis
- Décrit un besoin, pas une conception
- Inclut une vraie raison « afin de »
- Comporte trois à six critères d'acceptation vérifiables
- Couvre au moins un cas limite ou une erreur
- Précise ce qui est hors périmètre
- Assez petit pour être construit et testé d'un coup
- Critères vérifiés après la construction, un à un
Questions
Quel est le format d'un récit d'utilisateur ?
Le modèle courant est : En tant que [type d'utilisateur], je veux [objectif] afin de [raison]. Il est suivi de critères d'acceptation, une courte liste de conditions qui doivent être vraies pour que le récit soit considéré comme terminé.
Que sont les critères d'acceptation ?
Les critères d'acceptation sont des conditions précises et vérifiables qui définissent quand un récit d'utilisateur est complété. On les écrit souvent au format Étant donné / Quand / Alors : étant donné une situation de départ, quand l'utilisateur fait quelque chose, alors un résultat particulier se produit.
Quelle devrait être la taille d'un récit d'utilisateur ?
Assez petit pour être construit et testé en une seule séance, tout en ayant de la valeur par lui-même. Si un récit compte plus de cinq ou six critères d'acceptation ou couvre plusieurs écrans, découpez-le par rôle d'utilisateur, par étape du parcours ou par cas simple d'abord, et les cas limites ensuite.
Les récits d'utilisateurs sont-ils utiles quand on construit avec l'IA ?
Oui. Un récit d'utilisateur avec des critères d'acceptation se rapproche d'une requête idéale : il indique à qui s'adresse la fonctionnalité, ce dont la personne a besoin et exactement comment vérifier que cela fonctionne. Envoyer un récit par message garde aussi les changements de l'IA petits et faciles à tester.