Kuinka kirjoittaa parempia käyttäjätarinoita kurkkujen avulla (malli mukana)

Käyttäjätarinat ovat ketterä tekniikka tuotteen toiminnallisuuden ja vaatimusten määrittelyyn. Niissä keskitytään kertomaan tarina käyttäjän tekemästä toimenpiteestä ja siitä, mitä odotetaan, kun se onnistuu. Käyttäjätarinoiden käsite on laajalti käytetty, mutta hyvien tarinoiden kertominen voi olla melko vaikeaa.

Käyttäjätarinat ovat kuitenkin saaneet viime vuosina osumaa, sillä ne ovat hieman liian yksinkertaistettuja ja niistä puuttuu empatiaa käyttäjää kohtaan.

Hyviä uutisia – on olemassa parempi tapa! Niiden nimi on kurkku, mutta toisin kuin suolakurkku, ne eivät ole täällä hapantaakseen elämääsi. (Paitsi jos olet suolakurkun ystävä, oletan!) 🥒

TL;DR

Jos sinulla on vähän kiire, tässä on TL;DR (vaikka kannustan sinua jatkamaan lukemista, jotta pääset käsiksi malleihin!)

• Käyttäjätarinat keskittyvät käyttäjään, eivät tuotteeseen.
• Hahmottele persoonasi kontekstin lisäämiseksi.
• Lisää tarinoihisi empatiaa, jotta ymmärrät tekoja ja motiiveja.
• Kurkut: parempi tapa kirjoittaa tarinoita.
• Käytä kurkkuja keskittyäksesi tuloksiin, ei vain tuotoksiin.

Mitä ovat käyttäjätarinat?

Käyttäjätarinat ovat lyhyitä, yksinkertaisia kuvauksia tiimisi keksimästä ratkaisusta, joka kerrotaan vuorovaikutusta toteuttavan henkilön näkökulmasta. Ne ovat osa laajempaa eeposta, jossa kuvataan varsinainen ratkaistava ongelma ja se, miksi sitä ollaan ratkaisemassa.

Käyttäjä on tärkeä sana tässä yhteydessä, eli käyttäjätarinassa keskitytään käyttäjään, ei tuotteeseen.

Käyttäjätarinassa keskitytään yleensä kolmeen osa-alueeseen:

• Koska(kuka)
• Haluan(mitä)
• Niin että(miksi)

Tätä seuraa yleensä hyväksymiskriteerit, joissa määritellään, miten tiedät, onko vuorovaikutus onnistunut.

Kuka: Henkilökuvien käyttäminen käyttäjätarinoiden hahmottamiseen

Jos et ole vielä määritellyt tai ymmärtänyt käyttäjiäsi, sinun ei todellakaan pitäisi kirjoittaa käyttäjätarinoita. Aloita ensin selvittämisellä, kartoita asiakkaan matka ja luo asianmukaiset käyttäjäpersoonat, jotka auttavat sinua määrittelemään tarinat tarkemmin.

Persona voi auttaa sinua ymmärtämään ja antamaan kontekstin käyttäjätarinan “kenelle” – toisin sanoen, kuka suorittaa tämän vuorovaikutuksen.

Tämä on tärkeää, koska sinulla on väistämättä erilaisia asiakassegmenttejä, rooleja ja käyttöoikeuksia, joten vuorovaikutuksen määrittely näiden erityyppisten käyttäjien tarpeisiin on tärkeää.

Mikä: Käyttäjätarinoiden vuorovaikutus

Käyttäjätarinan “mitä” keskittyy itse vuorovaikutukseen. Hankalinta tässä on varmistaa, että “mitä” keskittyy siihen, mitä käyttäjän on tehtävä, eikä siihen, mitä käyttäjä haluaa tehdä, ja tässä kohtaa tyypillinen tarinamalli hajoaa hieman.

Jotta itse tarinaan saataisiin lisää empatiaa, on tärkeää korostaa, miltä käyttäjästä voi tuntua, kun hän on vuorovaikutuksessa tietyn toiminnon kanssa.

Kukaan ei esimerkiksi halua syöttää monimutkaista salasanaa, jossa on isoja kirjaimia, erikoismerkkejä ja vähimmäispituus – mutta tietää, että pitäisi. Tässä tapauksessa se on jotain, mitä käyttäjän on tehtävä.

Miksi: Käyttäjätarinan toiminnan syy

Käyttäjätarinan mallin kolmas osa on “miksi” – eli miksi käyttäjä haluaa (tai hänen on) suoritettava tietty toiminto.

Palataan edelliseen esimerkkiin salasanojen syöttämisestä:

Ylläpitäjänä minun on luotava monimutkainen salasana, jotta tilini on turvallinen.

Ymmärrämme nyt, kuka, mitä ja miksi – mutta tässä on eräs ongelma. Tästä puuttuu edelleen empatia ja asiayhteys, sillä olkaamme rehellisiä, kukaan ei halua monimutkaisten salasanojen olevan vaatimuksena, mutta me kaikki haluamme turvallisia tilejä.

Tätä testatessaan laadunvarmistusryhmä tyytyi vain tarkistamaan, onko salasana turvallinen, eikä tarkistamaan, onko prosessi turhauttava käyttäjälle.

Syötä Gherkin-käyttäjätarinan malli

Kurkkujen avulla voidaan lisätä käyttäjätarinoita ja antaa täydellinen skenaario, joka auttaa kehittäjiä ja testaajia ymmärtämään sekä tietyn käyttäjän vuorovaikutuksen lopputuloksen että tuotoksen.

1. Scenario – kuvaamasi käyttäytyminen
2. Given – skenaarion alkutilanne
3. When – käyttäjän suorittama tietty toimenpide
4. Then – testattavissa oleva lopputulos, joka yleensä aiheutuu toimenpiteestä When
5. And – tämä jatkaa tarvittaessa mitä tahansa kolmesta muusta operaatiosta.

Otetaan aiemmin kuvattu salasanaskenaario:

1. Kun asetat salasanan (Scenario),
2. Given että olen tilin ylläpitäjä,
3. WhenSyötän salasanan salasanakenttään,
4. ThenMinua pitäisi varoittaa salasanavaatimuksista,
5. And Minun pitäisi saada tehdä korjauksia heti,
6. Then että voin luoda suojatun tilin.

Meillä on nyt täydellinen kuva siitä, kuka suorittaa tietyn toimen ja mitkä ovat hyväksymiskriteerien vaatimukset, ja tiimi tietää, mitä mahdollisia turhautumia saattaa esiintyä, jotta se voi varmistaa, että prosessi sujuu sujuvammin.

Yleensä tuotepäällikkö tai tuoteomistaja on vastuussa Gherkin-tarinoiden kirjoittamisesta, mikä parantaa muun tiimin välistä viestintää ja varmistaa, että kaikki keskittyvät tuloksiin, eivät vain tuotoksiin.

Mitkä ovat suosikkitapasi hahmotella tarinoita? Kerro minulle! ✌️