Un principiu central al proceselor moderne de dezvoltare este dezvoltarea agilă . Această metodologie de dezvoltare subliniază utilizarea poveștilor de mici dimensiuni ale utilizatorilor pentru a defini ceea ce face un sistem din perspectiva utilizatorului, nu una tehnică. Unui utilizator îi pasă dacă un produs este rapid, ușor de utilizat și își rezolvă problema. Nu le pasă dacă urmează o arhitectură pe 3 niveluri, dacă are Mongo DB sau dacă folosește Rails sau Asp.net.
Storyboard That oferă o platformă ideală pentru a crea povești agile ale utilizatorilor și a declanșa conversații într-un format mult mai puțin impozabil decât un perete de text.
În contextul poveștilor utilizatorilor, o „epopee” este pur și simplu o poveste foarte largă care va fi împărțită mai târziu în multe povești specifice utilizatorilor. Începând cu o epopee aliniază toată lumea cu o singură viziune la nivel înalt. Povestea epică ancorează un proiect de sus în jos și, dacă nu are sens să construiești o epopee, munca de sprijin va fi, de asemenea, o risipă de efort.
În această poveste, este foarte clar care este viziunea pe termen lung și cum ar trebui să arate succesul. O poveste epică bună ar trebui să includă:
Mai ales atunci când proiectați software, este important să aveți o viziune bună despre cum vor fi utilizatorii. Nu fiecare utilizator se va potrivi cu această viziune cu precizie și pot exista mai multe categorii de utilizatori, dar aceste viziuni discrete necesită articulare. Gândindu-vă la utilizatori, mai întâi protejează împotriva ingineriei excesive și a excesului de complicații, împiedicând un nou produs să aibă ceva pentru toată lumea și să nu fie util nimănui.
Odată ce a fost stabilită o epopee și utilizatorii au fost definiți, se pot construi povești mai mici și mai specifice despre anumite experiențe ale utilizatorilor. Poveștile de mai jos descompun cele prezentate mai sus în două narațiuni: căutarea unei comenzi și reordonarea unui produs.
Aceste narațiuni nu conțin informații tehnice; utilizatorilor nu le pasă cum se obțin rezultatele, atâta timp cât îndeplinește sarcinile dorite. În mod similar, UX este descris generic, pentru a evita sufocarea inovației sau forțarea unei căi. În general, poveștile ar trebui să fie:
Aceste povești ar trebui să invite conversații și întrebări, cum ar fi:
Este perfect rezonabil să creezi multe povești; de fapt, ar trebui încurajat. Unele dintre aceste povești nu vor fi folosite niciodată, dar este important să vedem calea pe care au stabilit-o. Această colecție de povești va elimina cerințele suplimentare și va influența testarea.
Poveștile ar trebui să provoace și să informeze discuțiile despre modul în care software-ul va fi testat și ce reguli de afaceri trebuie definite în mod explicit. De exemplu:
