Gebruikstesten

Uit Usability

Ga naar: navigatie, zoeken

Inhoud

Algemene principes

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).
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 3 herhalingen van testen (met 1 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).
  • Web statistieken leveren zijn 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.



Ontwerpen van de test

Ex post testen met gebruikers werken over het algemeen beter dan ex ante 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.
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).
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).



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 drie kenmerken van de testgebruikers (6).
  1. ervaring met computers in het algemeen;
  2. ervaring met de (soort van) website;
  3. ervaring met het inhoudelijke domein van de website.
Bepaal het aantal testgebruikers.
  • Een test met 2 of 3 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).



De test uitvoeren

Benader 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.
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).
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.
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.
Persoonlijke instellingen
Proces
Randvoorwaarden