De laatste keer dat ik wilde uitleggen wat ik eigenlijk doe in mijn werk was onder de meest ideale omstandigheid: voorop een catamaran van Curaçao naar Klein Curaçao. Mijn medereisgenoot bleek hovenier en toen kwam de geïnteresseerde wedervraag: “Wat doe jij?”. Veel antwoorden zijn mogelijk, maar doen gevoelsmatig tekort aan de complexiteit van het werk en het plezier wat ik eruit haal. Maar hoe leg je als technisch tester aan een atechnisch persoon uit wat je doet? “Softwaretester”, geeft vaak een reactie in de trant van: “testen, dat kan toch iedereen”. Technisch tester, performancetester, testautomatiseerder, het maakt allemaal niet uit. Het dekt niet de lading.
“Noem mij frustratie manager. Ik bewaak (manage) dat je bij het gebruik van websites en programma’s je laptop niet van frustratie uit het raam wilt gooien ”. “Held!” is de reactie die ik krijg; meteen moet ik overal ingezet worden om problemen op te lossen. Iedereen is wel bekend met foutmeldingen na ingevulde formulieren, wachttijden langer dan bij de Efteling en knoppen die niets (lijken te) doen. Frustraties zijn aan de orde van de dag, behalve die dag, voorop een catamaran zeilend over kristalhelder water.
De vraag is nu: hoe zorgen we ervoor dat de frustraties niet te hoog oplopen? Als performancetester krijg ik van klanten vaak de vraag hoeveel wachttijd acceptabel is. Ofwel, hoeveel wachttijd kan iemand hebben? Dit is niet zozeer een technisch vraagstuk, maar een neurowetenschappelijk vraagstuk en, zoals ook genoemd in mijn vorige blog Infrastructuur performance testen, een psychologisch vraagstuk. In performanceland wordt er vooral gekeken naar efficiëntere code, configuratie en hardware.
Computers zijn in staat om miljarden berekeningen per seconden uit te voeren en informatie wordt verspreid met de lichtsnelheid. Het menselijke brein kent echter haar limieten en toleranties verschillen per gebruiker(sgroep). Lage reactietijden zijn niet alleen een handigheid, maar soms een noodzaak. Als een reactietijd boven een bepaalde grens komt, verliest de gebruiker de concentratie / informatie interesse.
Alle reactietijden onder de 100ms (milliseconden) blijven in het sensorisch geheugen hangen alvorens ze naar het werkgeheugen gaan en worden daardoor als ‘direct’ beschouwd. Zoals bijvoorbeeld de tijd tussen een toetsaanslag en het zichtbare resultaat op je scherm. Vertraging hierin verstoort het denkproces. Hoe snel is 100ms? Een keer knipperen met je ogen duurt gemiddeld 350ms.
Het typen op een toetsenbord dient vrijwel instantaan te gebeuren willen we goed kunnen werken of in een ‘flow’ blijven. Die ‘flow’ is belangrijk. We moet er rekening mee houden dat als gebruikers een proces doorlopen dit tussen de 0,1 en 1 seconde dient te gebeuren. Gebruikers hebben dan het gevoel dat de applicatie ‘werkt’.
Toch is deze maximale 1 seconde niet heilig. Gebruikers zijn best bereid om te wachten. Bij iedere actie hoort een verwachting. Op het laden van een filmpje op YouTube of bij het zoeken naar de goedkoopste vlucht is de gebruiker bereid om langer te wachten. De waarde moet evenredig zijn met het wachten. Er is wel een grens. De grens van de concentratiespanne ligt bij ongeveer 10 seconden. Gaan we nog een stap verder, dan komen we tot ongeveer de grens van het korte termijn geheugen van ongeveer 18 seconden.
Maar de eerder genoemde 350ms voor het laden van een pagina is vrijwel onhaalbaar. Google.nl heeft ongeveer 500ms nodig om te laden. En die pagina is vrij simpel. Alleen een pagina met ongeveer een A4-tekst in HTML haalt het om binnen 350ms te laden. Het is dus van belang kritisch te zijn bij het opzetten van webpagina’s.
Op mobiele apparaten werd dit nog verder bemoeilijkt. Tot voor kort kwamen er 300ms extra bij voor iedere actie. Dit was gedaan om onbedoelde acties te ondervangen. Nieuwere mobiele browsers hebben deze vertraging niet (bijv. sinds IOS 9.3 uit maart 2016), maar er zijn nog veel oude mobieltjes in omloop. Deze gebruikers ervaren dus een andere performance.
Performance is dan ook niet altijd uit te drukken in harde cijfers, maar vaak gaat het om de ervaren performance. Niet hoe snel een applicatie daadwerkelijk is, maar hoe snel een gebruiker denkt dat een applicatie is. Door handige visuele trucks kan een gebruiker worden geïnformeerd, bijvoorbeeld met een laadbalk, spinner en knopeffecten. Feedback verkort de ervaren performance en kan frustraties voorkomen.
Ook kunnen we een pagina op een andere manier laden. Door de belangrijkste componenten als eerste te laden kunnen gebruikers al snel actie ondernemen. Hetzelfde geldt bijvoorbeeld voor het laden van een plaatje in ‘progressieve beeldweergave’, waarbij een foto begint met een lage kwaliteit en dan verder wordt aangevuld. Houd het lokaal, op Instagram kun je een foto ‘liken’ zonder verbinding, er wordt dus geen vertraging ervaren.
Mogelijk niet het eerste waaraan gedacht wordt, maar een systeem kan ook te snel zijn. Een selectielijst die constant bijgewerkt wordt kan te snel veranderen voor een gebruiker om er op te klikken. Ook dit resulteert in een gefrustreerde gebruiker. Dit zie je wat sneller bij ouderen, atechnische mensen of als je de voertaal beperkt machtig bent.
Performance is daarmee niet alleen een wetenschap van harde cijfers, maar heeft ook een groot psychologisch component. Met als doel om frustratie te allen tijde te voorkomen en de gebruiker te behouden.
Uw frustratiemanager 😉
