UX – Intelligent design

UX en Service Design

Agile
Ik las laatst nog het agile manifesto eens terug. Wonderlijk hoe compact dat is. Ik wil het in deze blogpost graag over de laatste van de 4 regels hebben:

  • We have come to value responding to change over following a plan

En, niet onbelangrijk, de toevoeging:
“That is, while there is value in the items on the right, we value the items on the left more”

Verandering
Wees flexibel! Hou je niet star aan een plan vast! Ik ben het daar helemaal mee eens, maar.. er staat niet dat je géén plan moet hebben. Toch merk ik dat er bij agile soms het idee ontstaat dat er geen plan meer nodig is en dientengevolge ook geen ontwerp.

Wanneer je lang genoeg aan een product schaaft en het in de praktijk test, krijg je uiteindelijk een super efficiënt en prachtig vormgegeven product, toch?

Doelmatigheid
In theorie wel. Maar ik ken in de praktijk alleen maar één voorbeeld waarbij dit echt zo werkt: de evolutie. Die heeft alleen wel een paar kenmerken die in het bedrijfsleven nooit voorkomen:

  • Het duurt miljoenen jaren.
  • En de doelstellingen blijven altijd hetzelfde.

Responding to change
Wie in een organisatie werkt, weet dat doelstellingen even veranderlijk kunnen zijn als het het weer. Daar zit dus het addertje onder het gras: want wat is ‘responding to change’? In de ideale situatie is dat het inspelen op het gedrag van de gebruiker. In de realiteit zijn dat ook andere dingen zoals onverwachte technische complexiteit, politieke beslissingen en tijdsdruk: bedrijfsperikelen dus.

Visie ontwikkelen
Wanneer je product steeds verandert omdat je interne doelen steeds veranderen, krijg je geen goed product. Om dat tegen te gaan moet je als bedrijf snel een stevige visie neer kunnen zetten. En bij visie hoort visualiseren, durf te ontwerpen!

Geen snellere manier om je visie neer te zetten dan te prototypen, te testen en je conclusies daar uit te trekken. Agile maakt ontwerp helemaal niet overbodig, integendeel. Juist aandacht voor design zorgt voor de juiste mindset om snel te schakelen.

Design om na te denken, niet voor de vorm.


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.


UX in agile development

UX en Service Design

Ik had een tijdje geleden een leuke discussie met een vriend over agile
en structuur. Hoe veel voordelen agile ook oplevert, er zijn ook risico’s: te weinig overzicht bijvoorbeeld; een backlog als een bak legosteentjes waaruit elke sprint voldoende gegraaid wordt om te bouwen,
brrr!

image

Scaled agile framework

Een dag later kreeg ik een link naar het Scaled Agile Framework, een model om agile in een lange termijnvisie in te bedden. Het is een mooi model, maar ik werd als UX designer niet erg warm van de plek van UX in het geheel. In de bijbehorende blog staat er eigenlijk alleen de functie van UX designer beschreven:“The UX Designer(s) provides UI design, UX guidelines and design elements for the teams”.  

Nee jongens, dat is het niet helemaal. Ik citeer graag ‘the UX crash course‘ van Joel Marsh:

UX Design (also sometimes called UXD) involves a process very similar to doing science: we do research to understand the users, we develop ideas to solve the users’ needs — and the needs of the business — and we build and measure those solutions in the real world to see if they work.

Dat is toch wel even iets anders, nietwaar? Een UX designer moet veldwerk kunnen doen: doelgroeponderzoek, producttesten met echte gebruikers. Geen UX zonder data uit de buitenwereld dus. Maar hoe pas je dat dan in in een agile werkomgeving toe?

Design sprints

image

Een manier om die buitenwereld naar binnen te halen is het invoeren van ‘design sprints’ binnen je cyclus. Feitelijk las je dan een ‘pauze’ in om je gedurende één week te concentreren op het formuleren van een relevante probleemstelling, het kiezen van een oplosrichting daarvoor en het testen van die oplossing d.m.v. een prototype.

Jared Spool is hier een groot voorstander van en het boek ‘Sprint‘ van Jake Knap, John Zeratsky en Braden Kolwitz is momenteel een grote hit.

Design sprints zijn een prima manier om grote probleemstellingen te tackelen. Maar.. veel UX werk zit hem juist in kleine probleemstellingen en die pak je hier beter niet mee aan.

De UX cycle

image

Ik denk dan ook dat UX een parallel traject kan volgen, náást de agile development circles. Elke sprint levert ten slotte altijd een functioneel werkend blok op. Dat moet dan toch meteen in de praktijk met gebruikers te testen zijn.

UX in een agile proces is dus juist eenvoudig en effectief in te voegen als je maar voldoende iteratief test met de klant.

De voordelen

  • Je krijgt snel feedback of de gemaakte keuzes wel of niet werken
  • De backlog kan snel worden bijgesteld
  • Het agile proces wordt optimaal benut omdat in volgende sprints snel bijgestuurd kan worden.

