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 – Structure first

UX en Service Design

Naast mijn UX werk ben ik ook striptekenaar en via dat beroep ben ik veel bezig met het opbouwen van scenario’s voor verhalen. De belangrijkste les die ik daarbij geleerd heb, is dat het veel belangrijker is dat je weet wat je wil zeggen, dan welke vorm je kiest. 

Content modeling

Maar met een duidelijk geformuleerd doel ben je er nog niet. Wanneer je weet wat je wil zeggen, kun je beslissen hoe je het verhaal gaat organiseren. Het gaat dan nog niet om hoe je het gaat schrijven (vorm) maar wel om welke elementen er in het verhaal voor komen en welke relaties daartussen te leggen zijn. Voorbeelden? Content strategen gebruiken content modeling. Scenario-en romanschrijvers gebruiken matrixen, mindmaps en relatiestambomen.

Ik kan mij voorstellen dat menigeen niet zo opgewonden van dit onderwerp wordt, maar voor mij was het echt een openbaring.  Ik heb zo geleerd hoe ik een idee zowel in cartoonvorm als in een verhaal van vijftig bladzijden kan gieten. Ik ben daardoor vrijer, productiever en (paradoxaal) veel vormvaster geworden. 

Structure first

Dat experimenteren met verhaalstructuren heeft ook mijn kijk op UX design sterk gevormd; ten eerste zie ik content altijd als onderdeel van ontwerp en ten tweede ben ik een stevige aanhanger van het ‘structure first’-principe geworden.

Mark Boulton zegt het heel mooi in zijn artikel ‘Structure first, content always’:

“You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure. What is your content made from, not what your content is. An important distinction” 

UX – Laten we écht beginnen

UX en Service Design

“En, wat vond je ervan?”. Ik had zojuist de tweede versie van het prototype gepresenteerd. In tegenstelling tot de vorige keer waren er in deze sessie nog maar weinig opmerkingen over de flow door het applicatie, die een stuk eenvoudiger geworden was. De hevigste discussies waren geluwd tot een vriendelijke consensus.

Tevreden stelde ik dus de vraag een van de betrokkenen. Het antwoord was dat het een goede sessie was geweest, maar dat we nu toch echt moesten beginnen met ‘functionaliteit te bouwen’. De urgentie die in dat antwoord doorklonk, deed mij denken aan een uitspraak van Stephen Hay:

‘We’re afraid of losing money while we’re thinking’ – Stephen Hay

Wat is functionaliteit?

Wanneer in de IT over functionaliteit wordt gesproken, wordt eigenlijk altijd het eindproduct bedoeld, het product waar de eindgebruiker mee aan de slag kan gaan. In die zin is alles wat met ontwerp en design te maken heeft, nooit ‘af’. Vandaar de perceptie dat het bouwen van de applicatie (het coderen) toch het echte werk is. Een prototype is al snel ’te veel werk’. 

Maar is er in de IT eigenlijk wel ooit een eindproduct? Software verandert voortdurend (of hebben jullie vandaag nog geen notificaties voor updates ontvangen?). Er zijn geen eindproducten in de IT, alleen maar ‘versies‘. Wat je ook bedenkt, ontwerpt of codeert, het heeft altijd maar een beperkte houdbaarheidsdatum. 

Juist de beperking en de vluchtigheid van een prototype maakt haar zo waardevol. Daardoor kunnen ideeën razendsnel bedacht, getest én weggegooid worden. En dat laatste is misschien nog wel de belangrijkste: dat je op tijd ziet dat je idee niet klopt.

De wereld is ten slotte al vol genoeg met ‘functionaliteit’ die:

  • moeilijk te gebruiken is
  • duur is om te onderhouden
  • lastig is om aan te passen

De urgentie om zo snel mogelijk ‘echt’ te beginnen, pakt op lange termijn dan ook vaak veel te duur uit. Alleen wanneer we testen wat we bedenken, besparen we geld.

Van 2015 naar 2016

Strip

Mijn eindejaars-of nieuwjaarskaart (het is een beetje hoe je er tegenaan wilt kijken). Je ziet er wel aan af dat ik 2015 niet zo’n goed jaar vond, zeker niet voor cartoonisten. Het begon natuurlijk met de aanslag op Charlie Hebdo, maar in het verlengde daarvan werd het überhaupt een stuk moeilijker om grappen te maken. Ik wens iedereen in 2016 dan ook vooral een flinke dosis relativeringsvermogen toe.

Gelukkig 2016!

nieuwjaarskaart 2016

UX – Bonnetje

UX en Service Design

Ik geef het maar toe, ik snapte er niets van. Ik stond bij de AH toGo voor de self service kassa. Ik had het product gescand en ik keek naar de pinapparaat. Maar het ding deed helemaal niets; ik wachtte en wachtte, totdat de transactie werd afgebroken. Ik scande het product nog een keer en ging weer aan de gang met de pinautomaat. Weer wachten, weer afgebroken. Ander apparaat uitgeprobeerd, weer hetzelfde… grrrrrr.

Ik bekeek het transactiescherm opnieuw en toen pas zag ik onderaan de pagina twee grote blauwe blokken. Toen ik ze beter bekeek, bleek er ‘betalen wel een kassabon’ en ‘betalen geen kassabon’ op te staan. Hmm, zou dat er wat mee te maken hebben? Inderdaad: nadat ik op een van deze knoppen had geklikt, deed het pinapparaat ernaast het wel.

Je denkt misschien: ‘één scherm, twéé knoppen en allebei leiden ze naar de gewenste actie om te betalen. Wat kan hier nou misgaan?

Nou, ik hoef mij er niet stom om te voelen. Vandaag stond ik weer in die winkel en ik heb drie mensen gezien die hetzelfde probleem hadden: ze zagen de knoppen niet. Is dat een ontwerp fout? Ja en nee.

Wat kan beter?

Ik denk dat het geen goed idee was om de knoppen zo groot en rechthoekig te maken, daardoor zien ze er niet uit als knoppen maar als banners. De houterige teksten (’betalen wel een kassabon’) maken dat niet beter en het effect wordt nog eens versterkt door het milieuvriendelijke plaatje in de knop rechts. Als laatste staan de knoppen ook te ver van de bestellijst af en lijnen ze er links en rechts niet mee uit, je hebt zo niet het gevoel dat ze er bij horen. Dus ja, daar is wel een verbeterslag te halen

Systeem vs mens

Maar er is meer aan de hand. Het is niet alleen een kwestie van de knoppen niet zien, het is ook een kwestie van deze keuze niet te verwachten. We heb jarenlang ervaring met afrekenen aan de kassa met een bediende. In die situatie betaal je eerst. Pas als je daarmee klaar bent, vraagt de kassier/kassière of je een bonnetje wil.

De procesflow is in de winkel dus anders! Wanneer je dat gewend bent, kijk je gewoon niet of je nog wat moet doen: je kijkt meteen naar het pinapparaat.

Hulp

Gelukkig ontbreekt bij de Albert Heijn de menselijkheid niet. Vandaag zag ik ook hoe iemand op de ‘hulp’-knop klikte en schrok toen er meteen een medewerker aankwam om het systeem uit te leggen. Dat was haar intentie helemaal niet, ze had eigenlijk alleen meer informatie op het scherm verwacht

Mensen willen dus best alles zelf afhandelen. Die self service komt wel goed. Maar wel die knoppen herontwerpen graag.