Design Principles

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 Principles gelegd:

image

Wat zijn Design Principles?

Design principles 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.

Het nut van principes

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 Principles 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 principles aanhaalden om richting aan discussies te geven, weerstand weg te nemen en beslissingen te nemen.

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

image

De eerste stap

Design principles 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 principles? Op designprinciplesftw.com vind je een geweldige set om op verder te werken: UXaxioms.

Voor wie wat meer over de werkweek wil lezen: Op de blog van SintLucas staan een aantal blogposts en een filmpje:

Erg leuk filmpje van de One Week Workshop waar ik deze week behoorlijk hard aan gewerkt heb :). Zeer tevreden

Ontwerpers in het agile tijdperk

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.

Software gebruikers

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

Ontwerp in procenten

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.

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.

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

image

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:

  • 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.

image

Ontwerpteams
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.

Storymapping deel 2, persona’s en user stories

In mijn vorige artikel gaf ik aan dat ik storymapping een prachtvorm vind om agile aan een project te werken, maar dat ik als UX designer niet automatisch er zo mee aan de slag kan.

User stories
Dat heeft veel met de formulering van user stories te maken. Neem nou een user story zoals:

‘ik wil als consument een account aan kunnen maken zodat ..’.

Ik ken helemaal niemand die graag accounts aanmaakt, voor welke reden dan ook. Dit is dan eigenlijk ook geen user story, maar een oplossing die als user story wordt geformuleerd: hier wordt vanuit het systeem gedacht i.p.v vanuit de eindgebruiker.

Ik wil als UX designer een user centered storymap i.p.v. een system centered storymap. Hoe doe je dat? Door bij de persona’s te beginnen:

Wat is een persona ook al weer?
Een persona is een voorstelling van één gebruiker binnen je doelgroep die je zo duidelijk beschrijft dat je team:

  • een echt mens voor zich kan zien
  • zich in de behoefte van die mens kan inleven
  • de context waarbinnen die behoefte speelt, kan begrijpen

Scenario’s
Bij persona’s horen scenario’s. Deze worden vaak weggelaten maar zijn volgens mij juist het allerbelangrijkste. Wat is een scenario? Dat is een beschrijving van een levensechte situatie waaruit blijkt binnen welke context de eindgebruiker een vraag of behoefte heeft. Het is het vertrekpunt om op ideeën te komen, bijvoorbeeld:

ik was mijn sleutel kwijt en toen..

En toen.. en dan.. en daarom.. en dus..

Met een goed beginscenario is je team in de juiste sfeer en kun ze echt beginnen met user stories te bedenken. Durf details op te schrijven, durf emotionele context te geven en werk niet meteen naar een oplossing toe: durf te vertellen.

Hieronder heb ik een voorbeeld geschetst hoe je voor een webshop zou kunnen beginnen:

imageMaar ik hoor mensen al zeggen: ”wat als er nog andere scenario’s zijn?’. ‘wat als we dingen vergeten?’ of ‘wat als we verkeerd zitten?’.

Wel, je vergeet altijd dingen en je zit altijd wel eens verkeerd. Maar dat doe je ook wanneer je juist geen expliciete keuzes durft te maken, het is dan alleen minder voelbaar. Dus begin er maar eens aan, en wees verbaasd waar je plotseling uitkomt.

Don’t be a unicorn

Ik hoorde laatst de naam voor een UX designer die ‘alles’ binnen een bedrijf doet op het gebied van UX design: de UX unicorn.

Laat ik deze blog eens kort houden: een bedrijf wat maar één iemand op het volledige UX spectrum inzet, is een bedrijf wat zich niet met UX design bezighoudt. Aan alle unicorns die in zo’n situatie zitten: sterkte!

Storymapping, deel 1, de agile aanpak

Ik ben momenteel veel bezig met storymapping. Dit is een mooie vorm om in teamverband wensen en oplossingen in kaart te brengen. Storymapping wordt veel bij agile ontwikkelen van applicaties gebruikt. Dat ziet er dan zo uit:

imageBinnen de storymap worden doelen en activiteiten in ‘user story’-vorm opgesteld:

Als {doelgroep} wil ik {dit kunnen doen} om {dat te bereiken}

