Persona's en gebruikersverhalen waren logisch toen klanten en productteams elkaar verre van elkaar waren. Dat is niet langer het geval.

Dit is een gastpost van Alan Klement die beschrijft hoe een team de ontwerptechniek van Job Stories gebruikte om een ​​profielpagina in een product te ontwerpen.

Traditioneel, wie de klant was en wat ze nodig hadden viel onder de verantwoordelijkheid van marketing, bedrijfsontwikkeling of zelfs verkoop. Nadat deze informatie was verzameld, zou het worden gesynthetiseerd in een draagbaar formaat en vervolgens over het hek worden gegooid naar een productontwikkelteam, dat verantwoordelijk was voor het bouwen van het product.

De slachtoffers van dit watervalproces zijn de subtiliteiten die nodig zijn om te begrijpen bij het maken van geweldige producten: causaliteit, angsten en motivaties. Aangezien ontwikkelteams erkennen dat ze dicht bij de klant moeten staan, is het ook aangewezen om betere manieren te overwegen om de empathie van klanten te benutten om producten te maken.

Deze filosofie van focussen op causaliteit, angsten en motivaties wordt Jobs To Be Done genoemd en een gedetailleerde manier om dit concept in een product te brengen, is Job Stories gebruiken om functies, UI en UX te ontwerpen.

Hoe Personas faalt

Het grootste en meest pertinente probleem met Personas is dit:

Persona's zijn denkbeeldige klanten die worden gedefinieerd door attributen die oorzakelijkheid niet erkennen.

Deze kenmerken, meestal in de vorm van demografische gegevens, brengen een team niet dichter bij het begrijpen van het verbruik van een klant, of niet-consumptie, van een product. De kenmerken van een Persona (iemands leeftijd, geslacht, ras en weekendgewoonten) verklaart niet waarom ze die Snickers-bar aten; 30 seconden om iets te kopen en te eten dat de honger voor 30 minuten afwimpelt, verklaart waarom.

Hoe gebruikersverhalen falen

Als gebruiker kan ik mappen aangeven om geen back-up te maken, zodat mijn back-upschijf niet wordt gevuld met dingen die ik niet nodig heb opgeslagen.

Gebruikersverhalen, zoals die hierboven, hebben drie grote problemen:

1. Ze gebruiken Personas.
2. Ze koppelen implementatie met motivaties en uitkomsten.
3. Ze negeren de context, situaties en angsten.

Vaak zal een functie of UX mislukken. Als het werd gedefinieerd door een gebruikersverhaal, dan was het moeilijk om te ontdekken waarom het mislukte, omdat de implementatie gepaard ging met motivaties en uitkomsten. Vanwege de koppeling, hoe kan iemand weten wat er mis was? Was de implementatie verkeerd of waren de veronderstellingen over motivaties verkeerd?

Lees hier meer over de uitdagingen van User Stories .

Voer het Jobverhaal in

Voor het eerst genoemd door Paul Adams hier op het Intercom-blog , en hier ontwikkeld , zijn Job Stories een andere manier van denken over het definiëren van functies, UI en UX. Maar hoe implementeert een team ze in hun workflow?

Hier is een benadering:

1. Begin met de baan op hoog niveau.
2. Identificeer een kleinere baan of banen die helpen bij het oplossen van de hogere functie.
3. Observeer hoe mensen het probleem nu oplossen (welke taak gebruiken ze momenteel).
4. Verzin een Job Story, of Job Stories, die de causaliteit, angsten en beweegredenen onderzoeken van wat ze nu doen.
5. Maak een oplossing (meestal in de vorm van een functie of UI-wijziging) die dat Job Story oplost.

Om te laten zien hoe dit kan werken, moet u nagaan hoe een team de UX en UI van een profielview heeft gemaakt voor een product dat autoverkopers leningen helpt krijgen voor mensen die een auto willen kopen.

Een profielweergave ontwerpen

Het was al vroeg in het ontwerpproces. Het team was aan het bespreken hoe het Dashboard / Home View eruit zou zien en welke functies daar zouden moeten bestaan.

Op een gegeven moment staat Joe, een teamlid, op en tekent een eenvoudig draadframe op het whiteboard. Hij wees naar een doos en zei:

Dit is het profiel van de verkoper.

Het team luistert naar zijn reden voor de profielweergave, maar is niet meteen overtuigd. Ze vragen een reeks "waarom" voor elk specifiek onderdeel en elke omstandigheid voor de profielweergave. Zelfs na al deze vragen, verenigde het team zich niet voor of tegen het idee.

Op dit punt werd de vraag gesteld:

Waarom zou het product een profielweergave moeten hebben? Waarom zou het ergens zijn? Welke informatie zou het moeten weergeven? Welke situaties lost het op? Welke taak doet deze profielweergave?

Om dit op te lossen, werd de functie opnieuw geformuleerd in een proces met Job Stories.

Opmerking: om het kort te houden, zal dit artikel zich concentreren op slechts één taakverhaal voor de profielweergave; in werkelijkheid waren er verschillende werkverhalen gerelateerd aan de profielweergave.

