UX en Service Design

UX – van journey naar ontwerp

UX en Service Design

Zal ik heel eerlijk zijn? Toen customer journeys een paar jaar geleden in zwang kwamen, was ik geen fan. Waarom? Omdat ik voorzag dat het het einde van de persona zou zijn. Voortaan werkten we weer met de anonieme ‘customer’. Daar heb ik ook gelijk in gekregen, er was nog een trend met de wat laffe ‘proto-persona’, maar verder hoor je er nog maar weinig over, toch? 

Het voordeel van customer journeys
Ik vind dat nog steeds jammer, maar op het gebied van journeys ben ik ondertussen wel flink bijgedraaid. Wat ik een paar jaar geleden niet inzag, is dat een customer journey vooral een praatplaat is.

Ontwerpers gaan al snel de diepte in. Maar wanneer informatie te specifiek is, haken veel andere mensen binnen de organisatie gewoon af. Met een customer journey heb je een handige verhaallijn om je doelen in de juiste context te plaatsen. Niet meer, niet minder.

De kleine lijn
Ingewikkeld hoeft dat niet te zijn. Ook bij kleine projecten zoals het aanpassen van informatie op een pagina, werk ik met een ‘journey’. Dan teken ik het gewoon in een sessie uit.

Wanneer het om een document gaat waar meer mensen over langere periode mee gaan werken, mag het er natuurlijk wel wat strakker uitzien. Dan werk ik vaak in deze vorm:

  • Data
  • Scherm
  • Klantactie
  • Klantbehoefte
  • Pijnen
  • Emotie/quotes
  • Kansen

En dat ziet er dan zo uit:

Daarbij kan het zijn dat ik, afhankelijk van het onderwerp en doelgroep, onderaan andere stroken informatie toevoeg. Dat kunnen schetsen zijn, of trends, of data, alles wat specifiek voor een workshop relevant is. 

En dat komt nauw. Want wanneer de journey ‘te groot’ wordt, krijgen mensen een informatie overload. Is ze te klein, dan krijgen de mensen te weinig informatie en komt er te weinig uit zo’n sessie. 

De belangrijkste vraag voor de uitwerking blijft dus altijd: hoe simpel kun je het houden om het doel van de sessie te bereiken. 

UX – Belastingaangifte online

UX en Service Design

De belastingdienst is al twee jaar bezig om mij digitaal te krijgen. Op zich heb ik daar niets op tegen, ik was dit jaar zelfs behoorlijk tevreden hoe gemakkelijk ik mijn belastingaangifte kon invullen. Totdat ik digitaal had betaald..

Ik dacht dat ik klaar was, maar twee weken daarna kreeg ik een brief met acceptgiro: betalen a.u.b. Alsof ik niets gedaan had! Ik keek meteen op mijnbelastingdienst.nl maar daar was niets te vinden. Het leek wel of de site bevroren was sinds ik mijn aangifte had verzonden.

Ik checkte mijn overschrijving bij de bank: datum, bedrag, rekeningnummer, referentie, alles klopte. Was er nou iets misgegaan? Toch maar even de belastingtelefoon bellen. Na twee keer het keuzemenu doorlopen te hebben om vervolgens toch afgebroken te worden, kreeg ik van klantenservice het antwoord: mijn betaling was binnen, maar het klopte dat daar digitaal niets van te merken was: “Dat komt nog.”

Ik zit lang genoeg in de IT om te snappen hoe dat komt: er zijn prioriteiten gesteld bij het iteratief ontwikkelen. Maar ik zit ook lang genoeg in UX om te weten dat je het zo niet moet doen. Wanneer je de klant centraal stelt, zorg je ervoor dat processen een kop en een staart hebben, je stopt niet net voor het einde! Voor de klant eindigt de reis zo met onrust.

En dat kost ook geld, want reken maar dat ik niet de enige ben die hierover belt. Dat geld hadden ze ook aan communicatie vooraf kunnen besteden, om de onrust te vermijden.

Zo zie je maar, ze kunnen het best wel leuker maken.

Wat doet een UX designer?

UX en Service Design

Een beetje UX designer weet niet precies wat hij of zij is, daar is het vak veel te breed voor. Daarom is al jaren terug de term UX unicorn uitgevonden, dat magische wezen dat alles kan wat maar met ‘user experience’ te maken heeft.

