Hogyan írjunk felhasználói történeteket (példákkal és elfogadási kritériumokkal)

A felhasználói történet egy funkció rövid leírása a felhasználó szemszögéből: „Mint [felhasználótípus], szeretnék [cél], hogy [ok].” Alatta elfogadási kritériumokat írsz, néhány konkrét feltételt, amelyeknek teljesülniük kell ahhoz, hogy a történet késznek számítson. Minden történet legyen elég kicsi ahhoz, hogy egy menetben meg lehessen építeni és tesztelni, a kritériumokat pedig úgy írd meg, hogy bárki ellenőrizni tudja őket.

A felhasználói történeteket agilis szoftvercsapatok tették népszerűvé, de egyedül, AI-alkalmazásépítővel dolgozva is ugyanolyan hasznosak. Egy jó történet jó prompt.

A formátum

A felhasználói történetnek három része van:

Mint [ki], szeretnék [mit], hogy [miért].

• Ki egy konkrét felhasználótípus: első alkalommal látogató, fizetős tag, klinikai recepciós, adminisztrátor. Nem „a felhasználó”.
• Mit az, amit a felhasználó meg akar tenni, a saját szavaival. Nem az, hogyan működik a képernyő.
• Miért az az eredmény, amit fontosnak tart. Ezt szokták kihagyni, pedig ez óvja meg attól, hogy rossz dolgot építs.

Példa:

Mint edzőteremi tag, szeretnék telefonról lemondani egy órafoglalást, hogy a várólistán lévő valaki átvehesse a helyem, és ne kelljen távolmaradási díjat fizetnem.

A „miért” két olyan dolgot mond el, amit a „mit” nem: telefonon is működnie kell, és a várólista és a díjszabály is szerepet játszik.

Elfogadási kritériumok

A történet azt mondja meg, mit szeretnénk. Az elfogadási kritériumok azt, mikor kész. Legyenek elég konkrétak ahhoz, hogy két ember egyetértsen abban, megfelel-e mindegyik.

Gyakori módja a Adott / Amikor / Akkor formátum:

• Adott egy kiindulási helyzet
• Amikor a felhasználó tesz valamit
• Akkor ez az eredmény

Az edzőtermi foglalási történethez:

1. Adott egy foglalásom 12 óránál távolabb, amikor megnyomom a Lemondás gombot és megerősítem, akkor a foglalás törlődik, és a „Foglalás lemondva” üzenetet látom.
2. Adott egy lemondott foglalás, és az órára várólista van, amikor a lemondás mentődik, akkor a várólista első embere megkapja a helyet és egy e-mailt.
3. Adott egy foglalás 12 órán belül, amikor megnyomom a Lemondás gombot, akkor a megerősítés előtt látom, hogy késői lemondási díj vonatkozik rá.
4. Adott, hogy telefon-szélességű képernyőn vagyok, akkor a Lemondás gomb vízszintes görgetés nélkül látható.

Egy egyszerű ellenőrzőlista is működik, ha minden eleme tesztelhető. A „a lemondás egyszerű” nem tesztelhető. A „a lemondás legfeljebb két koppintás a foglalási listából” az.

Lépésről lépésre: jó történet írása

1. lépés: Valódi felhasználóból és valódi problémából indulj ki

Válassz egy felhasználótípust és valamit, amivel ma küszködnek. Ha készítettél ügyfél-interjúkat, használd a szavaikat. Az „mindig elfelejtek lemondani, és mégis fizetnem kell” jobb kiindulópont, mint az „lemondási funkció hozzáadása”.

2. lépés: Írd le az egysoros történetet

Töltsd ki a sablont. Ha nem tudsz meggyőző „hogy”-et írni, kérdezd meg magadtól, szükséges-e egyáltalán a funkció.

3. lépés: Adj hozzá három-hat elfogadási kritériumot

Először a fő sikeres esetet fedd le, aztán a fontos változatokat: másik szerep, üres állapot, korlát, hiba. Ha hatnál többet írsz, valószínűleg túl nagy a történet.

4. lépés: Jegyezd fel, mi van a hatókörön kívül

Egy sor sok fel-alá küldözgetést megspórol: „Hatókörön kívül: fizetős órák visszatérítése; adminisztrátorok lemondása tagok helyett.” Így a történet nem nő az építés közben.

5. lépés: Ellenőrizd INVEST szerint

Az INVEST a jó történetek gyakori ellenőrzőlistája. Egy történetnek:

Nem kell minden történetet pontozni. Akkor a leghasznosabb, ha egy történet furcsának tűnik, és meg akarod érteni, miért.

Jó és rossz példák

Hogyan bontsz fel egy túl nagy történetet

A nagy történeteknél akadnak el a projektek. Gyakori felosztási módok:

• Felhasználói szerep szerint. A tagok lemondják a saját foglalásaikat; a munkatársak bárkiét.
• A folyamat lépése szerint. Órák böngészése; óra foglalása; emlékeztető kapása.
• Először az egyszerű eset. Egy ingyenes óra lemondása most; díjak és visszatérítések egy későbbi történetben.
• Adatváltozatok szerint. Először egy helyszín támogatása, később több.
• Sikeres út, majd hibák. Először működjön, aztán jöhet a betelt órák, lejárt bérletek stb. kezelése.

Minden darabnak továbbra is olyan dolognak kell lennie, amelyet a felhasználó használhat és észrevesz.

Felhasználói történetek promptként

Az elfogadási kritériumokkal rendelkező felhasználói történet nagyon közel áll egy jó AI-alkalmazásépítő-prompthoz. Megadja a kit, a mit, a miért és a kész definícióját. Üzenetenként egy történetet küldj:

Mint edzőteremi tag, szeretnék telefonról lemondani egy órafoglalást, hogy a várólistán lévő valaki átvehesse a helyem. Elfogadási kritériumok:

1. A lemondás minden foglalásnál ott van a Foglalásaim oldalon, megerősítő lépéssel.
2. Ha 12 órával az óra előtt mondom le, a foglalás egyszerűen törlődik.
3. 12 órán belül, a megerősítés előtt jelenjen meg: „5 $-os késői lemondási díj vonatkozik rád”, és a díjat rögzítsd a foglaláson.
4. Ha az órára várólista van, az első személy kapja meg a helyet és egy e-mailt.
5. Telefon-szélességű képernyőn is működik. Hatókörön kívül: visszatérítések, munkatárs által végzett lemondás tagok nevében. Építsd meg, majd az előnézetben ellenőrizd minden kritériumot, és mondd meg, melyik teljesül.

Kérheted azt is, hogy az AI készítsen történeteket egy nyers ötletből, majd te szerkeszd őket:

Itt az alkalmazásötletem: [két-három mondat]. Írd meg az első verzió felhasználói történeteit, felhasználótípusonként csoportosítva, mindegyikhez 3–5 Adott/Amikor/Akkor elfogadási kritériummal. Jelöld, melyek szükségesek az indításhoz, és melyek várhatnak.

Mindig olvasd el és szerkeszd át az eredményt. Az AI nem ismeri a felhasználóidat; te igen.

Az elfogadási kritériumok a teszttervedként is szolgálnak. Amikor a történet megépült, menj végig egyenként minden kritériumon. A hogyan teszteld az alkalmazásod indítás előtt útmutató erre épít.

Hol illeszkednek a felhasználói történetek más dokumentumok közé

• A termékkövetelmény-dokumentum az egész terméket írja le: a problémát, a felhasználókat, a hatókört. A felhasználói történetek a benne lévő részletes elemek. Lásd: hogyan írjunk PRD-t AI-val.
• A hibajelentés egy olyan hibát ír le, amely egy már megépített történethez képest nem működik. Lásd: hogyan írjunk jó hibajelentést.
• Egy MVP a legkisebb történethalmaz, amely megadja a fő értéket. Lásd: mi az MVP.

Gyakori hibák

• „Mint felhasználó…” Túl általános. Nevezd meg a konkrét felhasználótípust.
• A „hogy” kihagyása. Ok nélkül nem lehet értelmes kompromisszumokat kötni.
• A szükséglet helyett a megoldás írása. Az „legördülő menüt szeretnék” egy tervet rögzít, mielőtt bárki átgondolta volna.
• Nem tesztelhető kritériumok. Az „egyszerű”, „gyors” és „intuitív” kívánságok, nem kritériumok.
• Valójában epikus történetek. A „fiókom kezelése” tíz történet.
• Minden történet előre megírása. A következő néhányat írd meg részletesen; a többit tartsd egysoros vázlatként, amíg oda nem érsz.

Történetek a Mythexben

A Mythexben a Plan mód jó hely arra, hogy ötletből történeteket készíts: az ügynök a szerkesztés előtt megbeszéli a megközelítést. Amikor egy történet kész, válts Build módra, és illeszd be, üzenetenként egy történetet. Minden után a /test végigkattinthat az előnézeten és ellenőrizheti a folyamatot, és ha egy válasz rossz irányba ment, a Visszaállítás erre a pontra gombbal visszaforgathatod. Lásd: hatékony promptok a dokumentációban, és az AI-alkalmazásépítőknek szóló promptírás útmutatónkat.

Felhasználói történet ellenőrzőlista

• Konkrét felhasználótípust nevez meg
• Szükségletet ír le, nem tervet
• Valódi „hogy” okot tartalmaz
• Három-hat tesztelhető elfogadási kritériuma van
• Legalább egy szélsőséges esetet vagy hibát lefed
• Megnevezi, mi van a hatókörön kívül
• Elég kicsi ahhoz, hogy egy menetben meg lehessen építeni és tesztelni
• A kritériumok építés után, egyenként ellenőrizve

Kérdések