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 – Probleempraters

UX en Service Design

Soms kun je veel van je dochter van tien leren. Een paar maanden geleden hebben we een nieuwe fiets voor haar gekocht. Ze was er ontzettend blij mee, want de oude fietste veel te zwaar.

Dus waarom wil ze deze week per se op die oude fiets naar het schoolkamp? 15 kilometer op een logge fiets waar ze altijd een hekel aan heeft gehad? Ze wuifde al mijn argumenten weg; het moest en zou die oude fiets zijn. Ik werd er gek van. Waarom geloofde ze mij nou toch niet? Daar kwam ik pas achter toen ik ophield met argumenteren en door ging vragen waarom ze dat nou per se wilde..

En wat bleek? Ze was helemaal niet bezig met welke fiets het beste was. Ze was bezorgd dat ze op haar nieuwe fiets niet genoeg spullen mee kon nemen. Alleen omdat op de oude fiets nog fietstassen zaten, wilde ze die hebben! Ze had dus een uitstekende oplossing voor haar probleem bedacht en daarmee was het voor haar klaar.

Ik denk dat het in het bedrijfsleven er ook heel vaak zo aan toe gaat. Begin dus, wanneer je een probleem bij een oplossing signaleert, eerst met vast te stellen of de ander het over de oplossing van hetzelfde probleem heeft. Dat scheelt een hoop communicatieproblemen :).

UX – Design Principes

UX en Service Design

Ik gaf afgelopen week een workshop aan het SintLucas in Noord Brabant. Een klein jaar geleden had Evident met deze school de strategielijn voor de ‘Online Creative Community’ ontwikkeld en deze week pakten we daarop door. We gingen in een week tijd niet alleen een plan van aanpak voor de Community bepalen, maar ook een conceptontwerp voor een eerste applicatie maken. Een ambitieus plan en ik had serieus mijn twijfels toen ik er aan begon, maar de week was erg leuk en succesvol. Daarvoor waren er twee redenen:

  1. De werkgroep bestond uit fijne, gedreven mensen.
  2. En we hebben sterk de nadruk op Design Principes gelegd

Wat zijn Design Principes?

Design principes zijn richtlijnen die je helpen bij het ontwerpen van je product. Kort gezegd, leg je daarmee vast op welke manier de eindgebruiker je product gaat ervaren. Dat is belangrijk voor een enkel product, maar het wordt nog belangrijker wanneer je meerdere producten binnen een platform gaat ontwikkelen. Wanneer je de samenhang daartussen wil garanderen, dan moeten er regels zijn waar iedere ontwikkelaar zich aan moet houden.

Ik zie Design Principles als ontwerpregels op strategisch niveau. Voorbeelden? Kijk maar eens bij Android, Windows of bij Apple.

Toen ik in de werkweek uitlegde wat Design Principles zijn, kreeg ik natuurlijk ook kritische opmerkingen. Terecht, want of je nou Android, Windows of Apple gebruikt, je komt altijd programma’s tegen die niet bepaald aan de regels voldoen. Wat voor nut hebben zulke principes nou wanneer bedrijven zich er niet aan houden? Zijn ze niet een beetje ‘idealistisch’?

Misschien wel, er zijn altijd factoren waardoor een product niet wordt wat je ervan had verwacht. Maar dan nog heb je er veel aan om zulke principes vastgelegd te hebben. Je hebt namelijk niet alleen spelregels nodig om een spel te spelen maar ook om om over het spel te kunnen praten.

Design Principes dienen vooral de communicatie

Dat laatste is hetgene wat ik deze week als het meest bijzondere heb ervaren. De groep op SintLucas bestond uit directieleden, docenten, studenten en mensen uit het bedrijfsleven. Ik was verrast hoe vaak ze de design principes aanhaalden om richting aan discussies te geven, weerstand weg te nemen en beslissingen te nemen.

Daarbij werd ook heel duidelijk dat er twee het belangijkste waren:

De eerste stap

Design principes zijn geen garantie voor een fantastisch product, maar ze zijn wel een voorwaarde. Die eerste voorwaarden zijn bij SintLucas benoemd, ik ben heel benieuwd wat er verder gaat komen. Meer weten over Design principes? Op designprinciplesftw.com vind je een geweldige set om op verder te werken: UXaxioms.

UX – Ontwerpers in het agile tijdperk

UX en Service Design

Hebben jullie het al gemerkt? De functionele ontwerper is verdwenen. Door de enorme populariteit van ‘agile’ worden er geen functionele ontwerpen meer geschreven. Wat doen die mensen dan nu? Veel functionele ontwerpers zijn scrummaster geworden. Waren ze eerst de architecten van een ontwerp, nu lijken ze meer op een coach die het team en de klant inhoudelijk houvast biedt.

Een agile aanpak biedt veel voordelen: teamwerk, snel schakelen, niet kapot ontwerpen, gemakkelijker van inzicht kunnen veranderen. Allemaal hartstikke mooi, maar ik hoor weinig mensen over de nadelen praten:

  • Geen tijd om eens rustig over je aanpak na de denken.
  • Daardoor geen duidelijke visie op de lange termijn
  • Geen gestructureerde documentatie voor wanneer een project twee jaar later opnieuw wordt opgepakt en alle mensen uit het oorspronkelijke team zijn verdwenen.