1. Begin met de baan op hoog niveau.

De baan op hoog niveau voor dit product is om een ​​autoverkoper te helpen een autolening veilig te stellen als iemand een auto bij hem koopt. Momenteel moet de koper heel wat moeilijk papierwerk invullen samen met de autoverkoper.

2. Identificeer een kleinere baan of banen die helpen bij het oplossen van de hogere functie.

Om de leningaanvraag correct in te vullen, moeten de verkoper en de koper veel informatie over de auto en de voorwaarden van de lening invullen, evenals de gevoelige financiële informatie van de koper. Omdat de informatie gevoelig is, moet de koper het gevoel hebben dat ze erop kan vertrouwen dat haar persoonlijke informatie veilig is bij de autoverkoper.

3. Observeer hoe mensen het probleem nu oplossen (dwz welke baan ze momenteel gebruiken).

Momenteel, bij het invullen van dit soort informatie, analyseert de koper (meestal visueel) de verkoper en autodealer en leidt deze af als ze betrouwbaar zijn en betrouwbaar zijn. Ze vullen over het algemeen ook hun gevoelige informatie in nauwe fysieke nabijheid, op een stuk papier, met de verkoper in. Dit helpt hen er zeker van te zijn dat de informatie correct wordt ingevuld en zal niet worden doorgegeven aan mensen die er niet naar zouden moeten kijken.

4. Verzin een Job Story, of Job Stories, die de causaliteit, angsten en beweegredenen onderzoeken van wat ze nu doen.

1. Wanneer autoverkopers en hun klanten via het product met elkaar omgaan ...
2. ... klanten willen het gevoel hebben dat ze de organisatie, het proces en de verkoper kunnen vertrouwen.
3. Verkopers gaan er zeker van willen zijn dat hun proces ervoor zorgt dat hun klanten zich op hun gemak voelen ...
4. ... zodat klanten zich veilig voelen bij het invoeren van hun financiële gegevens in een proces.

Het bovenstaande kadert de situatie in een Job Story. Het kan meer worden ingevuld door meer situationele context te bieden - zoals wanneer en waar het wordt ingevuld (bijvoorbeeld thuis of bij de dealer) - en bezorgdheid die elke partij heeft over het hebben en bekijken van een profiel. Meer tips over het maken van Job Stories zijn hier te vinden .

5. Maak een oplossing (meestal in de vorm van een functie of UI-wijziging) die dat Job Story oplost.

Om de bovenstaande taak op te lossen, heeft het team vervolgens besloten welke functies de profielweergave moet hebben en hoe deze moet worden gepresenteerd. Te weinig informatie en de profielweergave lossen de oorspronkelijke taak niet op, en te veel informatie kan negatieve gevolgen hebben. Dus besloten we:

1. Wanneer de klant het product gebruikt, is de profielweergave van de verkoper altijd zichtbaar (om de bezorgdheid van de klant te verminderen dat hij niet fysiek bij de verkoper is).
2. Het profiel zou een afbeelding bevatten van de verkoper, de functie, verkochte auto's en jaren bij het bedrijf (om de zorgen van klanten te verlichten over de vraag of de verkoper bekend is en kan worden vertrouwd).
3. De profielweergave biedt eenvoudige manieren voor de klant om contact op te nemen met de verkoper. Voorbeelden zijn hun telefoonnummer, e-mailadres en een knop die zegt: "Stel een vraag aan [verkoper]" (verlicht de bezorgdheid van klanten over het invullen van het formulier zelf en het krijgen van iets mis).

Hier is een voorbeeld van een oplossing:

Dit is een overzicht van de gebruikersinterface, de taak die elk UI-element uitvoert en welke situatie (n) het oplost.

Nu de gebruikersinterface compleet is, hebben we nu een UX waarin elk element terug te voeren is op het oplossen van een opdracht: zorgen dat de klant zich veilig voelt bij het blootstellen van persoonlijke informatie.

Ontwerp voor echte mensen, ontwerp voor causaliteit

Succesvolle producten ontwerpen betekent observeren hoe echte mensen nu problemen oplossen, de context van de situatie waarin ze zich bevinden verkennen en vervolgens causaliteit, angsten en motivaties begrijpen.

Samengevatte attributen en koppelingsimplementatie met motivaties en uitkomsten zijn afleidingen voor een team. Als het team diep graaft en leert over de taak die een klant moet doen, kunnen ze effectiever oplossingen bedenken. Het gebruik van Job Stories om functies te ontwerpen, UI en UX is een manier om het te doen.

Meer van Alan

Alan is productontwerper en -ingenieur die graag producten maakt en laat groeien. Houd hem in de gaten via Medium , Twitter of zijn homepage .

Ons vierde boek, Intercom on Jobs-to-be-Done , is een verzameling van onze beste gedachten en ideeën over dit onderwerp. Het doel: u helpen te begrijpen wat klanten nodig hebben bij uw product en hoe u die ervaring uiteindelijk kunt verbeteren.