UX – A plea for some inefficiency

Illustratie, UX en Service Design

It used to be quantitative data and qualitative data, the what and the why. Today it’s big data and thick data. Big data is véry big these days. But it’s not enough to get a complete picture. So I drew this story why it’s still essential to pay attention to the other kind of data: why you need to get out of your head and have real conversations with your customers.


De UX-designer in een agile team.

UX en Service Design

De afgelopen maanden werkte ik als interactie ontwerper binnen een agile ontwikkelteam. We werkten aan een bestaand project wat verder moest worden ontwikkeld, een situatie waar agile development zich prima voor leent. Het werk is erg leuk, maar ik merk ook in deze werksituatie dezelfde tendens die ik al beschreef in mijn blog over ’ontwerpers in het agile tijdperk’:

  • Er is weinig tijd om afstand te nemen.
  • De nadruk ligt op het bouwen van functionaliteit: er wordt meteen in schermen en code gedacht.

Het is logisch dat het proces zo snel gaat, want er moet een team door kunnen werken. Maar daardoor wordt er wel snel doorontwikkeld op oplossingen die misschien helemaal niet zo’n goede oplossing zijn. Een belangrijk deel van mijn werk is dan ook om dat proces af te remmen. Dat begint dan vaak met het herformuleren van user stories;

De bezoeker wil een landingspage om een overzicht van zijn werkstromen te zien

herformuleer ik tot:

De werknemer wil inzicht in zijn werkstromen omdat..

En dan praten we over wat nou écht de reden is dat zo iemand zijn werkstromen wil zien. En dan pas bekijken we of de oplossing nou een landingspagina moet zijn of dat een andere oplossing niet veel beter is. Er worden veel te snel functionele oplossingen bedacht voor problemen die juist met de organisatie van de content te maken hebben.

Zo’n remmende rol is niet gemakkelijk, er staan ten slotte wel een groep programmeurs met de vingers boven het toetsenbord te wachten. Maar ik moet zeggen dat het enorm gewaardeerd wordt, zowel door de klanten als door de ontwikkelaars. Dus voor alle UX ontwerpers die in deze hectische rol komen: ga ervoor en durf de rem erop te zetten. Het levert uiteindelijk beter werk en tevredener klanten op.

UX – Storymapping

UX en Service Design

Ik ben momenteel veel bezig met storymapping. Dit is een mooie vorm om in teamverband wensen en oplossingen in kaart te brengen. Zie het als een backlog waarbij horizontaal wensen op procesniveau worden geordend en vertikaal de prioriteit wordt aangegeven. Zo’n storymap komt er dan zo uit te zien:

De sessie

  1. Ten eerste; gebruik zoveel mogelijk de user story vorm: Als {doelgroep} wil ik {dit kunnen doen} om {dat te bereiken}.
  2. Definieer de doelen die je wil bereiken
  3. Omschrijf per doel de activiteiten om die doelen ook te bereiken. Orden die horizontaal op chronologische volgorde. Voorbeeld: wanneer je schoenen wil kopen, wil je eerst schoenen bekijken en vervolgens bestellen.
  4. Splits de activiteiten weer verder op in deeltaken, bijvoorbeeld ‘de schoen bekijken’, ‘kleuren vergelijken’, ‘de maat checken’, ‘prijs beoordelen’, enzovoort. Al deze taken zijn kleine user stories.

Prioriteiten

Alle taken (de gele briefjes in mijn tekening) vormen de uiteindelijke backlog. Het enige wat je nu nog moet doen is je Minimal Viable Product bepalen. Dat doe je zo:

  1. Orden alle taken naar beneden toe op prioriteit, de belangrijkste bovenaan
  2. Trek een horizontale streep onder alle user stories die absoluut nodig zijn om je eerste versie van het product op te leveren: dat is je MVP.
  3. Daaronder kun je nog meer onderverdelingen maken; dat worden je latere releases, al kan het natuurlijk zijn dat prioriteiten daar nog flink gaan schuiven. Hier kom je dus later op terug.

Dat is het.. mooi he? Ik ben erg tevreden met deze methode. De storymap is voor mij de inhoudelijke verbinding tussen UX en backlog. Er zou veel meer gebruik van moeten worden gemaakt.