Com escriure històries d'usuari (amb exemples i criteris d'acceptació)

Una història d'usuari és una descripció breu d'una funcionalitat des del punt de vista de l'usuari: "Com a [tipus d'usuari], vull [objectiu] perquè [motiu]." Sota seu escrius els criteris d'acceptació, unes quantes condicions concretes que han de ser certes perquè la història es consideri acabada. Mantén cada història prou petita per construir-la i provar-la d'una vegada, i escriu els criteris de manera que qualsevol pugui comprovar-los.

Les històries d'usuari es van popularitzar als equips de programari àgil, però són igual d'útils quan construeixes pel teu compte amb un creador d'apps amb IA. Una bona història és un bon prompt.

El format

Una història d'usuari té tres parts:

Com a [qui], vull [què] perquè [per què].

Qui és un tipus concret d'usuari: un visitant que entra per primera vegada, un soci que paga, una recepcionista d'una clínica, un administrador. No "l'usuari".
Què és el que vol fer, amb les seves pròpies paraules. No com funciona la pantalla.
Per què és el resultat que li importa. És la part que la gent se salta, i la que evita que construeixis la cosa equivocada.

Exemple:

Com a soci del gimnàs, vull cancel·lar una reserva de classe des del meu mòbil perquè algú de la llista d'espera pugui ocupar la meva plaça i no em cobrin una penalització per no presentar-me.

El "per què" et diu dues coses que el "què" no deia: ha de funcionar en un mòbil, i hi intervenen la llista d'espera i les regles de penalització.

Criteris d'acceptació

Una història diu què es vol. Els criteris d'acceptació diuen quan està feta. Han de ser prou concrets perquè dues persones estiguin d'acord en si cadascun passa o no.

Una manera habitual d'escriure'ls és Donat / Quan / Llavors:

Donat una situació inicial
Quan l'usuari fa alguna cosa
Llavors aquest és el resultat

Per a la història de la reserva del gimnàs:

Donat que tinc una reserva a més de 12 hores vista, quan toco Cancel·la i confirmo, llavors la reserva s'elimina i veig "Reserva cancel·lada".
Donat que cancel·lo una reserva i la classe té llista d'espera, quan la cancel·lació es desa, llavors la primera persona de la llista d'espera rep la plaça i un correu.
Donat una reserva a menys de 12 hores vista, quan toco Cancel·la, llavors veig que s'aplica una penalització per cancel·lació tardana abans de confirmar.
Donat que estic en una pantalla d'amplada de mòbil, llavors el botó Cancel·la es veu sense desplaçar-me lateralment.

Una llista de comprovació simple també funciona, sempre que cada element sigui comprovable. "Cancel·lar és fàcil" no és comprovable. "Cancel·lar necessita com a màxim dos tocs des de la llista de reserves" sí que ho és.

Pas a pas: escriure una bona història

Pas 1: parteix d'un usuari real i d'un problema real

Tria un tipus d'usuari i alguna cosa que avui li costi. Si has fet entrevistes a clients, fes servir les seves paraules. "Sempre oblido cancel·lar i em cobren" és un millor punt de partida que "afegir funcionalitat de cancel·lació".

Pas 2: escriu la història en una línia

Omple la plantilla. Si no pots escriure un "perquè" convincent, pregunta't si la funcionalitat és necessària.

Pas 3: afegeix de tres a sis criteris d'acceptació

Cobreix primer el cas d'èxit principal, i després les variants importants: un altre rol, un estat buit, un límit, un error. Si n'escrius més de sis, probablement la història és massa gran.

Pas 4: anota què queda fora de l'abast

Una línia estalvia molta anada i tornada: "Fora de l'abast: reemborsaments de classes de pagament; administradors que cancel·len en nom dels socis." Evita que la història creixi mentre la construeixes.

Pas 5: comprova-la amb INVEST

INVEST és una llista de comprovació habitual per a bones històries. Una història hauria de ser:

Lletra	Significa	Prova ràpida
I	Independent	Es pot construir sense esperar una altra història
N	Negociable	Descriu la necessitat, no un disseny fix
V	Valuosa	Un usuari notaria si es publiqués
E	Estimable	Pots endevinar aproximadament la seva mida
S	Petita	Es construeix i es prova en una sessió
T	Comprovable	Cada criteri d'acceptació es pot comprovar

No cal puntuar cada història. És més útil quan una història et sembla malament i vols saber per què.

Exemples bons i dolents

Història feble	Problema	Història millor
Com a usuari, vull un tauler.	Sense usuari concret, sense motiu, no comprovable	Com a propietari de la botiga, vull veure les comandes i els ingressos d'avui en una sola pantalla perquè pugui saber d'un cop d'ull si el dia va bé.
Com a administrador, vull que la base de dades tingui una columna d'estat.	Descriu la implementació, no una necessitat	Com a administrador, vull marcar les comandes com a enviades perquè els clients deixin de preguntar-me per correu on són.
Com a client, vull gestionar el meu compte.	Massa gran: cobreix moltes funcionalitats	Com a client, vull canviar la meva adreça de correu perquè els rebuts arribin a la nova safata d'entrada.
Com a visitant, vull que el lloc sigui ràpid.	No és una història; és una qualitat que tothom necessita	Escriu-ho com a criteri a cada història, o com un objectiu de rendiment separat.

Com dividir una història que és massa gran

Les històries grans són on els projectes s'encallen. Maneres habituals de dividir-les:

