Kā rakstīt lietotāju stāstus (ar piemēriem un pieņemšanas kritērijiem)

Lietotāja stāsts ir īss funkcijas apraksts no lietotāja skatpunkta: „Kā [lietotāja tips] es vēlos [mērķi], lai [iemesls].” Zem tā rakstāt pieņemšanas kritērijus — dažus konkrētus nosacījumus, kuriem jābūt izpildītiem, lai stāsts tiktu uzskatīts par pabeigtu. Turiet katru stāstu pietiekami mazu, lai to varētu uzbūvēt un pārbaudīt vienā piegājienā, un rakstiet kritērijus tā, lai ikviens varētu tos pārbaudīt.

Lietotāju stāstus populārus padarīja agile programmatūras komandas, bet tie ir tikpat noderīgi, ja veidojat pats ar MI lietotņu veidotāju. Labs stāsts ir laba uzvedne.

Formāts

Lietotāja stāstam ir trīs daļas:

Kā [kas], es vēlos [ko] lai [kāpēc].

• Kas ir konkrēts lietotāja tips: pirmoreizes apmeklētājs, maksājošs dalībnieks, klīnikas reģistratūras darbinieks, administrators. Ne „lietotājs”.
• Ko viņi vēlas darīt ar saviem vārdiem. Ne to, kā darbojas ekrāns.
• Kāpēc ir rezultāts, kas viņiem rūp. Tā ir daļa, ko cilvēki izlaiž, un tieši tā novērš nepareizas lietas būvēšanu.

Piemērs:

Kā sporta zāles dalībnieks, es vēlos atcelt nodarbības rezervāciju no sava tālruņa, lai kāds no gaidītāju saraksta varētu paņemt manu vietu un man netiktu piemērota maksa par neierašanos.

Iemesls pastāsta divas lietas, ko „ko” nepateica: tam jādarbojas telefonā, un iesaistīti ir gaidītāju saraksts un maksas noteikumi.

Pieņemšanas kritēriji

Stāsts saka, ko vēlas. Pieņemšanas kritēriji saka, kad tas ir pabeigts. Tiem jābūt pietiekami konkrētiem, lai divi cilvēki vienoties, vai katrs kritērijs ir izpildīts.

Bieži tos raksta kā Dots / Kad / Tad:

• Dots sākuma stāvoklis
• Kad lietotājs kaut ko dara
• Tad šis ir rezultāts

Sporta zāles rezervācijas stāstam:

1. Dots, ka man ir rezervācija, kas ir vairāk nekā 12 stundas tālu, kad es pieskaros Atcelt un apstiprinu, tad rezervācija tiek noņemta un es redzu „Rezervācija atcelta”.
2. Dots, ka atcelju rezervāciju un nodarbībai ir gaidītāju saraksts, kad atcelšana tiek saglabāta, tad pirmais gaidītājs saņem vietu un e-pastu.
3. Dots rezervācija, kas ir mazāk nekā 12 stundas tālu, kad es pieskaros Atcelt, tad pirms apstiprināšanas redzu, ka tiek piemērota vēlas atcelšanas maksa.
4. Dots, ka esmu ekrānā telefona platumā, tad poga Atcelt ir redzama bez horizontālas ritināšanas.

Vienkāršs kontrolsaraksts arī darbojas, ja katrs vienums ir pārbaudāms. „Atcelšana ir viegla” nav pārbaudāms. „Atcelšanai no rezervāciju saraksta vajag ne vairāk kā divus pieskārienus” ir.

Soli pa solim: labs stāsts

1. solis: sāciet no reāla lietotāja un reālas problēmas

Izvēlieties vienu lietotāja tipu un to, ar ko viņi šodien cīnās. Ja esat veicis klientu intervijas, izmantojiet viņu vārdus. „Es vienmēr aizmirstu atcelt un man tiek piemērota maksa” ir labāks sākumpunkts nekā „pievienot atcelšanas funkciju”.

2. solis: uzrakstiet vienas rindas stāstu

Aizpildiet sagatavi. Ja nevarat uzrakstīt pārliecinošu „lai”, pajautājiet, vai funkcija vispār ir vajadzīga.

3. solis: pievienojiet trīs līdz sešus pieņemšanas kritērijus

Aptveriet vispirms galveno veiksmīgo gadījumu, pēc tam svarīgos variantus: citu lomu, tukšu stāvokli, ierobežojumu, kļūdu. Ja rakstāt vairāk nekā sešus, stāsts droši vien ir pārāk liels.

4. solis: atzīmējiet, kas ir ārpus darbības apjoma

Viena rinda ietaupa daudz atpakaļ un uz priekšu: „Ārpus darbības apjoma: atmaksas par maksas nodarbībām; administratori, kas atceļ dalībnieku vārdā.” Tas neļauj stāstam augt, kamēr to būvējat.

5. solis: pārbaudiet to pret INVEST

INVEST ir izplatīts kontrolsaraksts labiem stāstiem. Stāstam jābūt:

Nav jāvērtē katrs stāsts. Tas ir visnoderīgākais, kad stāsts šķiet nepareizs un vēlaties zināt, kāpēc.

Labi un slikti piemēri

Kā sadalīt pārāk lielu stāstu

Lieli stāsti ir vieta, kur projekti iestrēgst. Biežākie veidi, kā sadalīt:

• Pēc lietotāja lomas. Dalībnieki atceļ savas rezervācijas; personāls atceļ jebkuras.
• Pēc soļa plūsmā. Pārlūkot nodarbības; rezervēt nodarbību; saņemt atgādinājumu.
• Vispirms vienkāršais gadījums. Atcelt bezmaksas nodarbību tagad; maksas un atmaksas apstrādāt vēlākā stāstā.
• Pēc datu variācijas. Vispirms atbalstīt vienu atrašanās vietu, vēlāk vairākas.
• Veiksmīgais ceļš, pēc tam kļūdas. Vispirms uzbūvēt, lai tas strādā, pēc tam pievienot apstrādi pilnām nodarbībām, beigušām abonementa vienībām un tamlīdzīgi.

Katram gabalam joprojām jābūt kaut kam, ko lietotājs varētu izmantot un pamanīt.

Lietotāju stāstu izmantošana kā uzvednes

Lietotāja stāsts ar pieņemšanas kritērijiem ir ļoti tuvu labai uzvednei MI lietotņu veidotājam. Tas sniedz MI kas, ko, kāpēc un definīciju, kad viss pabeigts. Sūtiet vienu stāstu vienā ziņojumā:

Kā sporta zāles dalībnieks, es vēlos atcelt nodarbības rezervāciju no sava tālruņa, lai kāds no gaidītāju saraksta varētu paņemt manu vietu. Pieņemšanas kritēriji:

1. Atcelt ir pie katras rezervācijas sadaļā Manas rezervācijas, ar apstiprinājuma soli.
2. Atceļot vairāk nekā 12 stundas pirms nodarbības, rezervācija vienkārši tiek noņemta.
3. Mazāk nekā 12 stundas pirms, pirms apstiprināšanas rādīt „Piemērojama vēlas atcelšanas maksa 5 EUR” un ierakstīt maksu rezervācijā.
4. Ja nodarbībai ir gaidītāju saraksts, pirmais saņem vietu un e-pastu.
5. Darbojas ekrānā telefona platumā. Ārpus darbības apjoma: atmaksas, personāls, kas atceļ dalībniekiem. Uzbūvē to, pēc tam priekšskatījumā pārbaudi katru kritēriju un pasaki, kuri izpildās.

Varat arī lūgt MI izstrādāt stāstus no aptuvenas idejas, pēc tam paši tos rediģēt:

Šeit ir mana lietotnes ideja: [divi vai trīs teikumi]. Uzrakstiet lietotāju stāstus pirmajai versijai, grupēti pēc lietotāja tipa, katram ar 3 līdz 5 Dots / Kad / Tad pieņemšanas kritērijiem. Atzīmējiet, kuri ir būtiski palaišanai un kuri var pagaidīt.

Vienmēr izlasiet un rediģējiet rezultātu. MI nezina jūsu lietotājus; jūs zināt.

Pieņemšanas kritēriji kalpo arī kā jūsu testu plāns. Kad stāsts ir uzbūvēts, izejiet cauri katram kritērijam pats. Mūsu rokasgrāmata par lietotnes testēšanu pirms palaišanas balstās uz šī.

Kur lietotāju stāsti ietilpst ar citiem dokumentiem

• Produkta prasību dokuments apraksta visu produktu: problēmu, lietotājus, darbības apjomu. Lietotāju stāsti ir detalizētās daļas tajā. Skatiet kā rakstīt PRD ar MI.
• Kļūdas ziņojums apraksta kaut ko bojātu salīdzinājumā ar stāstu, kas jau ir uzbūvēts. Skatiet kā uzrakstīt labu kļūdas ziņojumu.
• MVP ir mazākā stāstu kopa, kas nodrošina galveno vērtību. Skatiet kas ir MVP.

Biežākās kļūdas

• „Kā lietotājs…” Pārāk neskaidri. Nosauciet konkrētu lietotāja tipu.
• „Lai” izlaišana. Bez iemesla nevar pieņemt saprātīgus kompromisus.
• Risinājuma rakstīšana vajadzības vietā. „Es vēlos nolaižamo sarakstu” nosaka dizainu, pirms kāds to ir pārdomājis.
• Kritēriji, ko nevar pārbaudīt. „Viegli”, „ātri” un „intuitīvi” ir vēlējumi, nevis kritēriji.
• Stāsti, kas patiesībā ir episki. „Pārvaldīt savu kontu” ir desmit stāsti.
• Visu stāstu rakstīšana iepriekš. Uzrakstiet nākamos dažus detalizēti; pārējos turiet kā vienas rindas, līdz tiem nonākat.

Stāsti Mythex

Mythex režīms Plāns ir labā vieta, kur pārvērst ideju stāstos: aģents pirms jebkuras rediģēšanas apspriež pieeju. Kad stāsts ir gatavs, pārslēdzieties uz Veidot un ielīmējiet to, pa vienam stāstam vienā ziņojumā. Pēc katra var /test noklikšķināt cauri priekšskatījumam un pārbaudīt plūsmu, un jebkuru atbildi var atgriezt ar Atgriezties šajā punktā, ja tā aizgāja nepareizi. Skatiet efektīvas uzvednes dokumentācijā un mūsu rokasgrāmatu par uzvedņu rakstīšanu MI lietotņu veidotājiem.

Lietotāju stāstu kontrolsaraksts

• Nosauc konkrētu lietotāja tipu
• Apraksta vajadzību, nevis dizainu
• Ietver īstu „lai” iemeslu
• Ir trīs līdz seši pārbaudāmi pieņemšanas kritēriji
• Aptver vismaz vienu malas gadījumu vai kļūdu
• Norāda, kas ir ārpus darbības apjoma
• Pietiekami mazs, lai uzbūvētu un pārbaudītu vienā piegājienā
• Kritēriji pārbaudīti pēc būvēšanas, pa vienam

Jautājumi