Så skriver du användarberättelser (med exempel och acceptanskriterier)

En användarberättelse är en kort beskrivning av en funktion ur användarens perspektiv: ”Som [typ av användare] vill jag [mål] så att [anledning].” Under den skriver du acceptanskriterier, några specifika villkor som måste vara uppfyllda för att berättelsen ska räknas som klar. Håll varje berättelse tillräckligt liten för att byggas och testas på en gång, och skriv kriterierna så att vem som helst kan kontrollera dem.

Användarberättelser blev populära i agila mjukvaruteam, men de är lika användbara när du bygger på egen hand med ett AI-verktyg för appar. En bra berättelse är en bra prompt.

Formatet

En användarberättelse har tre delar:

Som [vem], vill jag [vad] så att [varför].

• Vem är en specifik typ av användare: en förstagångsbesökare, en betalande medlem, en receptionist på en klinik, en administratör. Inte ”användaren”.
• Vad är det de vill göra, med egna ord. Inte hur skärmen fungerar.
• Varför är resultatet de bryr sig om. Det är den del folk hoppar över, och den som hindrar dig från att bygga fel sak.

Exempel:

Som gymmedlem vill jag kunna avboka ett pass från min telefon så att någon på väntelistan kan ta min plats och jag inte debiteras en avgift för utebliven närvaro.

”Varför” berättar två saker som ”vad” inte gjorde: den måste fungera i mobilen, och väntelistan och avgiftsreglerna är inblandade.

Acceptanskriterier

En berättelse säger vad som önskas. Acceptanskriterierna säger när det är klart. De bör vara tillräckligt specifika för att två personer ska kunna komma överens om huruvida varje kriterium är uppfyllt.

Ett vanligt sätt att skriva dem är Givet / När / Då:

• Givet en utgångssituation
• När användaren gör något
• Då är detta resultatet

För gymbokningsberättelsen:

1. Givet att jag har en bokning mer än 12 timmar bort, när jag trycker på Avboka och bekräftar, då tas bokningen bort och jag ser ”Bokningen avbokad”.
2. Givet att jag avbokar en bokning och passet har en väntelista, när avbokningen sparas, då får den första personen på väntelistan platsen och ett e-postmeddelande.
3. Givet en bokning mindre än 12 timmar bort, när jag trycker på Avboka, då ser jag att en avgift för sen avbokning gäller innan jag bekräftar.
4. Givet att jag är på en skärm i mobilbredd, då syns Avboka-knappen utan att behöva scrolla åt sidan.

En vanlig checklista fungerar också, så länge varje punkt går att testa. ”Att avboka är enkelt” är inte testbart. ”Avbokning tar högst två tryck från bokningslistan” är det.

Steg för steg: skriva en bra berättelse

Steg 1: Börja från en verklig användare och ett verkligt problem

Välj en typ av användare och något de kämpar med idag. Om du har gjort kundintervjuer, använd deras ord. ”Jag glömmer alltid att avboka och blir debiterad” är en bättre utgångspunkt än ”lägg till avbokningsfunktion”.

Steg 2: Skriv berättelsen på en rad

Fyll i mallen. Om du inte kan skriva ett övertygande ”så att”, fråga dig om funktionen behövs alls.

Steg 3: Lägg till tre till sex acceptanskriterier

Täck in huvudfallet först, sedan de viktiga variationerna: en annan roll, ett tomt läge, en gräns, ett fel. Om du skriver fler än sex är berättelsen sannolikt för stor.

Steg 4: Notera vad som ligger utanför omfattningen

En rad sparar mycket fram och tillbaka: ”Utanför omfattningen: återbetalningar för betalda pass; administratörer som avbokar åt medlemmar.” Det hindrar berättelsen från att växa medan du bygger den.

Steg 5: Kontrollera den mot INVEST

INVEST är en vanlig checklista för bra berättelser. En berättelse bör vara:

Du behöver inte poängsätta varje berättelse. Det är mest användbart när en berättelse känns fel och du vill veta varför.

Bra och dåliga exempel

Så delar du upp en berättelse som är för stor

Stora berättelser är där projekt stannar av. Vanliga sätt att dela upp:

• Efter användarroll. Medlemmar avbokar sina egna bokningar; personal avbokar vems som helst.
• Efter steg i flödet. Bläddra bland pass; boka ett pass; få en påminnelse.
• Enklaste fallet först. Avboka ett gratis pass nu; hantera avgifter och återbetalningar i en senare berättelse.
• Efter datavariation. Stöd en plats först, flera senare.
• Lyckad väg först, sedan fel. Bygg den så att den fungerar, lägg sedan till hantering för fulla pass, utgångna kort och så vidare.

Varje del ska fortfarande vara något en användare kan använda och märka.

Använda användarberättelser som prompter

En användarberättelse med acceptanskriterier ligger mycket nära en bra prompt för ett AI-verktyg för appar. Den ger AI:n vem, vad, varför och en definition av klart. Skicka en berättelse per meddelande:

Som gymmedlem vill jag kunna avboka ett pass från min telefon så att någon på väntelistan kan ta min plats. Acceptanskriterier:

1. Avboka finns på varje bokning under Mina bokningar, med ett bekräftelsesteg.
2. Avbokning mer än 12 timmar före passet tar bara bort bokningen.
3. Mindre än 12 timmar före: visa ”En avgift för sen avbokning på $5 gäller” innan bekräftelse, och spara avgiften på bokningen.
4. Om passet har en väntelista får den första personen platsen och ett e-postmeddelande.
5. Fungerar på en skärm i mobilbredd. Utanför omfattningen: återbetalningar, personal som avbokar åt medlemmar. Bygg det här, kontrollera sedan varje kriterium i förhandsvisningen och säg vilka som går igenom.

Du kan också be AI:n utarbeta berättelser från en rå idé och sedan redigera dem själv:

Här är min appidé: [två eller tre meningar]. Skriv användarberättelserna för en första version, grupperade efter typ av användare, var och en med 3 till 5 Givet/När/Då-acceptanskriterier. Markera vilka som är nödvändiga för lansering och vilka som kan vänta.

Läs och redigera alltid resultatet. AI:n känner inte dina användare; du gör det.

Acceptanskriterierna fungerar också som din testplan. När berättelsen är byggd går du igenom varje kriterium själv. Vår guide om så testar du din app före lansering bygger vidare på det här.

Var användarberättelser passar in med andra dokument

• Ett produktkravsdokument beskriver hela produkten: problemet, användarna, omfattningen. Användarberättelserna är de detaljerade delarna inuti det. Se så skriver du en PRD med AI.
• En felrapport beskriver något som är trasigt mot en berättelse som redan byggts. Se så skriver du en bra felrapport.
• En MVP är den minsta uppsättningen berättelser som levererar kärnvärdet. Se vad är en MVP.

Vanliga misstag

• ”Som en användare …” För vagt. Namnge den faktiska typen av användare.
• Att hoppa över ”så att”. Utan anledningen kan du inte göra vettiga avvägningar.
• Att skriva lösningen i stället för behovet. ”Jag vill ha en rullgardinsmeny” låser fast en design innan någon har tänkt igenom den.
• Kriterier som inte går att testa. ”Enkelt”, ”snabbt” och ”intuitivt” är önskemål, inte kriterier.
• Berättelser som egentligen är epics. ”Hantera mitt konto” är tio berättelser.
• Att skriva alla berättelser i förväg. Skriv de närmaste några i detalj; behåll resten som korta rader tills du kommer till dem.

Berättelser i Mythex

I Mythex är läget Plan en bra plats att göra en idé till berättelser: agenten diskuterar tillvägagångssättet innan den redigerar något. När en berättelse är klar, byt till Build och klistra in den, en berättelse per meddelande. Efter varje kan du använda /test för att klicka igenom förhandsvisningen och kontrollera flödet, och du kan rulla tillbaka vilket svar som helst med Återställ till denna punkt om det gick fel. Se effektiva prompter i dokumentationen och vår guide om hur du skriver prompter för AI-appbyggare.

Checklista för användarberättelser

• Namnger en specifik typ av användare
• Beskriver ett behov, inte en design
• Innehåller en verklig ”så att”-anledning
• Har tre till sex testbara acceptanskriterier
• Täcker minst ett kantfall eller fel
• Anger vad som ligger utanför omfattningen
• Tillräckligt liten för att byggas och testas på en gång
• Kriterierna kontrollerade efter bygget, ett i taget

Frågor