Agile en UX

Maar niet alleen de functionele ontwerper is omgeschoold, ook de interactie designer en visual designer worden anders ingezet. Ze zijn nu allemaal onderdeel van het team waarbinnen gezamelijk de beslissingen worden genomen. En ook daar zitten voor mij een paar pijnpunten:

  • Hoeveel tijd hebben ontwerpers binnen een sprint?(Ik ken weinig situaties waarin ze full time betrokken zijn, dat is te duur)
  • Hoe zwaar weegt hun expertise binnen een team? (Nu lijkt het erop, dat ze er vooral bij zitten voor wanneer de programmeurs iets nodig hebben)
  • Hoeveel tijd en ruimte hebben ontwerpers om eens even na te denken, om uberhaubt een visie te ontwikkelen?

Bezint eer gij sprint

Dat moment om na te denken is natuurlijk wel benoemd: soms wordt dat sprintX genoemd, anderen wijzen naar sprint0. Maar hoe ze het ook noemen, de invulling ervan blijft vaak vaag (iets met een Minimum Viable Product en prioriteiten stellen). De intentie is ten slotte om zo snel mogelijk ‘echt’ te beginnen.

En daar zit volgens mij een groot probleem: de gedachte is namelijk dat je pas echt begint, wanneer je code schrijft. Een denkrichting uitproberen, daar een prototype van maken en het idee testen? Veel te duur! Dan ‘heb je nog niks’… Er wordt dus te weinig ruimte gemaakt voor sprints waarin aannames testen belangrijker is dan de ontwikkeling van het eindproduct. Jammer, want het loont echt wel om te testen of je gebruikers je ontwerp wel wíllen gebruiken.

Niets nieuws onder de zon, maar wel nieuwe kansen

Maar dat is niets nieuws natuurlijk. Er werd vroeger wel veel tijd besteed aan het ontwerp en documentatie, maar ook toen werd niet gekeken of een idee echt werkte totdat het online stond (en dan nog…).

De agile aanpak sluit in wezen veel beter aan op User Centered Design dan de watervalmethode. We kunnen met deze aanpak sneller ideeën ontwikkelen, sneller testen, sneller bijstellen, allemaal geweldig! Agile is juist bedoeld om van inzicht te kunnen veranderen, neem daarom conceptontwikkeling daarbinnen serieus:

  • Geef toe dat je het allemaal nog niet weet!
  • Durf te experimenteren en te varieren!
  • Test je ideeën!
  • Durf ideeën weg te gooien!

De toekomst

Hoe ontwikkelen we over twee jaar software? Ik heb eerlijk gezegd geen flauw idee. Misschien wordt agile weer even hard de kast in geduwd als het er nu is uitgetrokken. Ik verwacht dat het gebrek aan documentatie in ieder geval hard gevoeld zal worden. De functioneel ontwerper komt daarom wel terug, niet alleen als coach maar ook als verslaggever; de journalist van het project.

Welke rol UX ontwerpers, visual designers en interactie designers gaan hebben, vind ik moeilijker te voorspellen. Maar ik hoop dat ze het allemaal heel druk zullen hebben met conceptontwikkeling in een agile werkvorm.

UX – Software gebruikers

UX en Service Design

Laatst liep ik een dagje mee bij een bedrijf om te kijken wat de werknemers daar op een dag doen. Ze maken gebruik van een oude applicatie die ze dolgraag willen vervangen.

Het was geweldig om te zien hoe de mensen rondom alle problemen van de software heen werkten, ik hoorde de hele tijd ‘maar dat is geen probleem hoor’. Wanneer mensen dat zeggen, weet je namelijk zeker dat er een probleem is. Maar mensen vinden altijd manieren om hun werk voor elkaar te krijgen. Sterker nog: als je zo met software om kan gaan, ben je specialist!

Maar die ervaring en gewenning van gebruikers levert bij het ontwerpen voor een nieuwe applicatie ook een barriere op: wanneer je oplossingen voor problemen bedenkt, betekent dat dat de doelgroep opnieuw moet gaan leren. Ik ken niemand die dat graag doet, inclusief mijzelf.

Gebruikers kunnen zelfs meteen een afkeer van het systeem krijgen, ook al zou het, na een leercurve, beter werken.

Daarom de volgende kleine aanbevelingen:

  1. Geef gebruikers de gelegenheid en tijd om een systeem te leren. (Jawel, dit wordt heel vaak vergeten)
  2. Richt je ontwerpproces niet op de ideale werkwijze, maar op de werkelijkheid (oftewel: staar je niet blind op de logica van een proces op zich)
  3. Sta tijdens het ontwerpen steeds stil op wat een oplossing eigenlijk oplevert: soms zijn de praktische oplossingen van de gebruikers echt beter dan de logische oplossingen binnen het systeem