Job stories in plaats van User stories

Designers moeten niet programmeren, hoor je vaak. Het leidt tot zwakke interfaces, ontevredenBij 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].

Bij Pixelpillow merkten we steeds vaker dat deze vorm niet voldoet. We zijn daarom overgestapt op het schrijven van Job Stories. klanten en torenhoge kosten. Maar is dat wel zo? Ontdek het in dit artikel.

Waarom werken User Stories niet?

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.

De Job Story als beter alternatief

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:

Een klein verschil met een groot effect

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.

Een goede Job story schrijven

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.

Stap 1: Praat met je gebruikers

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?

Stap 2: Herschrijf de input van je gebruikers naar Job stories

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.

Stap 3: Vertaal de Job Stories naar ontwerp oplossingen

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: