Aan het werk met User Stories

In de blog van vandaag ga ik een manier aan je voorstellen om een goede briefing van een klant te ontvangen. De briefing moet leuk en boeiend zijn maar ook vooral duidelijk zijn om de klus te klaren.

In het volgende voorbeeld gaan we er vanuit dat een potentiële klant contact met je opneemt en aangeeft dat deze persoon graag een website bij je wilt laten maken. Diep in het achterhoofd ben je waarschijnlijk direct hoeveel pagina’s de website moet hebben en met meer soortgelijke zaken. De klant geeft op een eenvoudige manier antwoorden zoals “we hebben maar 5 pagina’s nodig voor onze website want de website is eigenlijk alleen een soort brochure voor ons”. Maar aan het einde van het gesprek blijkt dat de klant tussen neus-en-lippen door ook een “winkel” aan hun website willen hebben toegevoegd om producten te verkopen.

En dan komt hun hamvraag, kun je ons een prijs geven? En het geven van de prijs wordt dan moeilijk om te geven want de wensen in zo’n kort telefoongesprek geven niet aan wat de exacte functionaliteit van de website moet zijn. Misschien zou je in eerste instantie WooCommerce installeren of een ander eCommerce systeem maar je weet nog niet eens of deze plugins aan jouw wensen of die van de klant zal voldoen.

Om deze problemen te verhelpen moet je een document creëren met daarin een aantal belangrijke specificaties. En die specificaties worden per alinea in een geordend document met de klant gedeeld. Maar helaas, iedere klant haat zo’n briefing. Dus er zijn ook manieren om dit op een leukere manier met de klant te doen zoals bijvoorbeeld ‘User Stories’.

User Stories laten op een andere manier zien wat de functionaliteiten voor een website zal zijn. Stel je eens voor dat jij en je klant samen een boek gaan schrijven over het ontwerpen en bouwen van een nieuwe website. Jullie geven het boek een titel zoals “Een reis naar een nieuwe website” en daarmee gaan jullie wat plezier beleven. Om de structuur van het boek te bepalen, in plaats van een saai briefings document, moet je de hoofdpersonen en de hoofdstukken voor in het boek bepalen.

De hoofdpersonen zijn de mensen die de website gaan bezoeken. Probeer deze karakters zo echt mogelijk te maken door hun onder andere een naam te geven. Beide personen krijgen een andere rol. Bijvoorbeeld zal de eerste persoon een bezoeker van de website zijn en de tweede een admin van de website.

Door de hoofdpersonen als eerste te bepalen kan je hoofdstukken gaan bedenken per karakter. Voor de hoofdpersoon die de website bezoekt krijg je hoofdstukken zoals; “hoe werd de website gevonden?” of “hoe werd er naar de product pagina’s genavigeerd” en “via welken knoppen kwam hij hier terecht”. En door dit te doen maak jij met de klant een hoop lol om de functionaliteiten van de website te bepalen. Maar let erop dat een scenario van de hoofdpersoon vanuit verschillende invalshoeken kan starten. De hoofdpersoon kan je website bereiken via een zoekopdracht in Google of door op een knop in je nieuwsbrief te hebben geklikt. Beide scenario’s hebben dan ook een ander hoofdstukindeling.

Al deze hoofdstukken helpen jou als projectmanager, designer of ontwikkelaars team om de wensen en benodigdheden van de website te begrijpen. En het voordeel is als een klant tegen je zegt “Ooh, hoe kan ik alle producten in mijn winkel exporteren ?” Dan kan jij laten zien dat dit scenario niet als hoofdstuk is beschreven dus laten we dat weer samen creëren. Op basis daarvan kan je komen met een nieuwe offerte gebaseerd op het nieuwe scenairo.

Ik hoop dat dit voorbeeld voor jullie interessant is en jullie hier wat aan hebben. Wij gebruiken deze methode dagelijks in de praktijk en het geeft ons veel houvast en stabiliteit in het ontwerp- en ontwikkelproces.

Plaats een reactie