Per rol d'usuari. Els socis cancel·len les seves pròpies reserves; el personal cancel·la les de qualsevol.
Per pas del flux. Veure classes; reservar una classe; rebre un recordatori.
Cas simple primer. Cancel·lar una classe gratuïta ara; gestionar penalitzacions i reemborsaments en una història posterior.
Per variació de dades. Admetre primer una ubicació; més endavant, diverses.
Camí feliç i després errors. Construeix-ho perquè funcioni, i després afegeix la gestió de classes plenes, passis caducats, etc.

Cada part ha de ser encara alguna cosa que un usuari pugui fer servir i notar.

Fer servir les històries d'usuari com a prompts

Una història d'usuari amb criteris d'acceptació és molt semblant a un bon prompt per a un creador d'apps amb IA. Li dona a la IA el qui, el què, el per què i una definició de completat. Envia una història per missatge:

Com a soci del gimnàs, vull cancel·lar una reserva de classe des del meu mòbil perquè algú de la llista d'espera pugui ocupar la meva plaça. Criteris d'acceptació:

Cancel·la apareix a cada reserva de Les meves reserves, amb un pas de confirmació.

Si cancel·les més de 12 hores abans de la classe, la reserva s'elimina sense més.

A menys de 12 hores, mostra "S'aplica una penalització de 5 $ per cancel·lació tardana" abans de confirmar, i registra la penalització a la reserva.

Si la classe té llista d'espera, la primera persona rep la plaça i un correu.

Funciona en una pantalla d'amplada de mòbil. Fora de l'abast: reemborsaments, personal que cancel·la per als socis. Construeix-ho i després comprova cada criteri a la vista prèvia i digues-me quins passen.

També pots demanar a la IA que redacti històries a partir d'una idea aproximada i després editar-les tu mateix:

Aquesta és la meva idea d'app: [dues o tres frases]. Escriu les històries d'usuari per a una primera versió, agrupades per tipus d'usuari, amb 3 a 5 criteris d'acceptació Donat/Quan/Llavors cadascuna. Marca quines són imprescindibles per al llançament i quines poden esperar.

Llegeix i edita sempre el resultat. La IA no coneix els teus usuaris; tu sí.

Els criteris d'acceptació també fan de pla de proves. Quan la història estigui construïda, repassa tu mateix cada criteri. La nostra guia sobre com provar la teva app abans del llançament es basa en això.

On encaixen les històries d'usuari amb altres documents

Un document de requisits de producte descriu el producte sencer: el problema, els usuaris, l'abast. Les històries d'usuari són les peces detallades que hi ha dins. Consulta com escriure un PRD amb IA.
Un informe d'error descriu alguna cosa que no funciona en relació amb una història ja construïda. Consulta com escriure un bon informe d'error.
Un MVP és el conjunt més petit d'històries que ofereix el valor principal. Consulta què és un MVP.

Errors habituals

"Com a usuari..." Massa vague. Anomena el tipus d'usuari real.
Saltar-se el "perquè". Sense el motiu, no pots fer compensacions sensates.
Escriure la solució en lloc de la necessitat. "Vull un desplegable" fixa un disseny abans que ningú n'hagi pensat.
Criteris que no es poden provar. "Fàcil", "ràpid" i "intuïtiu" són desitjos, no criteris.
Històries que en realitat són èpiques. "Gestionar el meu compte" són deu històries.
Escriure totes les històries per endavant. Escriu les properes amb detall; deixa la resta com a una línia fins que hi arribis.

Històries a Mythex

A Mythex, el mode Plan és un bon lloc per convertir una idea en històries: l'agent discuteix l'enfocament abans de modificar res. Quan una història estigui a punt, canvia a Build i enganxa-la, una història per missatge. Després de cada una, /test pot fer clic per la vista prèvia i comprovar el flux, i pots desfer qualsevol resposta amb Torna a aquest punt si ha anat malament. Consulta prompts efectius a la documentació, i la nostra guia sobre com escriure prompts per a creadors d'apps amb IA.

Llista de comprovació de les històries d'usuari

Anomena un tipus concret d'usuari
Descriu una necessitat, no un disseny
Inclou un "perquè" real
Té de tres a sis criteris d'acceptació comprovables
Cobreix almenys un cas límit o un error
Indica què queda fora de l'abast
Prou petita per construir-la i provar-la d'una vegada
Criteris comprovats un per un després de construir

Preguntes

Quin és el format d'una història d'usuari?

La plantilla habitual és: Com a [tipus d'usuari], vull [objectiu] perquè [motiu]. Va seguida de criteris d'acceptació, una llista curta de condicions que han de ser certes perquè la història es consideri acabada.

Què són els criteris d'acceptació?

Els criteris d'acceptació són condicions concretes i comprovables que defineixen quan una història d'usuari està completa. Sovint s'escriuen en format Donat / Quan / Llavors: donada una situació inicial, quan l'usuari fa alguna cosa, llavors es produeix un resultat concret.

Com de gran ha de ser una història d'usuari?

Prou petita per construir-la i provar-la en una sola sessió, i encara útil per si sola. Si una història té més de cinc o sis criteris d'acceptació o cobreix diverses pantalles, divideix-la per rol d'usuari, per pas del flux o per cas simple primer i casos límit després.

Les històries d'usuari són útils quan construeixo amb IA?

Sí. Una història d'usuari amb criteris d'acceptació és gairebé un prompt ideal: diu per a qui és la funcionalitat, què necessiten i exactament com comprovar que funciona. Enviar una història per missatge també manté els canvis de la IA petits i fàcils de provar.