1 Utilizatorii sunt pe primul loc

după cum sugerează și numele, o poveste de utilizator descrie modul în care un client sau un utilizator utilizează produsul; este spus din perspectiva utilizatorului. În plus, poveștile utilizatorilor sunt deosebit de utile pentru a capta o anumită funcționalitate, cum ar fi Căutarea unui produs sau efectuarea unei rezervări. Imaginea de mai jos ilustrează relația dintre utilizator, poveste și funcționalitatea produsului (simbolizată de cerc).,dacă nu știți cine sunt utilizatorii și clienții și de ce ar dori să utilizeze produsul, atunci nu ar trebui să scrieți povești despre utilizatori. Efectuați mai întâi cercetarea necesară a utilizatorilor, de exemplu, observând și intervievând utilizatorii. În caz contrar, vă asumați riscul de a scrie povești speculative care se bazează pe credințe și idei—dar nu pe date și dovezi empirice.

2 Utilizați Personas pentru a descoperi poveștile potrivite

o tehnică excelentă pentru a vă surprinde informațiile despre utilizatori și clienți este colaborarea cu personas., Personas sunt personaje fictive care se bazează pe cunoașterea de primă mână a grupului țintă. Ele constau, de obicei, dintr-un nume și o imagine; Caracteristici, comportamente și atitudini relevante; și un scop. Scopul este beneficiul pe care persoana dorește să-l atingă sau problema pe care personajul dorește să o vadă rezolvată prin utilizarea produsului.dar există mai multe: obiectivele persona vă ajută să descoperiți poveștile potrivite: întrebați-vă ce funcționalitate ar trebui să ofere produsul pentru a îndeplini obiectivele personas, așa cum explic în postarea mea de la Personas la poveștile utilizatorilor., Puteți descărca un șablon la îndemână pentru a descrie personas dvs. de la romanpichler.com/tools/persona-template.

3 creați povestiri în colaborare

poveștile utilizatorilor sunt concepute ca o tehnică ușoară care vă permite să vă mișcați rapid. Ele nu sunt o specificație, ci un instrument de colaborare. Poveștile nu ar trebui să fie înmânate niciodată unei echipe de dezvoltare. În schimb, acestea ar trebui să fie încorporate într-o conversație: proprietarul produsului și echipa ar trebui să discute poveștile împreună. Acest lucru vă permite să capturați numai cantitatea minimă de informații, să reduceți cheltuielile generale și să accelerați livrarea.,

puteți să continuați această abordare și să scrieți povestiri în colaborare ca parte a procesului de îngrijire a produselor restante. Acest lucru valorifică creativitatea și cunoștințele echipei și are ca rezultat povești mai bune pentru utilizatori.dacă nu puteți implica echipa de dezvoltare în activitatea de poveste a utilizatorului, atunci ar trebui să luați în considerare utilizarea unei alte tehnici mai formale pentru a capta funcționalitatea produsului, cum ar fi cazurile de utilizare.

4 Păstrați-vă poveștile Simple și Concise

scrieți-vă poveștile astfel încât să fie ușor de înțeles. Păstrați-le simple și concise., Evitați termenii confuzi și ambigui și utilizați vocea activă. Concentrați-vă pe ceea ce este important și lăsați restul. Șablonul de mai jos pune utilizatorul sau clientul modelat ca persona în poveste și face beneficiul său explicit. Ea se bazează pe de șablon popular Rachel Davies, dar am înlocuit rolul de utilizator cu numele persona pentru a conecta povestea cu persona relevante.

<persona>
vreau <ce?>
astfel încât <de ce?>.,utilizați șablonul atunci când este util, dar nu vă simțiți obligați să îl aplicați întotdeauna. Experimentează diferite moduri de a-ți scrie poveștile pentru a înțelege ce funcționează cel mai bine pentru tine și echipa ta.

5 Începeți cu epopee

un epic este o poveste mare, schițată, cu granulație grosieră. De obicei, acesta este împărțit în mai multe povești ale utilizatorilor de—a lungul timpului-folosind feedback-ul utilizatorului cu privire la prototipurile timpurii și creșterile de produse. Vă puteți gândi la ea ca un titlu și un substituent pentru povești mai detaliate.

începând cu epics vă permite să schițați funcționalitatea produsului fără a vă angaja la detalii., Acest lucru este util în special pentru descrierea noilor produse și caracteristici: vă permite să capturați domeniul de aplicare dur și vă oferă timp pentru a afla mai multe despre cum să abordați cel mai bine nevoile utilizatorilor.de asemenea, reduce timpul și efortul necesar pentru integrarea noilor perspective. Dacă aveți multe povești detaliate în lista de produse, atunci este adesea dificil și consumator de timp să corelați feedback-ul cu elementele corespunzătoare și prezintă riscul introducerii inconsecvențelor.,

6 rafinați poveștile până când sunt gata

împărțiți epopeele în povești mai mici, detaliate, până când sunt gata: clare, fezabile și testabile. Toți membrii echipei de dezvoltare ar trebui să aibă o înțelegere comună a sensului poveștii; povestea nu ar trebui să fie prea mare și să se încadreze confortabil într-un sprint; și trebuie să existe o modalitate eficientă de a determina dacă povestea este terminată.

7 Adăugați criterii de acceptare

pe măsură ce împărțiți epopee în povești mai mici, nu uitați să adăugați criterii de acceptare., Criteriile de acceptare completează narațiunea: vă permit să descrieți condițiile care trebuie îndeplinite pentru ca povestea să fie făcută. Criteriile îmbogățesc povestea, o fac testabilă și se asigură că povestea poate fi demoată sau lansată utilizatorilor și altor părți interesate. Ca regulă generală, îmi place să folosesc trei până la cinci criterii de acceptare pentru povești detaliate.

8 utilizați carduri de hârtie

poveștile utilizatorilor au apărut în Extreme Programming (XP), iar literatura timpurie XP vorbește despre cărți de poveste, mai degrabă decât povești ale utilizatorilor., Există un motiv simplu: poveștile utilizatorilor au fost capturate pe carduri de hârtie. Această abordare oferă trei beneficii: în primul rând, cardurile de hârtie sunt ieftine și ușor de utilizat. În al doilea rând, ele facilitează colaborarea: fiecare poate să ia o carte și să noteze o idee. În al treilea rând, cărțile pot fi ușor grupate pe masă sau pe perete pentru a verifica coerența și exhaustivitatea și pentru a vizualiza dependențele. Chiar dacă poveștile dvs. sunt stocate electronic, merită să folosiți carduri de hârtie atunci când scrieți povești noi.

9 păstrați poveștile vizibile și accesibile

poveștile doresc să comunice informații., Prin urmare, nu le ascunde pe o unitate de rețea, jungla intranet corporativă sau un instrument licențiat. Faceți-le vizibile, de exemplu, așezându-le pe perete. Acest lucru favorizează colaborarea, creează transparență și face evident atunci când adăugați prea multe povești prea repede, deoarece veți începe să rămâneți fără spațiu pe perete. Un instrument la îndemână pentru a descoperi, vizualiza și gestiona poveștile dvs. este pânza mea de produse prezentată mai jos.

10 nu vă bazați exclusiv pe poveștile utilizatorilor

crearea unei experiențe extraordinare a utilizatorilor (UX) necesită mai mult decât povești ale utilizatorilor., Poveștile utilizatorilor sunt utile pentru a capta funcționalitatea produsului, dar nu sunt potrivite pentru a descrie călătoriile utilizatorilor și designul vizual. Prin urmare, completați poveștile utilizatorilor cu alte tehnici, cum ar fi, hărți de povești, diagrame de flux de lucru, storyboards, schițe și machete.în plus, poveștile utilizatorilor nu sunt cerințe tehnice bune de captare. Dacă trebuie să comunicați ce ar trebui să facă un element arhitectural precum o componentă sau un serviciu, atunci scrieți povestiri tehnice sau—care este preferința mea—folosiți un limbaj de modelare precum UML.,

în cele din urmă, scrierea poveștilor utilizatorilor merită atunci când dezvoltați software care este probabil să fie reutilizat. Dar dacă doriți să creați rapid un prototip sau o machetă pentru a valida o idee, atunci scrierea poveștilor poate să nu fie necesară. Amintiți—vă: poveștile utilizatorilor nu se referă la cerințele de documentare; ei doresc să vă permită să vă mișcați rapid și să dezvoltați software cât mai repede posibil-să nu impuneți nicio regie.