Wat de unicorn voor UX is, is de T-shape voor de rest van de wereld. T-shaped is een metafoor om je professionele vaardigheden te beschrijven waarbij je ‘in de breedte‘ meer dan een expertise hebt (horizontaal), maar binnen die expertises op bepaalde onderdelen gespecialiseerd bent (vertikaal).

Zo’n term is dus op maat gesneden voor een UX designer zou je zeggen, maar veel vind je er toch niet over. Ik kom online alleen het model van Peter Boersma tegen en dat stamt al uit 2004! Zijn T-shaped model voor User Experience Design ziet er zo uit:

We zijn ondertussen een aantal jaren verder, maar qua model is het nog behoorlijk actueel. Het enige onderdeel wat ik er in mis, is ‘Animation design‘, wat niet meer weg te denken is sinds mobiel de standaard is geworden.

Tegelijkertijd is deze indeling zó veelomvattend dat echt niemand verstand van al die onderdelen kan hebben. Grofweg zie ik binnen dit model twee type UX’ers (procesontwerp en applicatieontwerp) én een Online Marketeer terugkomen. Ik zou zelf Marketing uit het model weglaten en het model indikken tot alles wat met ontwerp te maken heeft:

Voila, dit is het spectrum waarbinnen een UX designer zich al jaren begeeft. En dan zijn jullie vast heel benieuwd hoe T-shaped ik dan ben? Hieronder zie je waar ik mij in thuisvoel:

Voila, het is wel duidelijk dat ik een proces designer ben. Waar je mij dan ook het beste voor kunt bellen, is voor het opbouwen van een goed verhaal. En dat komt dan weer omdat ik niet alleen UX designer maar ook striptekenaar ben. Ik ben niet T-shaped maar π-shaped.

UX – Zoeksuggesties

UX en Service Design

Als er een ding is wat wel onderschat wordt wanneer het over user experience gaat, dan is het wel de zoekfunctionaliteit op je site. 

Ikzelf heb nogal een zwak voor het doorspitten van gebruikte zoektermen, je komt heel dicht op de huid van de gebruiker. Soms typen mensen hele zinnen, alsof ze met klantenservice bellen. Soms zijn de zoektermen met CAPSLOCK geschreven. Dan vraag ik mij af of ze kwaad waren of dat ze moeite hebben met typen (steeds hoofdletters moeten typen met reuma bijvoorbeeld is geen pretje). Een ander voordeel van zo’n onderzoek naar zoekresultaten is dat je meteen kan testen wat voor pagina’s de mensen uit kwamen en hoe onlogisch dat kan uitpakken.

Zoeksuggesties
Vaak worden er al zoeksuggesties gegeven, voordat mensen klaar zijn met typen: de ‘autosuggest’. Google is er heel goed in, andere bedrijven vaak minder. Het kost namelijk best veel energie om goede suggesties te geven. kijk maar eens naar deze twee verschillende zoeksuggesties op npo.nl:

Zie je de verschillen? Wanneer je op ‘twee‘ zoekt, krijg je geen ‘2 voor 12‘. Bij nader onderzoek kwam ik er achter dat op npo.nl overal consequent cijfers in de naam van dit programma gebruikt worden. En dat is jammer, want op allerlei andere plekken online wordt het wel zo geschreven. Zo kun je bijvoorbeeld in de App store wel naar ‘Twee voor Twaalf‘ zoeken.

Het resultaat?
Ach, we vinden het programma steeds wel weer bij Uitzending Gemist, maar deze ‘fout‘ maken we ook steeds weer. Dus typen we twee keer, eh 2 keer. De oplossing ligt voor de hand: gebruik een synoniemenlijst waarbij er bij een zoekterm ‘Twee‘ ook naar ‘2′ wordt gezocht. Voor sites die zo afhankelijk zijn van zoeken als npo.nl zou dat een no-brainer moeten zijn.

UX – Kies je taal

UX en Service Design

Een kennis stuurde mij deze foto met de vraag op welke manier je ‘Nederlands’ kiest. Mijn eerste impuls was om op het vlaggetje zelf te klikken. Mijn tweede gedachte was de grijze knop linksboven. Maar het antwoord is de linksonder op de grijze knop!

De enige manier om dat te zien, is door het grijze lijntje buiten het kader te volgen. Ik denk dat de ontwerper een beetje gehuild heeft toen hij dit moest verduidelijken.