Je maakt en bespreekt een storymap in groepsverband. In bovenstaand voorbeeld doe je dat zo:

  1. Je hebt een aantal doelen die je wil bereiken
  2. Per doel definieer je activiteiten om die doelen voor elkaar te krijgen. Je ordent die horizontaal op chronologische volgorde. Bijvoorbeeld: wanneer je schoenen wil kopen, wil je eerst schoenen bekijken en vervolgens bestellen.
  3. Die activiteiten kun je weer verder opsplitsen in deeltaken: je wilt bijvoorbeeld de schoen zelf zien, kleuren vergelijken, de maat checken, de prijs beoordelen, enzovoort. Ook dat zijn allemaal kleine user stories.

Die taken (de gele briefjes in mijn tekening) worden de uiteindelijke ‘backlog’. Dat is de lijst van user stories die je in je systeem zou willen gaan maken. Die orden je naar beneden toe op prioriteit zodat je ook ‘releases' kunt bepalen: wat ga je als eerste doen en wat komt de volgende keer.

Wat ook belangrijk is, maar wat je natuurlijk niet in online voorbeelden ziet, is dat een storymap  tijdens het bouwproces verandert: je praat en neemt beslissingen en schuift met prioriteiten.

Agile en UX
Zo’n storymap in deze vorm is prachtig om agile te ontwikkelen, maar als UX designer kan ik er niet automatisch mee uit de voeten. Dat komt vooral doordat user stories vaak niet verder gaan dan ‘ik wil bestellen’ en ‘ik wil een notificatie ontvangen’. Voor UX design wil je als team toch meer nuances kunnen zien:

Wie wil op welke plek en op welk moment op die bestelknop klikken?

imageZeker, je kunt personabeschrijvingen bij je storymap hangen, maar ik vind dat niet genoeg, ik wil dat de nuances ook in de user stories zelf terug te vinden zijn. En dat kan door in de uitwerking van je persona’s daar al naar toe te gaan werken

Geautomatiseerd testen

Geautomatiseerd testen

Over anders kijken

Ik wil het eerst even over koopgedrag hebben. Grofweg heb je twee basisinstellingen bij het kopen van een product:

  1. Je wilt er over nadenken
  2. Of je wilt dat helemaal niet

Je hebt de eerste instelling wanneer je ‘iets nieuws’ wil. Dan ga je actief aan de slag: je kijkt en je vergelijkt, je wikt de risico’s af. De eerste keer dat ik een smartphone uitzocht, ben ik daar avonden mee bezig geweest.

imageHet gaat iets anders wanneer je voor de zoveelste keer hetzelfde moet hebben, bijvoorbeeld in de supermarkt. Dan loop je blindelings naar de juiste plek, je pakt wat je altijd pakt zonder te kijken en hop, je bent bent weer weg.

En dat was ook wat ik deed, toen ik mijn tweede smartphone kocht. Toen wilde ik niets nieuws: de oude begon te haperen en ik wilde snel ‘nog zoiets’. Ik ging meteen naar de site waar ik de vorige besteld had en nam dezelfde. Althans, ik nam dan een versienummer hoger, want dat was vast ook ietsje beter, toch? Ik heb zelden zo’n miskoop gedaan, het was een onding dat in niets op de vorige versie leek.

imageMaar de miskoop is niet het punt. Het punt is dat ik na slechts een keer bewust te kiezen, al op routinegedrag overstapte. En nee, ik ben daar niet de enige in: dat doen heel veel mensen: het kost energie om bewust keuzes te maken en daarom kiezen we zoveel mogelijk (onbewust) voor wat we al kennen. Maar waarom heb ik het hier eigenlijk over?

Omdat bij het ontwerpen van websites en apps mensen ook op de eerste manier bezig zijn. Ze praten intensief en bewust over welke informatie waar moet staan, wat allemaal moet kunnen en wat de logica is tussen al die informatie. Ze zijn namelijk bezig met iets nieuws wat best veel geld kost.

Maar wanneer mensen websites en apps gebruiken, doen ze heel vaak op de tweede manier: niemand die even de tijd neemt om de logica of de bedoeling van de site te doorgronden: net als in de supermarkt klik-klik-klikken ze de richting in waarvan ze denken dat het de juiste is.

Er is dus een reeël gevaar dat bij het ontwerpen van een website er te vlug van wordt uitgegaan, dat de doelgroepen het ontwerp wel zullen begrijpen. De ontwerpers zijn gewoon te bewust bezig :). De enige manier om dat risico te ondervangen is om tijdens de ontwerpfase al met de doelgroepen te testen.