Want wat je ook doet: wanneer je niet test, weet je nooit of het wel werkt :).


Ook over dit onderwerp op UX matters: How to combine user centered design and agile development

UX – Agile, design en de Mona Lisa

UX en Service Design

Ik was laatst betrokken bij een workshop waarbij ter introductie twee plaatjes gebruikt werden om het verschil uit te leggen tussen ‘incrementeel ontwikkelen’ (de watervalmethode) en ‘iteratief ontwikkelen’ (agile):

A- Incrementeel (waterval):

image

B- Iteratief (agile):

image

De plaatjes willen laten zien dat bij een ‘waterval proces’ alles eerst wordt uitgedacht en je pas helemaal op het einde een werkend product hebt. Bij een agile proces denk je niet alles van te voren uit maar ontwikkel je in stappen een product wat in elke fase ‘werkt’ (zij het in rudimentaire vorm).

De maker van deze plaatjes, Jeff Patton, hield in zijn artikel uit 2007,  ‘Don’t know what I want, but I know how to get it’, een pleidooi voor de agile werkmethode. Het is een prima artikel, al was het maar vanwege de Sex Pistols quote, maar… je kunt duidelijk zien dat Jeff een softwareontwikkelaar is en geen UX ontwerper. 

De plaatjes kloppen niet
Het artikel is al zeven jaar oud, maar het Mona Lisa voorbeeld wordt nog steeds gebruikt. Het wordt denk ik tijd om uit te leggen dat de plaatjes verkeerd zijn. Want waar zijn hier de ontwerpers??

De waterval
Creatieve processen lijken wel magisch. Hoe krijgt iemand de Mona Lisa in zijn hoofd? Wanneer ik naar het watervalplaatje kijk, wordt dat zo uitgebeeld:

image

Voila, bam, daar is ze al, bedacht door een genie! Vervolgens hoef je het alleen nog maar uit te voeren, simpel toch? 

Nee, het is niet zo simpel: er is werk aan om tot zo’n beeld te komen en het is wel erg krom dat dat werk in dit voorbeeld buiten het proces wordt geplaatst. Alle ontwerpgeheimen onthullen gaat hier te ver, maar een tipje van de sluier kan ik wel onthullen. Met ontwerp erbij ziet waterval er zo uit:

image

Agile
Hmm, lijkt dat ontwerpproces hierboven niet heel erg agile? Inderdaad, ik heb het agile voorbeeld ervoor geplakt. Maar dat voorbeeld ís helemaal niet agile, er wordt juist een waterval ontwerpproces uitgebeeld!

Waarom? Hierom:

  1. De functionaliteit en vorm van de eerste versie is volledig gelijk aan de laatste versie. Alles zit er meteen al in. 
  2. De eindvorm is ook al meteen in de eerste versie definitief, ze is alleen ‘mooier geworden’.   

Kijk nog maar eens goed: de eerste Mona kan al kijken, ruiken, lachen, praten, hoofd draaien, neuspeuteren enzovoort. En.. de ze is direct te herkennen als Mona Lisa. Het ontwerp is staat van begin al vast, het wordt alleen maar verder aangekleed.

image

Zo zou agile helemaal niet moeten werken. In de eerste oplevering is een ‘werkende versie’ voldoende en daarbij draait om het bereiken van doelen, niet van functionaliteit. De Mona Lisa is wereldberoemd vanwege haar blik en haar glimlach. De eerste versie had er dan ook best zo uit kunnen zien:

image

Vervolgens ga je als volledig team, ontwerpers en ontwikkelaars tegelijk, aan de slag om tot een eindproduct te komen. Daarbij is de insteek van agile dat je kunt sturen. Uit de eerste versie kan dus uiteindelijk best de Mona Lisa ontstaan (wanneer iedereen binnen het team een genie is), maar het had ook heel goed dit succesvolle product kunnen worden:

image

Voordeel en valkuil
In een echt agile proces weet je dus niet van te voren wat voor vorm er uit komt. Dat is ook de kracht ervan. Maar zo flexibel als ik het hierboven schets (Mona Lisa of Sponge Bob), gebeurt het eigenlijk nooit. De vorm staat meestal wel degelijk van te voren vast. Dat gebeurt dan meestal in een ‘conceptfase’ of een ‘sprint x’, buiten het werkelijke project om. Het ontwikkelen zelf richt zich daarna vooral erop het product ‘werkend‘ te maken, en niet meer op de vorm waarin het moet werken. 

Ik snap het wel; het kost allemaal tijd en geld, maar ik vind het toch jammer. Doordat vorm en project zo uit elkaar getrokken worden, blijft ontwerp binnen een agile proces nog steeds een wat ondergeschoven kindje. Terwijl er zo veel kansen liggen, als je maar durft.