Mijn opa

Wij gingen laatst lootjes trekken met de familie. Mijn opa uit Brabant deed ook mee. Omdat hij zo ver weg woont, deden wij dat via lootjestrekken.nl. Een handige, bruikbare website, vind ik zelf. Maar dat ik weet hoe lootjestrekken.nl werkt, wil niet zeggen dat mijn 85-jarige opa dit ook weet.

Mijn moeder nam de taak op zich om haar vader door dit proces te leiden. De telefoonrekening was die maand dan ook iets hoger dan andere maanden. De truc was om opa duidelijk te maken wiens lootje hij getrokken had, zonder dat mijn moeder er achter kwam wie hij had. Ik kan je vertellen, dat ging niet zoals gehoopt.

Mijn opa en ik zijn deel van twee heel verschillende doelgroepen. Toch wordt er van ons verwacht dat wij weten hoe we moeten omgaan met het internet. Ik vind het niet heel eerlijk dat dit ook van mijn opa wordt verwacht. Hij wist in het begin niet eens hoe hij een mailtje moest openen, laat staan het aanmaken van een e-mailadres.

Vergeet je eindgebruiker niet

Ik ben van mening dat wij, webdevelopers, wel eens vergeten te kijken naar onze eindgebruiker. Natuurlijk is het voorbeeld van mijn 85-jarige opa wel erg overdreven, aangezien hij niet is opgegroeid met computers. Alleen al het werken met een muis is voor hem onwennig. Maar het gaat om het principe. We zijn vaak zo enthousiast over ons eigen product en weten precies hoe ons ‘kindje’ er uit moet komen te zien. Maar wat voor ons logisch is, is niet per definitie logisch voor een hele grote groep andere mensen.

Tijdens het maken van websites doen we net alsof gebruikers aandachtig elke pagina bestuderen, elke geschreven alinea, link en foto bestuderen waarna zij een afgewogen keuze maken om ergens op te klikken. Niks is minder waar. Gebruikers lezen niet!

Gebruikers lezen niet, maar scannen

“The main thing you need to know about instructions is that no one is going to read them—at least not until after repeated attempts at “muddling through” have failed.”

Steve Krug, 2006

In werkelijkheid scannen gebruikers in één oogopslag de pagina, een klein beetje tekst en klikken vervolgens op hetgeen wat hun aandacht het meest trekt of een beetje lijkt op hetgeen waar ze naar zoeken. Er zijn drie duidelijke redenen waarom dit gebeurt:

  1. We hebben meestal haast. Een groot deel van ons webgebruik is om tijd te besparen. Als resultaat veranderen we in een soort haaien: we moeten blijven bewegen, anders gaan we dood. We hebben gewoon niet de tijd om meer te lezen dan nodig.
  2. We weten dat het niet nodig is om alles te lezen. We zijn eigenlijk alleen geïnteresseerd in een klein gedeelte wat op de pagina staat. We zijn opzoek naar die kleine beetjes die overeenkomen met onze interesse en de rest wat op de pagina staat is irrelevant. Door de pagina alleen maar te scannen vinden we deze relevante informatie.
  3. We zijn er goed in. Ons hele leven scannen we al kranten, tijdschriften en boeken om te vinden wat we interessant vinden en daardoor weten we dat scannen werkt.

Een ‘luie’ gebruiker is ook een gebruiker

Laatst bekeek ik een Hotjar opname van een bezoeker die een door ons ontworpen tool gebruikte. Dit was een perfect voorbeeld van een ‘luie’ gebruiker die niet leest. Hij moest een simpele taak volbrengen: zijn geboortedatum invoeren. Maar deze persoon voerde geen streepjes in tussen de cijfers, waardoor er telkens een foutmelding in beeld kwam. Zelfs na tien keer op de hulpknop te klikken, waarin duidelijk uitgelegd wordt hoe de geboortedatum ingevoerd moet worden, kreeg hij het niet voor elkaar, waarna hij afhaakte. Mission failed.

De fout lag bij ons. Uit gemak hadden we geen invoermasker gebouwd omdat we er van uit gingen dat mensen het wel zouden snappen. Een invoermasker wordt gebruikt voor het valideren van gegevens door gebruikers te dwingen gegevens op een bepaalde manier in te voeren. Mochten ze het zonder invoermasker niet snappen, dan konden ze altijd de uitleg nog lezen. Maar helaas was dit een verkeerde aanname. Mijn collega Jorn vertelt hier trouwens meer over in zijn artikel “We’ll fix that in content”.

Gelukkig hadden wij hier een Hotjar opname van, waardoor we de klant konden overtuigen om wel een invoermasker toe te voegen aan de tool. Dit is een goed voorbeeld van het verbeteren van een website door het kijken naar het gedrag van je gebruikers. Ook al is het een kleine aanpassing, het voorkomt gefrustreerde gebruikers. Een paar van zulke kleine ‘quick wins’ en het verhoogt de conversieratio aanzienlijk. Het doen van usability testen nadat het product is opgeleverd is een goede manier om te kijken of je product daadwerkelijk positieve gevolgen teweegbrengt bij de gebruiker, maar nog belangrijker is het doen van gebruiksonderzoeken voordat je gaat bouwen.

Testen, testen, en nog eens testen

Als je een goede website wilt, moet je ‘m testen. Als je een tijd bezig bent met een website, al zijn het een paar weken, is het moeilijk om het van een afstand te bekijken. Je staat er te dicht op en op je hebt tunnelvisie. De enige manier om er achter te komen of je website gebruiksvriendelijk is, is om hem te laten testen door buitenstaanders. Testen herinnert je er aan dat niet iedereen op dezelfde manier denkt als jij, weet wat jij weet, en het web gebruikt op de manier zoals jij dat doet.

Testen met één gebruiker is 100% beter dan testen met nul gebruikers. Testen werkt altijd. Zelfs een hele slecht uitgevoerde usability test kan al waardevolle resultaten opleveren.

Het testen met één gebruiker aan het begin van het project is beter dan het testen met 50 gebruikers aan het eind van het project. De meeste mensen denken dat testen een heel gedoe is. Maar een simpele test aan het begin van een project – wanneer je nog tijd hebt om er van te leren – is waardevoller dan een uitgebreide test aan het eind.

Wil je een mooie website maken die goed werkt, een hoge conversieratio heeft en waar je gelukkige bezoekers aan over houdt, dan is het doen van usability onderzoeken een must. Alleen dan kom je in de buurt van een gebruiksvriendelijke interface.

Om nog even terug te komen op mijn opa, hij heeft netjes de hele pagina aan mijn moeder voorgelezen en, ondanks de heldere instructies, las hij ook de naam van het getrokken lootje op, oftewel de naam van mijn moeder. Soms zal je moeten accepteren dat je kan testen wat je wilt, maar dat je site nou eenmaal niet voor iedereen bedoeld is.

Dit artikel is geïnspireerd door het boek Don’t Make Me Think, A Common Sense Approach to Web Usability van Steve Krug.

Billy de usabilitybus test op locatie

Testen op locatie met Billy de Usabilitybus? Dat kan

Met Billy onderzoeken en testen we hoe eindgebruikers omgaan met je website en apps. We leggen alles vast op beeld zodat je stakeholders het ook kunnen zien.

Wil je dat Billy ook naar jouw eindgebruikers rijdt? Of eerst zien wat je dan te zien krijgt in zo’n testfilmpje? Trek dan aan de bel of mail direct naar billy@tfe.nl.