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.

UX – Wireframeprogramma’s zijn uit!

UX en Service Design

Wireframes zijn schematische tekeningen van alle elementen die op een pagina komen te staan. Je maakt wireframes om twee verschillende redenen:

  • In het begin van een ontwerpproces dienen ze als schets voor de klant om ideeën vorm te geven.
  • Aan het eind van een ontwerpproces dient een wireframe als bouwtekening voor de programmeur

De programma’s

Er zijn veel wireframeprogrammas beschikbaar. Ik heb o.a. gewerkt met Axure, Visio en Balsamiq. Het ene programma werkt fijner dan het andere (ik geloof dat ik de enige op de wereld ben, die een hekel aan Balsamiq heeft) maar in wezen werkt het allemaal hetzelfde: je plaatst vierkantjes, tekst en lijntjes op een vlak. Maar.. deze manier van ontwerpen heeft nadelen. Het grootste nadeel is  wel het vertalen van het ene device naar het andere:

Schetsen, schetsen, schetsen..

Ik pak het nu anders aan en er zijn twee boeken die mij daarbij zwaar beïnvloed hebben. De eerste is ‘Sketching user experience’ van Bill Buxton. Ik snapte plotseling dat ik om mijn ideeën te krijgen moest TEKENEN in plaats van hokjes te verschuiven in een programma. Een ongelofelijke open deur, want met striptekenen doe ik het al jaren zo.

Waarom schetste ik weinig? Omdat je efficient met je tijd om wilt gaan en je dus de eerste oriënterende stap graag wilt combineren met de tweede (bouwtekening). Maar sinds ik vooral met potloodtekeningen aankom, merk ik dat de voordelen daarvan veel groter zijn:

  • Potloodschetsen worden als schetsen herkend. Wireframes niet, die worden toch vaak meteen gezien als een definitief ontwerp. Dit gaat op voor zowel de klant als de visual designer.
  • Doordat een schets als een schets wordt herkend, wordt de discussie veel opener. Het wordt ook gemakkelijker geaccepteerd dat dingen later kunnen veranderen.
  • Je bent veel vrijer in je vormtaal, zodat je sneller met een visual designer kunt schakelen.
  • Je kunt sneller verschillende aanpakken uitproberen.

Wireframes als bouwtekening

In de stap van schets naar bouwtekening, maakte ik nog wel gebruik van wireframeprogramma’s maar door ‘Responsive design workflow’ van Stephen Hay probeer ik ook daar (zoveel mogelijk) van af te stappen.

Stephen Hay zijn visie op het ontwerpproces was een ‘dat roep ik al jaren’-ervaring, maar zijn kritiek op wireframes kwam toch als een verrassing. Het is nu eenmaal makkelijker om te zien wat iemand anders verkeerd doet dan van jezelf. Even slikken, maar hij heeft een duidelijk punt: wireframes op papier zijn vaak veel te dwingend in vorm en geven geen realistisch beeld, zeker niet als het om mobiel gaat. Je kunt veel beter zo snel mogelijk naar code toe gaan. De voordelen zijn namelijk enorm:

  • Veel beter inzicht in wat een ontwerp echt in een browser doet.
  • Het is SNELLER. Alle devices kun je testen met hetzelfde ontwerp!
  • En de stap naar een testbaar prototype is natuurlijk ook veel kleiner. (Al moet ik daarbij waarschuwen dat het sneller complexer wordt dan je wilt. Het is niet hetzelfde, maar daar heb ik het vast later wel eens over).

Zijn er nadelen? Zeker, notatie van interacties is bijvoorbeeld niet op het scherm mogelijk. Maar voorlopig kan ik er toch maar weinig ontdekken. Wanneer ik ze tegenkom, zal ik ze hieronder in het commentaar toevoegen.