In de tijd voordat we alles responsive, mobile ready en volgens material design bouwden, maakten we ook websites. Helaas waren veel van deze websites toen niet echt goed ontworpen. Je herinnert je vast nog wel sites waardoor je liever de browser sloot dan naar de benodigde content zocht. Een goed voorbeeld hiervan is hoe Google het won van Altavista.
Lag dit aan de designer? Was die werkelijk niet in staat om een mooie pagina te creëren? Waren de hulpmiddelen niet voldoende? Was er te weinig budget?
Tegenwoordig, als ICT projecten in het nieuws zijn, staan ze meestal in een niet zo goed daglicht. In Nederland zijn genoeg voorbeelden te noemen. Waarom deze projecten floppen heeft verschillende oorzaken. Denk aan slecht omschreven en onderbouwde feature requests, zoals hier uitstekend geïllustreerd door the Oatmeal.
In dit geval worden de wensen van een klant niet getoetst aan de toegevoegde waarde. Er ontstaat een wensenlijstje die niets toevoegt aan het uiteindelijke product.
De oplossing: de user story
Dit is een omschrijving van een functie binnen een product welke direct waarde toevoegt voor een gebruiker. Op een abstract niveau wordt deze beschreven als volgt: “Ik als (rol), wil (functie) zodat ik (doel van de functie).” De rol kan de eindgebruiker zijn, maar ook een stakeholder of een externe (developer, administrator, etc.)
Op deze manier focus je je beter op de vraag achter de feature request en laat je degene die het verzoek indient, nadenken over de toegevoegde waarde. Dit is echter nog niet voldoende. Als je zegt: “Ik als klant wil geld overmaken op mijn telefoon zodat ik overal en altijd zaken kan doen”, behelst dit voor een programmeur wel wat meer dan een paar regels code.
Conversie en contact
Hier komt de conversatie om de hoek kijken. Programmeurs, designers en projectmanagers dienen contact te hebben met eindgebruikers, stakeholders en subject matter experts. Zo stellen ze meteen vast wat de scope van deze feature request omvat en welke beren hier op de weg lopen. Deze conversaties verfijnen de user story en geven na verloop van tijd meer en meer detail.
Een goed verhaal
Wat tot slot een goede user story maakt is de confirmation. Aan welke eisen moet de user story voldoen om vast te stellen dat deze voltooid is? Als iemand zegt: “Ik als klant wil dat de site meer flair heeft zodat ik meer klanten krijg” is het uitzonderlijk moeilijk om vast te stellen wanneer dit doel behaald is. Een voorbeeld als geld overmaken op je telefoon, is meteen met geautomatiseerde tests vast te stellen. User stories afsluiten is even belangrijk als ze inschieten.
Gebruik user stories om verlangens en feature requests te toetsen aan de werkelijkheid en waarom deze toegevoegde waarde heeft voor de gebruiker. Dit zijn uiteindelijk degenen die waarde aan je product ontlenen. Als de klant dus de volgende keer vraagt om alles lichtblauw te maken omdat zijn dochter van Frozen houdt, overweeg voor zijn dochter de Frozen blokfluit set aan te schaffen, zodat hij dag-in-dag-uit kan horen wat wel een goede user story is.
Samenwerken?
Klaar om samen het maximale uit jouw organisatie te halen? Neem contact met ons op!
- Samen online succes behalen
- Ontvang vrijblijvend persoonlijk en professioneel advies
- Meer dan 20 jaar online ervaring
Comaxx neemt je privacy serieus, dus we gebruiken jouw persoonsgegevens alleen voor administratieve doeleinden en om de producten en services te leveren die je bij ons opvraagt. Uitschrijven kan op elk gewenst moment. Zie hier het volledige cookie- en privacybeleid.
Wij realiseerden
extra online groei voor:
