Bij Pixelpillow werken we jaren met User stories, bij de meeste lezers bekend als manier om - vanuit het perspectief van de gebruiker - te bepalen welke functionaliteit software moet bevatten: 'als [gebruiker], wil ik [actie] zodat ik [uitkomst].We merkten steeds vaker dat deze vorm niet voldoet. We zijn daarom overgestapt op het schrijven van Job Stories.
User stories worden al decennia standaard gebruikt bij productontwikkeling. Maar we liepen stelselmatig tegen de volgende problemen aan:
Kort samengevat: een user stories doet teveel aannames over de gebruiker en geeft te weinig informatie over 'waarom' een gebruiker een taak wil uitvoeren.
Omdat User Stories niet werkten, stapten we over op Job stories. Job stories zijn ontwikkeld door Intercom, en komen voort uit de 'Jobs To Be Done' filosofie, die er vanuit gaat dat gebruikers geen features of producten willen, maar dat ze een probleem opgelost willen hebben. Job stories zijn vervolgens een manier om deze 'problemen' te inventariseren en te omschrijven als gebruikerstaken.
Zelf omschrijft intercom het als volgt:If we understood the situation in which people encounter a problem to solve, understand the motivation for solving it, and understand what a great outcome looks like, we were confident that we would be building valuable product for our customers.
In de vorm van een Job Story ziet dat er als volgt uit:
Het schrijven van job stories is een goede manier om te begrijpen wat een gebruiker écht wil bereiken op je website of bij het gebruik van je applicatie. Door het gebruik van job stories kun je een gebruikerservaring (UX) creëren die gericht is op het oplossen van die taken en het bereiken van hun doelen.
Dit helpt om ervoor te zorgen dat je product is afgestemd op de behoeften van elke gebruiker en zorgt ervoor dat je een intuïtieve interface kunt ontwerpen, waarmee gebruikers hun doel snel en gemakkelijk bereiken.
Design Thinking is een methode waarmee je op een iteratieve, gebruikersgerichte manier (design)vraagstukken kunt oplossen. En met deze methode worden vaak producten en/of diensten gemaakt die zijn ontworpen door de gebruiker centraal te stellen (User Centered Design).
Job stories helpen ons om pijnpunten van gebruikers in de huidige UX te identificeren en daar oplossingen voor te ontwikkelen. En dat is direct de overeenkomst met design thinking.
Op het eerste gezicht lijkt een 'job story' behoorlijk op een 'user story'. Waarom maakt deze kleine aanpassing dan toch zo'n groot verschil? Dat is omdat Job stories de focus verleggen van klantgericht naar taakgericht. Daarmee richten we ons niet langer op een - vaak fictieve - gebruiker, maar op de taak die de gebruiker te doen heeft. Hiermee wordt de story objectiever, concreter en geeft — als we deze goed schrijven! — veel meer context over wáárom de gebruiker deze taak wil uitvoeren.
Job stories schrijven is niet makkelijk. Maar als je het goed doet, levert het een bruikbare, praktische lijst met taken op die eenvoudig te vertalen zijn naar concrete features en componenten.
Begin altijd met échte mensen. Zoek uit voor wie je de applicatie of site ontwikkeld en zoek mensen die je kunt interviewen of – nog beter - die je kunt observeren bij het uitvoeren van hun taken. Het is voor je product of dienst cruciaal om erachter te komen welke problemen je gebruikers proberen op te lossen, en waarom.
Stel je gebruiker twee vragen:
💡 Tip
Benoemen wat mis gaat is makkelijk. Vraag de gebruikers dus niet naar hun wensen, maar naar wat hen frustreert bij het uitvoeren van hun taak.
Dus niet:
Wat is de nummer 1 behoefte bij het doen van je belastingaangifte?
maar
Wat is je nummer 1 frustratie bij het doen van je belastingaangifte?
Hierbij is het belangrijk dat je naast het benoemen van de taak (wil ik) ook duidelijk de situatie benoemd waarin de gebruiker zich bevindt (waar en wanneer) en de motivatie (waarom wil de gebruiker deze taak uitvoeren?).
Bij het schrijven van user stories probeerden we altijd zo bondig mogelijk te formuleren, maar dat is bij het schrijven van Job Stories juist niet de bedoeling! We willen de UX ontwerper immers zoveel mogelijk context meegeven over de situatie waarin de gebruiker zich bevindt op het moment dat hij of zij de taak wil uitvoeren.
Dus niet:
'Wanneer ik honger heb' wil ik,
maar
Wanneer ik honger heb, bijna te laat kom en geen tijd heb om zelf eten te maken, wil ik ...
🤔 De Job story heeft geen mogelijkheid voor het benoemen van een type gebruiker omdat we gezegd hebben dat dit niet relevant is. Maar wat nu als er wel een heel duidelijk onderscheid is tussen typen gebruikers en belangrijker, wat als deze duidelijk verschillende taken moeten uitvoeren? Bijvoorbeeld bij een systeem met een backend (beheerder) en een frontend (consument)?
In dat geval heb je het eigenlijk niet over typen gebruikers, maar over 'rollen', die je kunt zien als de situatie waarin de gebruiker zich bevindt. Deze kun je eenvoudig opnemen in de Job Story, op de volgende manier:
Wanneer ik [in mijn rol] als content beheerder mijn blogartikel niet direct af kan ronden,
wil ik deze kunnen opslaan als concept,
zodat ik deze op een later moment kan afronden.
Omdat Job Stories concreter zijn dan User stories, leiden ze sneller naar de juiste (ontwerp) oplossing en is vooraf beter in te schatten hoeveel tijd het gaat kosten om ze te realiseren. Dit helpt bij het prioriteren van functionaliteit (is het deze inspanning waard om dit probleem voor een gebruiker op te lossen?) en maakt het uiteindelijk product gebruikersvriendelijker en waardevoller voor de gebruiker.
Bronnen:
Een user story bestaat uit de volgende onderdelen: een gebruiker, een doel, en de waarde die ze halen uit het bereiken van dat doel. Om een effectieve user story te maken moet je makkelijk te begrijpen taal gebruiken en zo schrijven dat belanghebbenden zich een beeld kunnen vormen van het gewenste resultaat.
De 3 c's van user stories zijn: kaart (card), het gesprek (conversation) en bevestiging (confirmation). De kaart is de schriftelijke beschrijving van een user story, het gesprek is een discussie met belanghebbenden om de details van een user story uit te werken, en de bevestiging is wanneer iedereen het erover eens is dat de user story aan zijn doel voldoet.
Job stories zijn een type user story die de "Jobs To Be Done" filosofie volgen. Ze worden gebruikt om gebruikerstaken te identificeren en te beschrijven in termen van welk probleem ze oplossen. Job stories helpen ervoor te zorgen dat het product dat wordt gebouwd is afgestemd op de behoeften van elke gebruiker en stelt je in staat een intuïtieve interface te ontwerpen waarmee gebruikers snel hun doelen kunnen bereiken.
User stories worden gezamenlijk geschreven door teamleden en belanghebbenden om het ontwikkelingsproces van informatie te voorzien en ervoor te zorgen dat het product dat gebouwd wordt echte problemen voor gebruikers oplost.
User stories zijn een manier om de functionaliteit te beschrijven die je in je product wilt inbouwen. Ze beschrijven welke handelingen gebruikers met je product zouden moeten kunnen verrichten en waarom ze die handelingen zouden willen verrichten.
