Als je net zo lang als ik (15+ jaar) in productmanagement werkt, heb je de overgang meegemaakt van uitgebreide productrequirementdocumenten (PRD's) waarin functionaliteit wordt beschreven naar Agile-productbacklogs waarin gebruikersverhalen worden beschreven.
Niemand mist PRD's, toch?
Agile-methoden zijn ongetwijfeld een verbetering, maar een vlak productbacklog kan snel uitgroeien tot een zeer lange, ongestructureerde lijst met items die moeilijk te onderhouden is.
Een manier om het grote geheel te zien, is door een kaart van gebruikersverhalen te maken. Hiermee krijg je een overzicht van een reeks complexe productfuncties. Dit is nuttig bij het starten van een nieuw product, maar ook bij het toevoegen van nieuwe functies aan een bestaand product. De kaart van gebruikersverhalen kan je ook helpen bij het definiëren van epics en gebruikersverhalen.
Wat is het in kaart brengen van gebruikersverhalen?
Het in kaart brengen van gebruikersverhalen is een methode om een complex product te structureren aan de hand van gebruikersreizen. De methode werd voor het eerst beschreven door Jeff Patton, die er een heel boek over heeft geschreven. Het maakt deel uit van de Lean Startup-methodologie.
De kaart van gebruikersverhalen beschrijft de gebruikerservaring van jouw product vanuit het perspectief van een gebruiker. Dit moet niet worden verward met een klantreis, die reizen beschrijft met inbegrip van motivaties, vragen en emoties vanuit het oogpunt van een klant, maar niet noodzakelijkerwijs op het product zelf is gericht.
De 3 niveaus van het in kaart brengen van gebruikersverhalen
Een kaart van gebruikersverhalen heeft drie niveaus. Laten we elk niveau bekijken aan de hand van een voorbeeld van een hotelwebsite.
Have an account? Log In
Niveau 1 - Activiteiten
Dit zijn gebruikersactiviteiten die mensen in jouw product uitvoeren. Op dit punt kunnen ze zo hoog- of laagdrempelig zijn als je wilt. Ik zou aanraden om te beginnen met redelijk algemene activiteiten, zodat je hoogste niveau in eerste instantie niet meer dan 10 items bevat. De activiteiten zijn geformuleerd als resultaten die gebruikers willen bereiken. Activiteiten worden horizontaal op de kaart geplaatst.
Voor onze hotelwebsite zouden enkele belangrijke activiteiten op hoofdlijnen kunnen zijn:
Niveau 2 - Stappen
Het volgende niveau bestaat uit de stappen die gebruikers in jouw product nemen om de activiteiten te voltooien die in niveau 1 zijn beschreven. Deze stappen worden ook horizontaal geplaatst.
In het voorbeeld van onze hotelwebsite zouden de stappen kunnen zijn:
Niveau 3 - Details
Op dit niveau beschrijf je in detail wat gebruikers nodig hebben om de stappen uit niveau 2 uit te voeren. Hier neem je alle gegevens en interacties op die nodig zijn om een stap te voltooien.
Niveau 3 wordt verticaal onder de activiteiten en stappen geplaatst. Als we het voorbeeld van onze hotelwebsite voortzetten, zouden de details kunnen zijn:
Een kaart van gebruikersverhalen maken
Voordat je begint met het maken van een kaart van gebruikersverhalen, moet je zeker weten welke exacte problemen je product oplost, welke typen gebruikers je bedient en wat de behoeften van je gebruikers zijn. Sommige UX-persona's kunnen hierbij helpen.
Voordat ze zich aan de gebruikersverhalen zelf verbinden, kunnen veel teams er ook baat bij hebben om eerst het bredere verhaal uit te werken. Storyboarden—waarbij technieken uit het maken van films en ontwerpen worden gebruikt—helpt teams om de emotionele reis en context van de gebruiker te visualiseren voordat specifieke interacties worden gedefinieerd. Terwijl het in kaart brengen van gebruikersverhalen het “wat” en “waarom” van productfunctionaliteit uiteenzet, kan storyboarden duidelijk maken “hoe het voelt” en “wat ervoor en erna komt” bij belangrijke contactmomenten.
Het in kaart brengen van gebruikersverhalen is een gezamenlijke taak. Op zijn minst heb je de leden van je multifunctionele productontwikkelingsteam nodig. Je kunt ook leden van de klantenservice, marketing, verkoopteams of andere belanghebbenden uitnodigen die inzicht hebben in wat gebruikers van je product verwachten. Zo zorg je ervoor dat jullie allemaal hetzelfde beeld hebben van je product als geheel.
Een gebruikersverhalenkaart hoeft echter niet in één sessie te worden opgebouwd. Het is raadzaam om tijdens de eerste sessie ten minste een uitgebreide lijst met activiteiten van niveau 1 te maken, zodat alle teamleden de complexiteit van het product als geheel kunnen zien en risico's en afhankelijkheden vroegtijdig kunnen herkennen. De volledige reeks details van niveau 2 en niveau 3 kan later worden uitgewerkt wanneer je de betreffende activiteit van niveau 1 ontwikkelt.
Wanneer je ervoor kiest om een kaart van gebruikersverhalen te maken, is de kans groter dat je een volledig beeld creëert en vervolgens het juiste product bouwt.
Hulpmiddelen voor het in kaart brengen van gebruikersverhalen
Om je kaart fysiek te maken, is elk medium dat na een paar dagen niet uit elkaar valt geschikt. Als je als team op dezelfde locatie werkt, kun je een whiteboard of zelfs een muur gebruiken om plakbriefjes op te hangen. Dit is een geweldige manier om de creativiteit te stimuleren, maar het nadeel is dat plakbriefjes na een paar dagen vaak van een muur vallen! Als je een muur gebruikt, raad ik je ten zeerste aan er foto's van te maken.
Natuurlijk zou een betere oplossing een van de vele gezamenlijke virtuele whiteboardoplossingen of software voor gebruikersverhalen zijn.
Gebruikersverhalen in kaart brengen en Agile-ontwikkeling
Of je nu Scrum, Kanban of een hybride methode gebruikt als Agile-methode voor softwareontwikkeling, je zult moeten bepalen hoe je productfuncties prioriteert. Met een gebruikersverhalenkaart kun je eenvoudig het volledige product zien, wat prioriteit moet krijgen voor de volgende productrelease en wat nog moet worden gebouwd.
Het volledige product in kaart hebben gebracht heeft ook als voordeel dat je het op meerdere manieren kunt uitsplitsen voor de prioritering van je productroadmap.
Je kunt de kaart van gebruikersverhalen verticaal uitsplitsen als het mogelijk is om enkele belangrijke gebruikersreizen af te zonderen voor de functionaliteit van een minimaal levensvatbaar product (MVP).
In het voorbeeld van onze hotelwebsite kun je misschien alleen informatie over je hotel en kamerprijzen online zetten, maar nog geen volledig online boekingsproces. In je allereerste iteratie kunnen klanten alle informatie vinden die nodig is om een beslissing te nemen, maar zullen ze bellen of een e-mail sturen om een kamer te boeken.
Je kunt de kaart van gebruikersverhalen ook horizontaal uitsplitsen om je klanten een minimale reis van begin tot eind te bieden. In ons hotelvoorbeeld kan dit betekenen dat je online een eenvoudige zoek- en boekingsfunctie voor kamers hebt, maar niet alle extra's die kunnen worden geboekt.
More Articles
- VP Product van Amex zegt dat AI geleidelijk in productorganisaties moet worden geïntegreerd — één overgeslagen laag kost je
- Docent productmanagement en voormalig CPO zegt dat sprints en roadmaps zijn ontworpen voor een trager tijdperk van productwerk
- Een PRD schrijven: complete gids in 10 stappen + AI-schrijfopdrachten
Een kaart van gebruikersverhalen vertalen naar je Agile-backlog
Om je product uiteindelijk te ontwikkelen, zul je je kaart van gebruikersverhalen waarschijnlijk moeten omzetten in een vlakke Agile-backlog met gebruikersverhalen voor prioritering en sprintplanning.
Misschien vraag je jezelf af: is dit geen dubbel werk? Eigenlijk kunnen de details van niveau 3 uit je kaart eenvoudig de gebruikersverhalen en acceptatiecriteria voor je Agile-team worden. Hoewel er dus een beetje sprake is van dubbel werk, wordt het schrijven van gebruikersverhalen eenvoudig wanneer je een goede kaart van gebruikersverhalen hebt ontwikkeld.
Waarom zou ik gebruikersverhalen in kaart brengen?
Samenvattend zijn er verschillende voordelen aan het gebruik van een kaart van gebruikersverhalen ten opzichte van een vlakke Agile-backlog:
- Je krijgt een holistisch beeld van je product, zodat je de omvang van het benodigde werk begrijpt.
- Je kunt risico's en afhankelijkheden eerder en gemakkelijker identificeren.
- Je kunt je Agile-sprintwerk gemakkelijker prioriteren vanuit een gestructureerde kaart dan vanuit een ongestructureerde, vlakke backlog.
- Je hebt binnen de hele organisatie een gedeeld begrip van de gebruikersactiviteiten die je product ondersteunt.
Als je meer wilt lezen over beste-praktijken op het gebied van productmanagement, abonneer je dan op onze nieuwsbrief.
Gerelateerd artikel: Wat is een Agile-epic? Beste praktijken, sjabloon en voorbeeld
Breid je team uit? Hier is iets nuttigs: Zo maak je een effectieve functieomschrijving voor een agile productmanager (+ voorbeeld)
Ook de moeite waard om te bekijken:
