Zelfs de meest geavanceerde systemen zijn nutteloos als gebruikers ze niet kunnen of willen gebruiken. Bij het ontwerp en de bouw van een website, shop of applicatie is het dus superbelangrijk om die gebruikerservaring te doorgronden. Jesse James Garrett beschrijft in zijn model vijf lagen van User Experience die je daarbij helpen.

Wanneer inzetbaar?

Of je nu aan nieuwe features werkt, of een compleet nieuwe webapplicatie ontwerpt, het User Experience model van Garrett is heel schaalbaar en altijd inzetbaar. De enige factor die dan exponentieel groeit is tijd. Het model helpt je strategische beslissingen te nemen, eisen te formuleren aan de informatiearchitectuur en te komen tot een gebruikersvriendelijk visueel ontwerp. Herken je de werkwijze van Proud Nerds hierin? Het is inderdaad voor een belangrijk deel gebaseerd op dit model.

De vijf lagen van User Experience

Het User Experience model bestaat uit vijf lagen: strategy, scope, structure, skeleton, and surface. We beginnen onderaan in het model. Laag voor laag wordt het plan gedetailleerder en concreter. Het is ook goed te weten dat elke laag doorwerkt in de volgende laag. Het een kan niet zonder het ander.

• Laag 1: Strategy
  Strategie vormt de basis van elke site, elke service, elke feature. In deze fase maken we onderscheid tussen de doelen van de organisatie (wat wil jij uit de site halen) en wat de gebruikers uit de site of feature nodig hebben: de user needs.
  Om de organisatiedoelen te achterhalen, gaan we in gesprek met de opdrachtgever. Door in de historie van gebruikersdata te duiken, krijgen we inzicht in de user needs. Waar nodig verrijken we onze kennis met onderzoek onder gebruikers.
• Laag 2: Scope
  De eerste twee lagen gaan vaak hand in hand. Bij de scope-laag duik je in de functies die nodig zijn om de doelen te behalen. Een lijst aan requirements bepaalt de scope, reikwijdte van de te ontwikkelen functionaliteit. Daarbij maak je onderscheid tussen business requirements en user requirements. Deze laag dwingt je al in een vroeg stadium goed na te denken over mogelijkheden en onmogelijkheden. Bij de ontwikkeling van een configurator, kan bijvoorbeeld een user requirement zijn dat je in 3D visualisaties direct de gemaakte keuzes toont. Een business requirement kan zijn dat bepaalde combinaties van opties worden uitgesloten, omdat productie van bepaalde samenstellingen niet mogelijk is.

Business versus user requirements

Nog een voorbeeld om dit te duiden. VVV Nederland wilde het voor zakelijke klanten eenvoudig maken om op grote schaal VVV-cadeaukaarten te bestellen en aan te bieden aan een groep mensen. Bijvoorbeeld als kerstcadeau aan personeel. Die behoefte heeft betrekking op de business requirements. Kijken we naar de user requirements, dan willen we het de eindgebruiker zo makkelijk mogelijk maken om adressen in te voeren. De eis is zo geformuleerd dat de gebruiker de mogelijkheid moet krijgen om bij meer dan 5 adressen een csv-bestand te kunnen uploaden.

• Laag 3: Structure
  In deze laag maken onze interaction designers structuren van hoe de interactie van de gebruiker met het product eruitziet. Ze beschrijven de navigatiestructuur. Denk aan een landkaart die alle pagina’s en de routes ernaartoe beschrijft. En ook beschrijven ze de zogenaamde userflows: hoe de gebruiker van punt a naar b gaat. Bij de ontwikkeling van een webshop is er bijvoorbeeld één hoofdpad dat de eindgebruiker bewandelt en die wij de ‘main buying flow’ noemen. Dat is het pad waarin een bedrijf omzet binnenhaalt. Daarnaast zijn er nog veel meer user flows te beschrijven. Wat als een klant producten wil retourneren? Of zijn account wil wijzigen? Al die paden worden beschreven in user flows. En dan is het aan ons om ervoor te zorgen dat de gebruiker al die flows zonder stoorzenders bewandelt en dus ervaart als ‘happy flows’.

Use case diagram

In sommige gevallen is het voor developers handig om in deze fase ook zogenaamde use case diagrams te maken. Dat zijn diagrammen die inzichtelijk maken hoe de interactie werkt tussen gebruiker en het systeem.

Stel dat iemand van een vervoerder wil weten wanneer zijn pakket aankomt. In een user flow wordt dan gepresenteerd welke stappen de gebruiker doorloopt om de status van de verzending gepresenteerd te krijgen. In een use case diagram wordt daarnaast ook duidelijk welke informatie vanuit relevante systemen opgehaald moeten worden om de gebruiker te informeren. Zo wordt inzichtelijk welke radertjes moeten gaan draaien.

• Laag 4: Skeleton
  En dan is het tijd voor de laag die het hart van UX-designers sneller laat kloppen. Nu we weten wat de requirements zijn, hoe de user flows eruitzien en welke pagina’s nodig zijn, is het tijd voor wireframes. Wireframes zijn sterk versimpelde raamwerken van websites of applicaties waarin pagina-elementen zoals knoppen, tekstblokken, foto’s zijn weergegeven. In deze laag komen alle functionaliteiten tot leven.
• Laag 5: Surface
  De laatste laag betreft het oppervlak van de functionaliteit. De laag waarin visual en motion designers aan de slag gaan en het grafisch design van het eindproduct helder wordt. Compleet met kleuren, vormen, fonts en micro-animaties zoals knoppen en afbeeldingen. Geeft de opdrachtgever een go op dit onderdeel, dan kunnen de back- en front-end developers aan het werk met de ontwikkeling van de functionaliteit.

Voer UX testen zsm uit

In de laatste twee lagen is de uitdaging om zo gebruiksvriendelijk mogelijk te ontwerpen. Met usability testen kun je valideren of een ontwerp daadwerkelijk intuïtief werkt voor de gebruiker. Het advies is om zo vroeg mogelijk in het proces UX testen te doen. Een wireframe is namelijk binnen één uur aangepast. Een wijziging in het design kost ongeveer al tien uur. Zit je al in de staging omgeving, dan kan dit zomaar 100 uur zijn. Dus…