Kartlegging av brukerhistorier: Slik styrker du agil prioritering

Hvis du har jobbet med produktledelse like lenge som jeg har (over 15 år), har du sett overgangen fra lange dokumenter med produktkrav (PRD-er) som beskriver funksjonalitet, til smidige produktetterslep som beskriver brukerhistorier.

Ingen savner PRD-er, vel?

Smidige metoder er utvilsomt en forbedring, men et flatt produktetterslep kan raskt vokse til en svært lang og ustrukturert liste over elementer, som kan være vanskelig å vedlikeholde.

Én måte å se helheten på er å lage et kart over brukerhistorier. Dette gir deg en oversikt over et sett med komplekse produktfunksjoner. Det er nyttig når du starter et nytt produkt, men også når du legger til nye funksjoner i et eksisterende produkt. Kartet over brukerhistorier kan også hjelpe deg med å definere epos og brukerhistorier. 

Hva er kartlegging av brukerhistorier?

Kartlegging av brukerhistorier er en metode for å strukturere et komplekst produkt i brukerreiser. Metoden ble først beskrevet av Jeff Patton, som har skrevet en hel bok om den. Den er en del av Lean Startup-metodikken. 

Kartet over brukerhistorier beskriver brukeropplevelsen av produktet ditt fra brukerens perspektiv. Dette må ikke forveksles med et kundereisekart, som beskriver reiser, inkludert motivasjoner, spørsmål og følelser, fra kundens synspunkt, men som ikke nødvendigvis fokuserer på selve produktet.

De tre nivåene i kartlegging av brukerhistorier

Et kart over brukerhistorier har tre nivåer. La oss se på hvert nivå sammen med et eksempel fra et hotellnettsted. 

Nivå 1 – aktiviteter

Dette er brukeraktiviteter som folk utfører i produktet ditt. På dette tidspunktet kan de være så overordnede eller detaljerte som du ønsker. Jeg vil foreslå å starte med ganske overordnede aktiviteter, slik at det øverste nivået i alle fall i begynnelsen ikke overstiger 10 elementer. Aktivitetene formuleres som resultater brukerne ønsker å oppnå. Aktivitetene legges ut horisontalt på kartet.

For hotellnettstedet vårt kan noen viktige aktiviteter på et overordnet nivå være:

Nivå 2 – trinn

Det neste nivået er trinnene brukerne tar i produktet ditt for å fullføre aktivitetene som er beskrevet i nivå 1. Disse trinnene legges også ut horisontalt.

I eksempelet med hotellnettstedet vårt kan trinnene være: 

Nivå 3 – detaljer

På dette nivået beskriver du i detalj hva som kreves for at brukerne skal kunne utføre trinnene som er beskrevet i nivå 2. Her inkluderer du alle dataene og interaksjonene som kreves for å fullføre et trinn. 

Nivå 3 legges vertikalt under aktivitetene og trinnene. Hvis vi fortsetter eksempelet med hotellnettstedet vårt, kan detaljene være:

Slik lager du et kart over brukerhistorier

Før du begynner å lage et kart over brukerhistorier, må du være sikker på at du vet nøyaktig hvilke problemer produktet ditt løser, hvilke typer brukere du betjener, og hvilke behov brukerne dine har. Noen UX-personaer kan være nyttige i dette arbeidet.

Før dere forplikter dere til selve brukerhistoriene, kan mange team også ha nytte av å skissere den overordnede fortellingen først. Storyboardarbeid – med teknikker hentet fra filmproduksjon og design – hjelper team med å visualisere brukerens følelsesmessige reise og kontekst før de definerer spesifikke interaksjoner. Mens kartlegging av brukerhistorier viser “hva” og “hvorfor” ved produktfunksjonalitet, kan storyboardarbeid tydeliggjøre “hvordan det føles” og “hva som kommer før og etter” viktige kontaktpunkter.

Kartlegging av brukerhistorier er en samarbeidsoppgave. Som et minimum trenger du medlemmene av det tverrfunksjonelle produktutviklingsteamet ditt. Du kan også ønske å invitere medlemmer fra kundestøtte, markedsføring, salgsteam eller andre interessenter som har innsikt i hva brukerne forventer av produktet ditt. Dette sikrer at dere har en felles forståelse av hele produktet.

Et kart over brukerhistorier trenger imidlertid ikke å bygges ferdig i én økt. Det anbefales å ha minst en omfattende liste over aktiviteter på nivå 1 i den første økten, slik at alle teammedlemmene kan se kompleksiteten i hele produktet og oppdage risikoer og avhengigheter tidlig. Hele omfanget av detaljer på nivå 2 og nivå 3 kan imidlertid bygges ut senere, når dere utvikler den aktuelle aktiviteten på nivå 1.

Når du velger å lage et kart over brukerhistorier, er det mer sannsynlig at du skaper et helhetlig bilde og deretter utvikler det riktige produktet. 

Verktøy for kartlegging av brukerhistorier

For å lage kartet fysisk fungerer alle medier som ikke faller fra hverandre etter noen dager. Hvis dere jobber som et samlokalisert team, kan dere bruke en tavle eller til og med en vegg der dere fester klistrelapper. Dette er en flott måte å få kreativiteten til å flyte på, men ulempen er at klistrelapper ofte faller av veggen etter noen dager! Hvis du bruker en vegg, anbefaler jeg på det sterkeste at du tar bilder av den. 

Et bedre alternativ vil naturligvis være en av de mange virtuelle samarbeidsbaserte tavleløsningene eller programvare for brukerhistorier. 

Kartlegging av brukerhistorier og smidig utvikling

Uansett om du bruker Scrum, Kanban eller en hybrid som metode for smidig programvareutvikling, må du finne ut hvordan du skal prioritere produktfunksjoner. Et kart over brukerhistorier gjør det enkelt å se hele produktet, hva som bør prioriteres for neste produktutgivelse, og hva som gjenstår å bygge. 

Det at hele produktet er kartlagt, har også den fordelen at du kan dele det opp på flere måter for å prioritere produktveikartet ditt. 

Du kan dele kartet over brukerhistorier vertikalt hvis det er mulig å skille ut noen viktige brukerreiser for funksjonaliteten i et minimumsprodukt (MVP). 

I eksempelet med hotellnettstedet vårt kan du kanskje bare legge ut informasjon om hotellet og romprisene på nettet, men ikke en komplett nettbasert bestillingsflyt. I den aller første iterasjonen kan kundene finne all informasjonen de trenger for å ta en beslutning, men de må ringe eller sende en e-post for å bestille et rom. 

Alternativt kan du også dele kartet over brukerhistorier horisontalt for å gi kundene dine en minimal ende-til-ende-reise. I hotelleksempelet vårt kan dette bety at dere har et grunnleggende søk etter rom og en bestillingsflyt på nettet, men ikke alle tilleggene som kan bestilles. 

Gjøre et kart over brukerhistorier om til den smidige arbeidskøen din

For å utvikle produktet ditt må du til syvende og sist sannsynligvis omforme kartet over brukerhistorier til en flat, smidig arbeidskø med brukerhistorier for prioritering og sprintplanlegging.

Du spør kanskje deg selv: Er ikke dette dobbeltarbeid? Egentlig kan detaljene på nivå 3 fra kartet ditt enkelt bli brukerhistoriene og akseptansekriteriene for det smidige teamet ditt. Så selv om det er litt dobbeltarbeid, blir det enkelt å skrive brukerhistorier når du har utviklet et godt kart over brukerhistorier. 

Hvorfor bør jeg bruke kartlegging av brukerhistorier?

For å oppsummere finnes det en rekke fordeler ved å bruke et kart over brukerhistorier fremfor en flat, smidig arbeidskø:

• Du får et helhetlig bilde av produktet ditt, slik at du forstår omfanget av arbeidet som kreves.
• Du kan identifisere risikoer og avhengigheter tidligere og enklere.
• Du kan enklere prioritere arbeidet i de smidige sprintene dine ut fra et strukturert kart i stedet for en ustrukturert, flat arbeidskø.
• Dere får en felles forståelse på tvers av virksomheten av hvilke brukeraktiviteter produktet støtter. 

Hvis du vil lese mer om beste praksis for produktledelsesmetoder, hvorfor ikke abonnere på nyhetsbrevet vårt.

Relatert lesning: Hva er en smidig episk oppgave? Beste praksis, mal og eksempel

Skal du utvide teamet ditt? Her er noe nyttig: Slik lager du en effektiv stillingsbeskrivelse for en agil produktleder (+eksempel)

Også verdt å sjekke ut:

• Topp 15 rammeverk for prioritering av produktfunksjoner: Hvilket er best?
• De 4 beste nettbaserte sertifiseringene innen agil produktledelse
• Verktøy for håndtering av programvareutgivelser