← Insights
User Story Mapping på Kungliga Operan
ArtikelGuideProduktutveckling & Product ManagementAv Mia Kolmodin

User Story Mapping – Gratis guide att ladda ner

En User Story Map är ett enkelt men kraftfullt sätt att visualisera hur användarna använder din produkt eller tjänst – och att bygga rätt sak. Den hjälper er att snabbt gå från att förstå användaren till att faktiskt bygga och leverera produkten.

User Story Mapping på Kungliga Operan

En User Story Map är ett enkelt men kraftfullt sätt att visualisera berättelsen om hur användarna använder din produkt eller tjänst – och att bygga rätt sak.

Den är enkel eftersom den ger stöd för att snabbt gå från att förstå användaren och dennes problem till att bygga och lansera produkten, och det kan göras med enkla post-it-lappar på en vägg eller i enkla digitala verktyg.

Hands-On Master Class i User Story Mapping

Master class · 20 januari 2027 · Stockholm

Hands-On Master Class i User Story Mapping

För er som arbetar med produktledning eller behöver kunna stötta detta arbete.

Läs mer och anmäl dig →

Den är kraftfull eftersom den berättar en historia, ger sammanhang åt varje user story och ger en tydlig överblick över backloggen och vad vi behöver bygga för att stödja användarscenarierna över alla relevanta kontaktpunkter. Den stödjer även samarbete och både horisontell och vertikal skivning (slicing).

Jag är evigt tacksam mot Jeff Patton, skaparen av User Story Mapping, som jag lärde mig metoden av för cirka 13 år sedan. Utan den vet jag inte var jag hade varit i dag. Det har varit en av de mest värdefulla metoderna för mig för att möjliggöra leveranser av fantastiska användarupplevelser i mycket komplexa domäner, med skarpa deadlines (som sportevenemang som sker när de sker) med allt från ett till över 20 team 🙏

Förhandsvisning av User Story Mapping-guiden (PDF, två sidor)
Så här ser guiden ut som du laddar ner.

Det är en levande, transparent och värdebaserad backlogg som stöttar Product Owners och team att hitta tunna skivor att släppa som skapar verkligt värde utifrån användarscenarier, snarare än funktioner. Om ni vill bli en värde- och produktdriven organisation erbjuder det här verktyget mycket stöd.

Det kommer kanske inte som en överraskning att User Story Map är det vanligaste verktyget för agil produktplanering med ett eller flera team. Jeff Patton uppfann det och tog in det som en central del av CSPO-utbildningen (Certified Product Owner) när han skapade den för Scrum Alliance för många år sedan. Jeff Patton, med sin bakgrund inom UX och design, har varit en stark drivkraft för att göra kundcentrerade arbetssätt agila och knyta ihop dem naturligt med Scrum och produktteam.

Begrepp i User Story Mapping

User Story Mapping – begrepp och kartans uppbyggnad

En User Story Map berättar historien om en viss typ av person som gör något för att nå ett mål. Se till att ta med dessa personer i kartan tillsammans med lite information om dem. Använd gärna enkla personas eller roller för att beskriva användarna.

Användaruppgifter (User Tasks)

Användaruppgifter är korta verbfraser som utgör kartans grundläggande byggstenar. Om jag frågar dig vad du gjorde tidigare i dag när du använde e-post, svarar du sannolikt med uppgifter som: • Läsa ett e-postmeddelande • Svara på ett meddelande • Markera ett meddelande som skräppost

Användaruppgifter blir utmärkta titlar på User Stories. Skriv korta verbfraser på kort eller lappar och använd dem senare som story-titlar. Om du använder en mall för story-beskrivningar passar uppgiften perfekt direkt efter "Jag vill...", och aktiviteten passar perfekt efter "så att...".

Målnivå (Goal Level)

De handlingar som användarna utför för att nå sina övergripande mål har själva en målnivå kopplad till användarbeteendet. Sammanfattande (Summary): många uppgifter som görs för att stödja ett större mål. Funktionell (Functional): jag förväntar mig att slutföra uppgiften innan jag tar en paus. Sub-funktionell (Sub-Functional): mindre moment som görs för att stödja en större uppgift. När du läser av uppgifterna längs ryggraden (backbone), kontrollera att de ligger på en liknande målnivå.

Aktiviteter (Activities)

Aktiviteter organiserar uppgifter som utförs av liknande personer vid liknande tidpunkter för att nå ett mål. För din e-postklient kan aktiviteter inkludera:

  • Gå igenom min inkorg
  • Konfigurera min e-postklient
  • Organisera meddelanden i mappar

Narrativt flöde (Narrative Flow)

Den horisontella axeln från vänster till höger i en story map är organiserad i den ordning du skulle berätta historien om användaren för någon annan.

Självklart kan en specifik användare välja att göra olika saker i en annan ordning. Använd samtal för att förklara detaljer och variationer.

Om du är ute efter precisionen i en arbetsflödesmodell, ett flödesschema eller en UML-modell är en story map inte rätt val.

En story map kräver mycket dialog för att fungera effektivt. Men det är också själva syftet med stories.

User Story Map med användarens narrativa flöde från vänster till höger

Detaljer, detaljer…

Bryt ned uppgifter på hög målnivå i:

  • Deluppgifter
  • Alternativa uppgifter
  • Undantag
  • Detaljer

Det går bra att fånga lösningsidéer bland detaljerna för användaruppgifter eller aktiviteter, som hur gränssnittet kan se ut eller vad systemet gör i bakgrunden. Men helst görs detta först med design studio eller liknande metoder för att nyttja den kollektiva intelligensen, och sedan löpande när teamet börjar leverera i varje sprint.

Detaljer och alternativa uppgifter i en User Story Map

Release-skiva (Release Slice)

Dra ett streck över kartan, eller använd tejp, för att identifiera skivor av uppgifter som användarna kan använda i er mjukvara för att nå sina mål. Det minsta antalet uppgifter som gör att era specifika målanvändare når sitt mål utgör en livskraftig produktrelease. Använd release-skivor för att identifiera små experiment, minimalt livskraftiga produktreleaser (MVP) eller en "walking skeleton"-version av produkten. Identifiera de önskade effekterna (outcomes) för skivan på en lapp vid sidan av skivan.

User Story Map uppdelad i release-skivor

Mappa nu och senare (Map Now & Later)

Använd en karta för att beskriva världen som den ser ut i dag. Lägg till smärtpunkter, glädjeämnen och belöningar, detaljer, observationer och lösningsidéer. Detta kan göras baserat på en kundresa (Customer Journey) eller en användartransaktionskarta (User Transaction Map), som är utmärkta verktyg för att kartlägga nuläget i processer, komplexa interaktioner och upplevelsen. Utveckla kartan med hjälp av design- och discovery-aktiviteter som storyboarding eller design studio för att beskriva det beteende ni förväntar er att användarna ska ha i framtiden. User Story Maps används för att förstå nuläget och föreställa sig framtiden.

Mappa hela systemet

Mappa en hel process när den rör sig genom flera typer av användare och kontaktpunkter. Story maps är till för att se helheten.

Kartläggningsprocessen

Story-kartan utvecklas i takt med att er förståelse för era användare och er produktlösning fördjupas.

1. Före kartläggningen

Sätt ramarna för vilken kundresa, produkt, tjänst och vilka målanvändare ni troligen kommer att ha med i kartan. Kom ihåg att detta kan uppdateras när hela historien klarnar. Detta visar vilka som behöver involveras i skapandet och vilka kundresor, användartransaktionskartor eller personas som eventuellt behöver tas fram innan ni går vidare till user story mapping.

2. Mappa helhetsbilden

Fokusera på att få med hela historien. Tänk "en mil bred, en tum djup". Aktiviteterna och de övergripande användaruppgifterna som berättar hela historien utgör ryggraden (backbone) i er story map. Titta på kundresan från början till slut: vad användarna gör före, under och efter att de använder er produkt.

Börja med den användartyp som är mest avgörande för produktens framgång. Föreställ dig en typisk dag i användarens liv med er nya produkt, eller använd insikter från användarnyttaundersökningar och mappa direkt från er kundresa eller användartransaktionskarta. Mappa stegen de tar som användaruppgifter från vänster till höger. Det går bra att göra antaganden i det här skedet, men alla riskfyllda antaganden måste valideras för att säkerställa att ni levererar rätt produkt och uppfyller verkliga användarmål.

Identifiera användaraktiviteter – grupper av uppgifter som samverkar för att stödja ett gemensamt mål. Aktiviteter växer ofta fram när man ser mer av sammanhanget. Se till att användaraktiviteten avslutas med att användaren når sitt mål inom den aktiviteten.

Lägg till ytterligare användare. Allteftersom du följer den typiska användningen av produkten kan du upptäcka att andra typer av användare kliver in i historien. Fortsätt att modellera deras resa från vänster till höger.

Kartläggning av helhetsbilden i en User Story Map

3. Utforska

Fyll ut kartans innehåll genom att bryta ned större användaruppgifter i mindre deluppgifter. Under den här fasen lägger ni till lappar, delar upp en lapp i två, skriver om lappar och omorganiserar dem.

Uppgifter och deluppgifter som inte tillför värde för en användare faller utanför scopet och prioriteras inte för utveckling, men detta upptäcks senare i processen när ni börjar validera era idéer och lansera.

Det kan vara klokt att tidsboxa den här fasen. Ha i åtanke att "tillräckligt bra" faktiskt tar längre tid om man försöker få med alla detaljer direkt, när man har som minst information.

4. Skiva ut livskraftiga releaser

Skiva er karta i helgjutna produktreleaser som spänner över användarna och användningen av produkten. Dessa skivor bildar en inkrementell release-färdplan där varje release är en minimalt livskraftig produktrelease (MVP).

Definiera önskade effekter (outcomes) och påverkan (impact) för varje release. Mål och påverkan beskriver hur denna release bidrar till det övergripande syftet – det "stora varför" som motiverar att produkten byggs – och hur användarna kommer att agera på ett sätt som hjälper oss att nå målet.

Exempel på releasemål: Release 1 möjliggör användarscenariot "Öppna ett konto, sätt in pengar och använd dem online" för personan "Millenial Millan". Release 2 möjliggör användarscenariot "Skicka och ta emot pengar från vänner" för personan "Millenial Millan".

Identifiera framgångsmått för varje release. Besvara frågan: "Vad skulle vi mäta för att avgöra om denna produkt var framgångsrik?" Helst hittar ni specifika beteendeförändringar hos användarna när de använder produkten på det sätt som er story map beskriver.

5. Skiva ut en utvecklingsstrategi

Skiva den första releasen i er karta i tre eller fler leveransfaser som gör att du och teamet kan lära er snabbt och undvika risker. Tänk på faserna som öppningsspel, mittspel och slutspel i schack.

Denna utvecklingsstrategi hjälper er att släppa bästa möjliga produkt inom de tidsramar ni har.

  • Öppningsspel (Opening Game) bygger ett funktionellt "walking skeleton" – den enklaste tänkbara funktionella versionen av produkten. När öppningsspelet är klart testas produkten med användare och andra intressenter. Börja validera önskad prestanda och skalbarhet.
  • Mittspel (Mid Game) färdigställer all huvudsaklig funktionalitet och gör befintliga funktioner rikare och mer kompletta. Fortsätt användartesterna och använd återkopplingen för att justera produkten. Fortsätt att testa prestanda och skalbarhet.
  • Slutspel (End Game) förfinar produkten inför release. Utvärdera löpande release-beredskapen baserat på produktmålen för releasen. Räkna med att oförutsett arbete dyker upp under denna sista utvecklingsfas.

När en User Story Map väl är på plats fungerar den som en levande backlogg som Product Owner (eller Product Owners) använder för kontinuerlig planering tillsammans med teamet eller teamen. Utifrån releasemålen kan teamen planera vilka användaruppgifter som ska hanteras, och Product Owner kan omplanera releasemålen utifrån återkoppling.

User Story Map med en stegvis utvecklingsstrategi

User Story Map som produktbacklogg – med ett eller flera team

Ofta när man använder en User Story Map i ett stort projekt visar det sig att man inte genomför ungefär 50 % av alla stories. Det beror på att de inte behövs för att nå våra mål och tillfredsställa användarna. Det sparar naturligtvis mycket tid och pengar, som vi i stället kan lägga på nästa prioriterade mål.

När vi arbetar agilt vill vi hålla teamen stabila över tid, de levererar inkrementellt och iterativt och förvaltar alltid det de själva har byggt.

En User Story Map är ett fantastiskt sätt för en Product Owner att främja det ägarskapet över tid. Eftersom ryggraden i en process oftast förblir densamma kan man lägga till nytt material när man lär sig mer och planera om sprintar och releasemål. Kartan är också ett utmärkt sätt att hålla intressenter informerade om vad teamen arbetar med och vad de inte arbetar med. Den är supertransparent.

Vill du lära dig mer?

Det här innehållet är en del av vår självstudiekurs Agile Product Development Process and Organization In a Nutshell Training and Toolbox i vår Digital Academy.

Agila onlineutbildningar i din egen takt, i ett roligt, hjärnvänligt och engagerande interaktivt format. Få tillgång nu!

Ladda ner materialet

15 minuter, inga förpliktelser

☕ Boka 15 min digitalt kaffe

Lämna namn och mejl så återkommer vi inom kort med två tidsförslag som passar dig.

Fler insikter som denna direkt i mejlen?

Nya fällor, posters och gratiswebinar – på svenska och utan brus.

Du kan avregistrera dig när du vill via länken i varje utskick.

Vill ni prata vidare om det här?

Vi resonerar gärna kring vad detta betyder i er organisation.