UX – Renderen

UX en Service Design

Ik las een tijdje geleden de toespraak van Ramsey Nasr ter gelegenheid van het ITs festival in Amsterdam; ‘Trap het rendementsdenken van school’

Het is een prachtige toespraak, ik ben het er alleen niet mee eens. Ik denk namelijk dat voor een renderende economie je juist dit soort ‘nutteloze’ dingen moet leren. Niet als alternatief, maar als basis.

Innovatie

Het is al vaker gezegd: onze economie moeten het niet van de goedkope werkkrachten hebben, wij moeten juist creatief ‘innovatief’ zijn. Maar hoeveel kwaliteit het primair en voortgezet onderwijs ook hebben, ik zie te weinig aandacht voor creatief leren denken en werken. 

Mijn dochter leerde bijvoorbeeld wel om een woordweb te gebruiken, maar ze werd op de vingers getikt omdat ze het niet deed ‘zoals het hoorde’. Dat klopte, ik had haar geleerd dat niet elk woord keurig vanuit het midden ontstaat en er ook andere verbanden te trekken zijn. Ik had haar leren brainstormen..  

Stap voor stap imiteren

Hoezeer ik het hedendaags onderwijs ook waardeer, de meeste creatieve opdrachten zijn nog steeds niets anders dan het stapsgewijs namaken van een voorbeeld. Erg jammer, want zo leer je kinderen wel de moeilijkheden van het uitvoeren maar niet de mogelijkheden van het ontdekken.  

Geen wonder dat voor veel mensen ‘creativiteit’ en ‘hobby’ dezelfde betekenis hebben. En geen wonder dat ze later dan ook met die blik naar creatief innovatief werk kijken!  

image

Dat is niet alleen jammer, dat is ook duur. Want het vaderdagcadeau van vroeger wordt de productontwikkeling van later: er is maar ruimte voor één idee waar vervolgens angstvallig aan wordt vastgehouden. 

Juist dat altijd maar door ontwikkelen in dezelfde richting, zonder ooit de oorspronkelijke aanname te toetsen, is een enorme kostenpost in het bedrijfsleven. En dan nog eentje die vaak als succes wordt opgevoerd ook!

Omgaan met onzekerheid

Experimenteren, richting zoeken, nieuwe vormen ontdekken, niet bang zijn van waar je uit gaat komen; ik heb dat allemaal op de kunstacademie geleerd. Ik gebruik het nu in de ICT.

Ik kan mij dan ook werkelijk kwaad maken om het onbegrip en het gemak waarmee alles wat met creativiteit te maken heeft, momenteel wordt weggezet als ‘een linkse hobby’. Niks geen linkse hobby, het is een keiharde competentie die je moet hebben om goede producten te maken. Daarom heb ik als tekenaar én als UX designer deze welgemeende adviezen voor iedereen: 

  • Doe eens gek
  • Geef toe dat je niet alles weet
  • Bedenk meer dan een oplossing 
  • Test je aannames
  • Durf werk weg te gooien. 

Het zal gegarandeerd renderen.

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.