Testen met gebruikers
Uit Usability
Inhoud |
Algemene principes
- Geen site zou de lucht in mogen zonder een gebruikerstest
- Alleen een gebruikerstest kan duidelijk maken of een site werkt of niet werkt. Gebruikerstesten zouden verder minstens elk halfjaar moeten plaatsvinden.
- Gebruikers zijn geen ontwerpers.
- Gebruikerstesten vertellen ontwerpers wat de site moet kunnen, niet hoe de site gemaakt moet worden. Ze zijn ook minder geschikt om slordigheden op te sporen. (1)(6)(7).
- Ontwerpers zijn geen gebruikers.
- Gebruikerstesten zijn bij uitstek geschikt om websites te evalueren en om de aannames van ontwerpers te testen in de (weerbarstige) praktijk (1)(6)(18).
- Voer altijd meerdere testrondes uit.
- Evalueer websites voor en na elke wijziging. Op deze manier kunt u de netto winst van de verandering afzetten tegen de kosten voor het doorvoeren van de verandering.
- Bedenk dat veranderingen voor gebruikers altijd kosten met zich meebrengen omdat ze moeten wennen aan de nieuwe opzet. Kondig veranderingen daarom ruim van te voren aan.
- Meer dan drie herhalingen van testen (met één gebruiker) leveren nauwelijks nog extra informatie op. Gebruik die extra testen liever om de volgende veranderingen te evalueren (4).
- Maak reeds beschikbare gebruiksinformatie integraal onderdeel van het (continue) testproces.
- Klachten en opmerkingen van gebruikers die via andere kanalen (via baliemedewerkers of via het call center) binnenkomen, geven vaak veel inzicht in de feitelijk gebruik in de praktijk (9).
- Webstatistieken leveren ook een zeer bruikbare (en vaak onderbenutte) bron van informatie (4)(9).
- Een nadeel van statistieken is dat ze weliswaar precies vertellen wat een gebruiker doet maar niet waarom zij of hij dat doet (6). Kwantitatieve methoden zoals statistieken kunnen daarom het beste gecombineerd worden met kwalitatieve methoden zoals interviews.
- Mannen en vrouwen gebruiken sites vaak heel verschillend
- Vrouwen gaan intuïtiever te werk; mannen reageren meer op plaatjes en nemen teksten letterlijker
Ontwerpen van de test
- Achteraf testen met gebruikers werken over het algemeen beter dan vooraf testen met experts.
- Ex ante testen door experts (zoals cognitive walkthroughs) resulteren vaak in meldingen van problemen die in de praktijk helemaal niet bestaan en andersom, missen vaak reële problemen (1).
- Uit de literatuur blijkt dat er over het algemeen weinig overlap zit tussen de opinie van experts wat betreft de problemen die de grootste impact hebben op gebruiksvriendelijkheid (1).
- Geautomatiseerde testen zijn geen substituut voor testen met gebruikers van vlees en bloed (1).
- Geautomatiseerde testen zijn met name bruikbaar voor het testen van de technische prestatie en (deels) voor het testen van de toegankelijkheid van een website.
- Een nadeel van geautomatiseerde testen is dat ze vaak veel 'valse meldingen' genereren, dat wil zeggen problemen melden die in de praktijk helemaal geen probleem blijken te zijn (18).
- Beperk het aantal taken per test.
- Focus op de taken die voor de gebruiker het belangrijkste zijn, niet op nieuwe, ludieke of makkelijk te testen onderdelen van de website (9).
- Sorteer taken op volgorde van belangrijkheid volgens de formule {aantal gebruikers x frequentie x impact (severity) } (1).
- Het bepalen van de impact is geen sinecure. Uit de literatuur blijkt dat zelfs zeer ervaren usability experts niet in staat zijn om te voorspellen welke zaken het grootste effect hebben op gebruiksvriendelijkheid (1).
- Leidt het selectiecriterium (en de usability goals) liever af uit het feitelijk gebruik. Dat verschilt sterk van geval tot geval.
- Als een website wordt gebruikt om urgente problemen te verhelpen, dan is een bruikbaar criterium bijvoorbeeld: informatie die nodig is om een storing te verhelpen moet binnen 30 seconden door alle gebruikers gevonden kunnen worden (1).
- Laat de moeilijkheidsgraad van de uit te voeren taken oplopen.
- Begin met een hele makkelijke taak (om de testgebruiker gerust te stellen) en eindig met een onmogelijk uit te voeren taak (om te testen hoe de site zich onder stress houdt) (34)(47).
- Kwantificeer de usability goals. Bruikbare kwantitatieve grootheden zijn bijvoorbeeld (9)
- het aantal gebruikers dat een bepaalde taak 100% succesvol heeft afgerond;
- Het aantal gebruikers dat tegen een specifiek probleem aanloopt;
- Opsplitsing van de belangrijkste soorten problemen naar ervaring van de gebruiker.
- Gebruik het geschikte soort prototype.
- Papieren prototypes blijken in de praktijk net zo goed te werken als elektronische varianten. Er is geen significant verschil in het aantal usability issues dat wordt gevonden (1).
- Voor de indeling van de informatie (hoofdcategorieën, subcategorieën) is het laten sorteren van kaarten door een panel van gebruikers een effectieve en goedkope manier van testen (8);
- Maak daarvoor een kaart met een omschrijving voor ieder onderwerp dat u op de website wilt presenteren (maximaal 40). Dit worden de labels op de website (8);
- Schud de kaarten en vraag een groep personen (circa 15) om de kaarten logisch te ordenen (8).
- Vraag de groep om na te denken over namen voor de groepen gesorteerde kaarten. Dit worden de labels voor de categorieën op de website (8).
- Formuleer de opdrachten voor de testgebruikers zo open mogelijk.
- Zelfs het werken zonder instructies ('vrije surfsessie') levert al veel informatie op (5).
- Als er met opdrachten wordt gewerkt, beschrijf dan alleen de doelen die de testgebruiker moet bereiken, niet de stappen (9).
- Vermijd verborgen aanwijzingen in de opdrachtomschrijving. Denk in termen van de gebruiker, niet in termen van de website of de software die wordt gebruikt (9).
- Meest voorkomende problemen waar testgebruikers tegenaan lopen (9)
- Het concept van de website blijft onduidelijk;
- Ze kunnen de woorden/termen niet vinden waar ze naar op zoek zijn;
- de indeling van de informatie op de site komt niet overeen met de logica van de gebruiker;
- de indeling is nog wel te volgen maar de labels/omschrijvingen die gebruikt zijn, zijn onduidelijk;
- Er gebeurt teveel op de site;
- er is teveel 'ruis' op de site (speelt met name op de homepage);
- de zaken die voor d(i)e gebruiker relevant zijn, springen niet duidelijk genoeg naar voren.
Testgebruikers selecteren
- Do not test your own baby (9).
- Zelftesten zijn alleen geschikt om de technische werking van een website te testen. Ze leveren geen informatie op over het gebruik in de praktijk.
- Maak bij voorkeur gebruik van een (gestratificeerde) steekproef uit de huidige gebruikersgroep.
- Testen met vrijwilligers van buiten de huidige gebruikersgroep (vrienden, familie en collega's) zijn vaak minder betrouwbaar (10).
- Zelfs met een beperkt aantal (4-5) onervaren gebruikers kunnen de meest kritische problemen al worden opgespoord (11).
- Als er veel variatie zit in de gebruikersgroep, moeten er in het panel vertegenwoordigers uit alle relevante subgroepen worden geselecteerd.
- Zorg bij het samenstellen van het panel voor voldoende variatie op de volgende kenmerken van de testgebruikers (6):
- ervaring met het internet;
- ervaring met het inhoudelijke domein van de website.
- Om een goede vergelijking tussen de uitkomsten van de uniforme gebruikstest mogelijk te maken, is het daarnaast belangrijk om een goede spreiding te hebben op de volgende demografische kenmerken (52):
- leeftijd;
- opleiding;
- Bepaal het aantal testgebruikers.
- Een test met twee of drie gebruikers levert al een heleboel nuttige informatie op [5].
- Het loont vaak beter om een groot aantal testen met een (zeer) beperkt aantal gebruikers te doen dan enkele testen met veel gebruikers (12).
- Zelfs bij grote aantallen gebruikers (meer dan 15) worden niet alle usability problemen (maximaal 80%) gevonden. (13).
- Een bekende vuistregel is dat bij 6 gebruikers het optimum is bereikt uit oogpunt van kostenefficiëntie (6).
- Om een goede vergelijking tussen de uitkomsten van de uniforme gebruikstest mogelijk te maken, zijn er tenminste negen gebruikers nodig (47).
De test uitvoeren
- Test eerst sites uit van vergelijkbare organisaties (18).
- 'Live' sites zijn bij uitstek geschikt om van te leren omdat de beste sites (of meer abstract: de beste design patterns) in de praktijk vanzelf boven komen drijven (30).
- Benadruk dat het om een test van de website gaat, niet om een test van de testgebruikers (6).
- Nodig geen mensen uit het management uit wanneer hun personeelsleden in het panel zitten (9).
- Garandeer de anonimiteit van de testgebruikers (9).
- Laat de ontwerpers meekijken bij de gebruikstesten (9).
- Het is vaak een ontnuchterende dan wel louterende ervaring voor het ontwerpteam om gebruikers de website in de werkelijkheid te zien gebruiken.
- Maak eventueel opnames van de gebruikerstest om ontwerpers en/of opdrachtgevers duidelijk te maken waar de knelpunten zitten.
- Let met name op het gedrag van de testgebruikers, niet op de dingen die ze zeggen.
- Zelfrapportages zijn over het algemeen onbetrouwbaar, net als speculaties van gebruikers over hun toekomstige gedrag (14).
- Hardop denken (thinking aloud) is een veelgebruikte methode om uit te vinden wat mensen denken bij gebruik van een website. In de praktijk blijkt de meerwaarde beperkt. Mensen zeggen meestal letterlijk wat ze doen of lezen direct van het scherm in plaats van dat ze zeggen wat hun achterliggende overwegingen zijn (1). De thinking aloud-methode laat wel goed zien waar mensen hun eerste informatie vandaan halen. Dat is vaak heel ergens anders dan wordt aangenomen (16).
- Wees bij gebruik van de thinking aloud methode alert op lange stiltes, stel de testpersoon open vragen om erachter te komen waar hij of zij over nadenkt of naar zoekt.
- Voer de testen bij voorkeur met individuele gebruikers uit.
- In een groep zeggen mensen vaak niet wat ze echt denken (9). Dit geldt nog sterker voor onervaren gebruikers.
- (focus)groepen zijn in het geheel niet bruikbaar voor het testen van de gebruiksvriendelijkheid (usability) van een website (34).
- Ze zijn wel bij uitstek geschikt voor het genereren van nieuwe ideeën (brainstorm sessies) aan het begin van (her)ontwerptrajecten (34).
- Begin elke test met een 'vrije surfsessie'.
- Vraag de proefgebruiker welke informatie hij op de website zou willen vinden of welke handelingen hij zou willen uitvoeren. Vraag hem dan vervolgens om dat hardop denkend te doen (5).
- Wat mensen uit zichzelf doen leidt vaak tot interessanter gedrag dan het louter uitvoeren van opdrachten (5).
- Vrije opdrachten leveren meer relevante en volledige informatie op dan voorgestructureerde opdrachten en hebben een hogere waardering en acceptatie [15]. Ze scoren wel lager op begrip -- zijn dus minder geschikt voor onervaren gebruikers -- en selectie -- leveren uiteraard minder gerichte informatie op dan voorgestructueerde opdrachten.
- Vraag de testpersoon naar zijn of haar verwachtingen, bijvoorbeeld wat de testpersoon achter de verschillende menukeuzes verwacht te vinden.
- Voor het onderling vergelijken van resultaten (benchmarken) zijn voorgestructureerde (gestandaardiseerde) opdracht juist bij uitstek geschikt (47).
