Auteur: Joost Verweij

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

UX – Ontwerp in procenten

UX en Service Design

Het is vaker gezegd: UX ontwerp wordt maar moeilijk begrepen. Veel mensen voelen niet aan dat ontwerp van een moeiteloze gebruikerservaring niet moeiteloos gaat.

Procenten
Zo kreeg ik laatst nog van iemand te horen dat je bij ontwerp 80% hetzelfde kan gebruiken (“best practices”) en dat je dan 20% interactie design of usability bij kan doen om “het verschil’ te maken…

Tja, autobestuurders rijden veel op routine maar je kunt toch echt niet zeggen dat je voor 80% met je ogen dicht kan rijden omdat er maar 20% van de tijd een risicosituatie is waar je het verschil echt maakt. Hoe komt iemand op zo’n idee?

Van scherm naar flow
Ik ga niet op de percentages in, die zijn nergens op gebaseerd. Maar ik snap wel waar die best practices vandaan komen.

image

Natuurlijk zijn er interactiepatronen die zich bewezen hebben: een duidelijk zichtbare hoofdnavigatie bijvoorbeeld. Vreemd genoeg zijn juist dàt de zaken die binnen een design vaak onder druk staan omdat het ‘niet spannend’ genoeg is. Maar het is waar: wanneer heel de wereld de ervaring heeft dat iets op een bepaalde manier werkt, kun je dat beter maar ook zo doen.

Maar waarom is het dan geen kwestie van schermen als een bouwpakket in elkaar klikken?

UX ontwerp is meer dan schermen ontwerpen

UX ontwerp richt zich erop om het gedrag van de bezoeker te beïnvloeden. En dat doe je door informatie en vertrouwen en gebruikersgemak te geven. Dat gaat veel dieper dan een set wireframes produceren. Je kunt het werk het beste te vergelijken met het slim inrichten van een winkel:

image
  • Welke indruk krijgen de bezoekers wanneer ze binnenkomen?
  • Hoe blijven ze geïnteresseerd wanneer ze langs de rekken lopen?
  • Welke routes wil je graag dat ze in de winkel doorlopen?
  • Hoe en waar verleidt je ze tot actie?

En vervolgens test je of de inrichting voor de bezoekers werkt, keer op keer. Een goede UX designer is dan ook de warme combinatie van architect, scenarist en gedragspsycholoog in één.

Teamwerk

Maar een UX ontwerper doet dat niet alleen. Ontwerpen doe je met een team. Wat voor team? De functieomschrijvingen kunnen enorm verschillen, maar in de basis heb je mensen in het team die zich met onderzoek bezighouden (doelgroep onderzoek, informatie analyse en testen) en mensen die ontwerpen (interface, visual design en front end development). De verdeling over mensen hangt af van het soort project en natuurlijk het budget.

Design is kostbaar

Al dat werk kost geld, zeker. Maar het levert ook iets heel belangrijks op: conversie. En dat was toch de reden waarom je als bedrijf überhaubt in een applicatie investeert?

Dus durf te investeren in onderzoek en ontwerp. Durf te meten en te testen. Pas je ontwerp aan wanneer het niet voldeed en test dat opnieuw. Het is de enige echte manier om tot een lonend product te komen.