Het was natuurlijk duidelijker geweest om het Nederlandse en Engelse vlaggetje om te draaien. Maar ja, dan was Engels de eerste optie in een Nederlandse bus geweest. Fascinerend dat er op zo’n klein scherm al zoveel dilemma’s af te lezen zijn.

UX – Agile training

UX en Service Design

“En, jullie hebben hier zeker wel een heel goed gevoel over?“, zo vroeg de trainer tijdens de agile sessie.

Nou nee, dat had ik niet. We hadden zojuist in de derde sprint onze doelen gehaald. Dat wil zeggen: we hadden het aantal legohuizen gebouwd waar we ons aan gecommitteerd hadden. Maar de huizen waren steeds slechter geworden, ze vielen bijna uit elkaar.

De oefening om een stad te bouwen was bedoeld om de groep het gevoel te geven hoe je de hoeveelheid werk inschat en daarna samenwerkt om dat werk ook te verzetten. Maar er was een probleem: we zagen al meteen dat er niet genoeg materiaal voorhanden was om de klus te klaren. “Ach jawel” zei de trainer.

Sprint 1
De eerste sprint  ging alles prima. We hadden een realistische inschatting van het werk. De eisen waren dat het ‘uniforme’ huizen waren (een kleur, even hoog etc) en daarom pasten we het tweede huis nog binnen de sprint aan. Resultaat: we hadden binnen een sprint zowel een standaard ontwikkeld als de productie gehaald.

Sprint 2
Maar die standaard was in sprint 2 al niet meer te halen. We kregen de huizen nog wel in een kleur, maar we moesten smokkelen met de hoogte en gaan smokkelen met de legosteentjes: de huizen waren lang niet meer zo stevig als de set uit sprint 1. Wel was onze productie een stuk omhoog gegaan.

Sprint 3
In sprint 3 gingen in overleg met de trainer (de klant) de kwaliteitseisen nog verder omlaag. De huizen hoefden nu niet meer in dezelfde kleur. Maar dat was niet genoeg. We moesten nog meer kleine stukjes aan elkaar plakken en we verborgen een gat achter papier. De huizen waren tijdens het bouwen verschillende keren ingestort maar we haalden onze deadline. Onze productie was weer omhoog gegaan; na drie sprints stond de volledige stad. Maar aan de achterkant zagen de huizen er in sprint 3 nogal krakkemikkig uit:

Ik had medelijden met de toekomstige bewoners. Gegarandeerd dat een aantal een dak op hun hoofd zouden gaan krijgen.

Wat kunnen we hieruit leren?
Dat ‘agile’ niet automatisch garant staat voor goede producten. Voor de opdrachtgever waren hier namelijk maar twee criteria doorslaggevend:

  1. De vooraf gestelde kwantiteit
  2. De snelheid van werken

Agile en ontwerp
Maar is dat dan agile werken? Natuurlijk niet. Het had ook helemaal anders kunnen gaan.

In het begin was er al een inschatting gegeven dat het materiaal niet toereikend was. We hadden de opdracht ook anders kunnen in gaan vullen: bijvoorbeeld door meer flats te bouwen i.p.v. losstaande huizen. Daarmee was de échte doelstelling (mensen fatsoenlijk huisvesten zonder dat ze verongelukken) beter gehaald.

Of we hadden meer tijd moeten nemen om een type woonhuis te ontwikkelen met minder materiaal: een fatsoenlijk Minimal Viable Product dus. Daarmee waren we in het begin langzamer geweest, maar op het einde sneller met een betere kwaliteit.

Beide opties waren hier uitgesloten omdat:

  1. De opdrachtgever vooraf de vorm al in zijn hoofd had. En daar bleef hij aan vasthouden toen het project onder druk kwam te staan. Niet de kwantiteits-maar de kwaliteitseisen gingen omlaag.
  2. Er was geen tijd om te prototypen voordat het product de markt opging.
  3. En was er ook geen tijd om het ontwerp gaandeweg te verbeteren: we konden niet testen .

Kortom: de opdrachtgever hield totaal geen rekening met de beslissende rol die ontwerp binnen agile speelt om een goed product te maken.

Zo zie je maar, software blijft mensenwerk, welke procedure je ook maar toepast. Wat dat betreft was het voor mij een erg verhelderende training.