Als je ooit in een spookhuis bent geweest (en als je dat niet hebt gedaan, moet je je levenskeuzes heroverwegen), weet je dat ze extreem doordacht zijn. Ontwerpers van spookhuizen weten hoe ze bezoekers kwetsbaar kunnen opstellen, zodat ze de grootste schrik kunnen opwekken voor een maximale reactie. De ontwerpers werken vaak een heel jaar aan de perfecte plek, waarbij ze de plattegrond steeds opnieuw bekijken, nieuwe plattegronden uitproberen en hun vorige spookplekken verbeteren, zodat ze elk jaar nog angstaanjagender zijn.

Interessant is dat user story mapping vergelijkbaar is met het ontwerpen van een spookhuis. Het gaat om doordachte beslissingen, een behoorlijke hoeveelheid onderzoek en een grote hoeveelheid empathie om een product te maken dat de beste gebruikerservaring oplevert. Natuurlijk zou je kunnen vertrouwen op het systematisch afwerken van backlogitems, maar dat zou de voordelen voor de gebruiker niet vergroten. 

Lees meer over user story mapping en hoe je productontwikkeling daarmee veel minder eng kunt maken.

Wat is een user story?

Om deze vraag te beantwoorden, moet je eerst weten wat user stories zijn. Denk eens aan de manier waarop je, laten we zeggen, een navigatie-app gebruikt om een koffiebar te vinden. Je opent eerst de kaart, centreert hem in de buurt van je locatie, voert 'koffiebar' in, klikt op zoeken en selecteert de koffiebar waar je naartoe wilt. Vervolgens wijst de navigatie-app je stap voor stap de weg daar naartoe. Dat hele proces van het openen van de app tot de aankomst op je bestemming is de user story. Een user story is de manier waarop een klant met een product omgaat.

Wat is een user story map?

Wat is dan een user story map? De documentatie van die story. Het is een stapsgewijze analyse van de interactie van een gebruiker met een bepaald product. In agile kan story mapping je helpen om te bepalen waar er potentieel is om functies te ontwikkelen en te verbeteren voor de beste customer experience.

Waarom user story mapping?

Je hebt nu waarschijnlijk al een van de grootste voordelen van user story maps begrepen: het ontwikkelen van een product dat volledig is gericht op de gebruikerservaring. Maar er zijn ook andere voordelen.

• Het zorgt voor duidelijkheid bij het prioriteren.
  Het prioriteren van backlogitems kan verwarrend zijn. Moet de prioriteit liggen bij het afwerken van de gemakkelijkste items? Of bij de goedkoopste items? Uiteindelijk zijn de items die de meeste waarde opleveren de items die de customer experience het meest verbeteren. Als je weet wat klanten het meest waarderen, kun je backlogitems rangschikken van de meeste naar de minste impact op de klant.
• Het helpt de juiste vereisten te bepalen.
  Backlogitems kunnen snel in omvang toenemen zonder dat er eisen worden gesteld. Story mapping bepaalt de juiste grootte voor producteisen en stelt je in staat om grote projecten op te splitsen in de juiste grootte voor je teams.
• Het fungeert als poolster.
  Carl van de design-afdeling dringt aan op 3D-weergaven van elk product in de winkel. Het is een goed idee, maar bij het ontwikkelen van de user stories van je klanten zie je dat de meeste klanten producten bekijken op een mobiel apparaat. Zelfs met lazy loading zouden pagina's met 3D-weergaven van het product er veel langer over doen om geladen te worden. Als Carl de user story in kaart brengt, ziet hij ook in dat de prioriteit geven aan 3D-weergaven niet in het belang van de klant is. User maps kunnen dienen als neutrale oplossing voor meningsverschillen en teams op een lijn te krijgen. 
• Het benadrukt afhankelijkheden.
  Als je gebruikers voornamelijk iPhone-gebruikers zijn en graag online afrekenen, is de integratie van Apple Pay wellicht een topprioriteit. Als je app nog niet beschikbaar is in de App Store, zul je hem eerst via Apple moeten implementeren voordat je Apple Pay kunt integreren. Als de user story in kaart gebracht is, kun je meteen de afhankelijkheden bepalen die eerst moeten worden aangepakt voordat je verder gaat met de ontwikkeling van de functie.

Wie is er betrokken bij user story mapping? 

Er is geen vaste regel voor wie er betrokken moet zijn bij user story mapping, aangezien dat grotendeels bepaald wordt door het product en wie eraan werkt. Als je een API voor banken ontwikkelt, hoeft je HR-team niet betrokken te zijn bij de user story map. Maar als je nadenkt over wie er zou moeten meewerken aan de user story map, is het over het algemeen nuttig om de volgende personen en teams in overweging te nemen:

• UX/UI
• Productmanagers
• Verkoopteams
• Marketing
• Klantenservice-/klantenondersteuningsteams
• Technische teams
• IT
• Juridische afdeling
• Financiële teams

Een user story map maken 

Als je niet weet hoe je een user story moet maken, zijn wij er om je te helpen. Bovendien hoef je niet te weten hoe je user stories maakt of zelfs maar bijhoudt welke user stories je geschreven hebt: Lucidspark heeft het werk al voor je gedaan. Je hoeft alleen de volgende vragen te beantwoorden en het sjabloon te volgen om de elementen van je user story maps te bepalen:

1. Wat is het probleem dat je wilt oplossen?

Dit is de ultieme stress die je voor je klant wegneemt. Als je bijvoorbeeld een budgetteringsapp maakt, willen je klanten meer controle over hun geld. Als je een app maakt om calorieën te tellen, proberen je klanten hun afslankdoelen te bereiken.

2. Wie zijn je gebruikers?

Je moet een groot inlevingsvermogen ontwikkelen voor je gebruikers en dat kan niet zonder te weten wie je gebruikers zijn. Verschillende mensen hebben verschillende doelen en zullen anders met je product omgaan.

3. Hoe gaan je gebruikers over het algemeen om met je product?

Nu moet je de algemene activiteiten van elke gebruiker gaan documenteren. Dit zijn algemenere onderwerpen die in de volgende stap in kleinere user stories zullen worden onderverdeeld. Als je een website voor tweedehandskleding hebt, kunnen je gebruikers de app openen, producten uploaden om te verkopen en vervolgens beschrijvingen van de kleding invoeren. 

4. Welke specifieke activiteiten voeren je klanten uit?

Splits de bovenstaande onderwerpen op in specifiekere user stories. Als elke klant producten uploadt om te verkopen, kan hij/zij bijvoorbeeld zeggen: 'Ik wil meerdere foto's van mijn product toevoegen' en 'Ik wil de beschrijvingen van mijn producten kunnen bewerken'.

Met je gedetailleerde user stories kan je team beginnen om te bepalen welke user stories het belangrijkst zijn voor de gebruiker en die dan prioriteit geven. Nu weten je teams welke acties het grootste voordeel opleveren voor je gebruikers.

Uitdagingen van user stories (en hoe je ze kunt overwinnen)

1. Je story map is te algemeen/te gedetailleerd.

Er is een gulden middenweg voor te veel details. Als je team in de war raakt, dan zijn de stappen te gedetailleerd. Gebruik eenvoudige taal om het risico te verkleinen dat je te veel in detail treedt.

2. Je kent je gebruikers niet.

Als je niet weet wie je gebruikers zijn, kun je ook geen map voor hen maken. Gebruik demografische gegevens om inzicht te krijgen in de gebruikers van je product.

3. Je story map is onoverzichtelijk.

Als je user story map moeilijk te lezen of onoverzichtelijk is of niet gemakkelijk bijgewerkt kan worden dan is een sjabloon in de cloud gebruiken handiger.

4. Je weet niet waarom je product bestaat.

Dit is een groot probleem. Als je niet weet welk probleem je product oplost, kun je ook geen story map maken om te bepalen hoe je het probleem kunt oplossen.

Ziezo. Je snelstartgids voor user story maps. Veel minder eng dan een spookhuis betreden.