Een van de dingen die we bij Occhio graag doen voor onze opdrachtgevers, en die erg interessant is, is Usability Testing. Usability testing is een van de minst spannend klinkende, maar (een van de) meest belangrijke onderdelen van web development.
Wat is een usability test?
Een usability test is een gebruikersonderzoek, waarbij het gedrag van gebruikers op de website wordt vastgelegd. Mogelijke problemen in bijvoorbeeld de navigatie worden vastgelegd en je krijgt een heel uitgebreid inzicht in de gebruikerservaring.
Mits… dit uiteraard op een professionele manier wordt uitgevoerd.
De Do’s & Don’ts van Usability testing
Wil je een usability test goed uitvoeren, dan zijn er een aantal belangrijke dingen tijdens je test die je WEL moet doen, en die je juist NIET moet doen. Hieronder een overzicht de do’s en don’ts.
Observeer meerdere usability test sessies (DO)
Zowel ontwerpers en ontwikkelaars, als stakeholders in een project kunnen veel halen uit het observeren van usability testsessies.
Door de reactie van gebruikers te observeren, kun je veel leren over de usability problemen van het product (de site of web applicatie) die anders heel moeilijk zijn te omschrijven in een rapport of powerpoint presentatie door de onderzoekers. Dus, als je de kans hebt om een aantal test sessies bij te kunnen/mogen wonen, grijp je kans en haal je voordeel!
Direct een conclusie formuleren na een aantal testsessies (DON’T)
Houdt in je achterhoofd dat elke mens uniek is, wanneer je een usability testsessie observeert. De feedback van een paar gebruikers hoeft helemaal niet de algemene reactie te zijn die je gehele doelgroep heeft ten opzichte van je website. Als onderzoeker ben je op zoek naar trends in usability en niet naar specifieke opmerkingen of handelingen van individuen.
Houdt dit in gedachte en vermijd dat je direct conclusies trekt over een bepaalde ontwerprichting. Neem de tijd voor overleg over de user feedback, voordat je besluiten neemt.
Richting geven aan het user research team (DO)
De stakeholders en ontwerpers begrijpen hun website/web applicatie vaak beter dan de onderzoekers die de gebruikerstest uitvoeren. Wij, in de rol van onderzoeker, moeten erop vertrouwen op de informatie van onze klanten over het doel en de waarde van het product dat ermee beoogd wordt, helder is. Tijdens de kick-off meeting en gesprekken daarna verzamelen we die info, maar wanneer de stakeholders (en ontwerpers) deelnemen tijdens de usability test kunnen zij ervoor zorgen dat de bevindingen van het onderzoek ook echt werkbaar zijn.
Je wil opleggen aan het research team (DON’T)
Richting geven is goed, maar leg niet je wil op tijdens een onderzoek. Uiteraard hebben usability test onderzoekers meer ervaring en kennis voor wat betreft het uitvoeren van gebruikersonderzoek. Houdt daarom rekening met hun inbreng bij het nemen van beslissingen over de planning, het schema, de logistiek en andere taken bij zo’n onderzoek.
Onderzoek werkt het beste als het een gezamenlijk proces betreft, dus het is heel belangrijk is dat het ontwikkelingsteam samenwerkt met het onderzoeksteam om de beste resultaten te bereiken.
Zorg dat je je testgroep screent op gedrag (DO)
Het kiezen van de juiste testgroep is een van de meest kritische onderdelen van usability testing. Wanneer je de test start met de ‘verkeerde’ testpersonen – dus personen die niet representatief voor je doel(markt) – dan zul je vaak de verkeerde keuzes maken bij aanpassingen aan de user interface van je product.
Voor het ‘recruteren’ van de juiste testdoelgroep, moet je zorgen dat die geselecteerd wordt op basis van de juiste selectiecriteria.
Dat zijn bijvoorbeeld:
- wekelijks internetgedrag (hoe vaak)
- interactie op social networking sites
- gebruik van smartphones (en specifieke applicaties)
Op deze wijze krijg je een goed beeld van de (technische) kennis (en kunde) en het vermogen van een deelnemer. Het matchen van zogenaamde characteristic user behaviors met je basiscriteria voor het product, zorgen er in ieder geval voor dat je ontwerpkeuzes niet voor de verkeerde doelgroep worden gemaakt.
Stel geen onmogelijke selectiecriteria op voor de deelnemers (DON’T)
Het is natuurlijk belangrijk om de juiste deelnemers mee te laten doen aan een testsessie, maar het is nog belangrijker om er zeker van te zijn dat je een testpanel hebt. Als je screent op gebruikers die een bepaald model mobiele telefoon bezit, en dan ook nog firmware versie 3.1.56 hebben geinstalleerd, dan kun je er wel zeker van zijn dat je te weinig deelnemers kunt verwachten om een juiste studie mee uit te voeren. Daar komt nog bij dat als je zulke deelnemers hebt gevonden, het waarschijnlijk buitenbeentjes of uitblinkers zijn, in ieder geval vallen ze meestal buiten een wat breder gedefinieerde doelgroepmarkt. Het is dan ook niet de bedoeling om deelnemers te recruteren die exact overeenkomen met de user persona van je website of webapplicatie, maar die bij benadering het gedrag en de technische kennis bezitten.
Video opnames van testsessies bewaren (DO)
Video beelden zijn van grote waarde tijdens het overleg over usability problemen. De emotionele reactie op de gezichten van de deelnemers in combinatie met hun feedback zegt namelijk heel veel. Daarnaast kan het handig zijn om de video’s in te korten tot korte videoclips en die te presenteren aan de decision makers om zo de besluitvorming op een restyling van een project kracht bij te zetten. Zien is geloven.
Verwacht niet dat je al het videomateriaal kunt bekijken van een usability study (DON’T)
Verwacht niet dat je al het videomateriaal van een usabilty test zult gaan bekijken, of te zien krijgt (tenzij je de test integraal meemaakt). Zelfs kleinere testen leveren vaak meer dan 10 uur video op. Beslissingen en adviezen worden gemaakt op basis van het bekijken van de video’s (of live testen) en het maken van aantekeningen tijdens het bekijken van de video’s, zodat je later de reacties van de verschillende deelnemers met elkaar kunt vergelijken. (Het gevaar zit hem in het direct trekken van conclusies). Wacht dus rustig af totdat je de resultaten en wat videoclips kunt bekijken.
Voer usability testen op een iteteratieve manier uit (DO)
Op het eerste gezicht lijkt het efficient en doeltreffend om een usability test in 1 sessie te doen en af te ronden. Maar er zijn een aantal redenen waarom je dit niet moet willen (doen). Allereerst zullen grote (proimente) usability issues ervoor zorgen dat de minder zichtbare (of andere) issues niet aan bod komen, terwijl die even belangrijk zijn. Het is beter om eerst te beginnen met een expert review, om vervolgens pas echte gebruikers deel te laten nemen in de usability test. De expert review zorgt ervoor dat je de belangrijkste, meest voor de handliggende, usability problemen kunt ondervangen, die je vervolgens meteen kunt oplossen. Daarna kun je de verbeteringen die je hebt doorgevoerd aan de user interface dan gaat toetsen bij het testpanel van gebruikers.
Een solide testprocedure bevat het testen met een klein groepje gebruikers, waarna je noodzakelijke aanpassingen worden gemaakt naar aanleiding van de gevonden problemen. Vervolgens ga je weer testen met een groepje.
Testen met 10 tot 12 deelnemers voegt vaak bijna niets extra’s toe aan waarde in vergelijking met het testen met 6 tot 8 mensen. Je hebt echter wel veel minder kosten dan met meer deelnemers.
Iteratief usability testen past overigens ook veel meer bij het tegenwoordig populaire Agile development waarin in cycli wordt gewerkt (over Agile development schrijf ik binnenkort nog eens een blog).
Verschillende doelgroepen buiten je onderzoek laten (DON’T)
Wanneer je een website of applicatie ontwikkeld voor meer dan 1 doelgroep, zorg er dan ook voor dat er van elke doelgroep in ieder geval 1 afgevaardigde is die meedoet aan (een deel van) het testonderzoek. Je kunt dat in feite op 2 manieren doen: je kunt deelnemers van elke doelgroep in 1 usability test opnemen. Je kunt ook de verschillende doelgroepen op verschillende momenten laten deelnemen gedurende de test iteraties (in meerdere sessies). Onze voorkeur gaat uit naar de laatste optie:
Grote usability onderzoeken zijn ingewikkelder, en kosten ook veel meer dan iteratieve testsessies. Wat je dus kunt doen is starten met de meest technische doelgroep om vervolgens te eindigen (na een aantal sessies) met de doelgroep die het minst bekend is met je product. Het is gebleken dat de meest ervaren (technische) doelgroep makkelijk door de testsessie heenkomt (ze zijn vaardig in het gebruik van je website of applicatie), maar ze zijn ook het meest kritisch op de user interface. Terwijl de minder ervaren doelgroep meer moeite hebben om taken binnen de test te verrichten, maar hun waarde ligt in het feit dat zij de moeilijkheden die ze ondervinden koppelen aan hun eigen level of ability dan aan het productontwerp.
Minimaliseer je impact op testsessies (DO)
Het gevaar bij een testsessie is dat de ontwerper of ontwikkelaar van een testsessie een demonstratie van het product maakt. De kern van het probleem zit hem in het feit dat je gebruiker altijd wel de logica van een productdesign inziet als je het hem laat zien. Het doel is natuurlijk om te kunnen bepalen of de doelgroep in staat is om zelfstandig uit te vinden hoe de user interface (het menu, de navigatie etc) werkt. Om dat te weten is het van belang dat de omgeving zoveel mogelijk aansluit bij de context waarin de gebruiker de site of web applicatie zal gaan gebruiken. En dat is dus niet met een developer die naast hem of haar zit.
Zorg dat je bij het observeren van een deelnemer in een testsessie stilzit, observeert en aantekeningen maakt. Bij Occhio hebben we een aparte ruimte waarbij we het scherm en het gezicht van de persoon op afstand kunnen bekijken en he commentaar kunnen beluisteren met meerdere mensen. 1 persoon zit wel in de ruimte met de deelnemer en kijkt en begeleidt de tester af en toe met de vragenlijst die behandeld wordt.
Verschuil jezelf niet voor de deelnemers (DON’T)
Over het algemeen wil je als testdeelnemer graag weten met welke ‘kwade geest’ je te maken hebt. De introductie van one-way spiegelglas, waarbij de deelnemer niet ziet wie er naar hem kijkt zorgt er vaak voor dat deelnemers nerveuzer zijn en veel meer bewust van zichzelf zijn, dan wanneer er een persoon (van de organisatie) bij is met een laptop en camera op hun gericht. Daarnaast, en logischerwijs, ervaren mensen —
Voeg experience testing toe (DO)
Usability testing is erg waardevol, maar je kunt er ook nog meer uithalen dan de feedback van deelnemers op de functionaliteiten van een product. Usability testing is namelijk ook een hele goede mogelijkheid om data te verzamelen over de waarde (value proposition) van je product. Deze informatie helpt je om te bepalen of je op de juiste weg bent, met het in de markt zetten van de applicatie en of je de juiste ervaring creeert ermee en daarmee je merkwaardering verbetert. Daarnaast zul je ook ontdekken of je site of webapplicatie misschien wel een key feature mist die de waarde van je product enorm vergroot. Het betekent dat als je dit soort feedback wilt ontvangen, je de emotionele reactie van de deelnemers over de ervaring van je product, moet kunnen vangen. Het gebeurt zeker wel dat deelnemers enorm verrast zijn door de aanwezigheid van een bepaalde feature, en meteen al vertellen wat ze er niet allemaal mee kunnen doen. Maar het komt ook voor dat deelnemers helemaal niet onder de indruk zijn van de innovatieve oplossingen die het systeem bevat. En dat is jamer. Maar als je dat kunt traceren, dan kun je er iets aan doen voordat je het systeem lanceert (en dat is zeer waardevol).
Vermijd het gebruik van werkende prototypes die te buggy of onstabiel zijn (DON’T)
Prototypes die onstabiel zijn of vol met bugs zitten kunnen een usability onderzoek flink gecompliceerd maken. We weten dat wanneer deelnemers bugs ontdekken terwijl ze taken uitvoeren tijdens een test, ze zullen reageren op de fouten en niet op het daadwerkelijke ontwerp. Dit soort feedback beinvloed je resultaten (data) negatief, namelijk in aantal en in kwaliteit. Daarnaast zorgen crashes en bugs ervoor dat de tijd die je inruimt voor een sessie voor een deelnemer flink kan oplopen en daarmee uitlopen. Je komt dan niet uit met je agendaschema. En je hebt kans dat deelnemers afhaken.
Natuurlijk zijn er situaties waarin je niet kunt testen wat je exact wilt testen bij het gebruik van een demo of mockup, en zul je een deelnemer een incomplete site moeten voorschotelen.
Maar in die gevallen is het heel belangrijk dat je de deelnemer duidelijk vertelt over de gevorderde status van de applicatie en ervoor te zorgen dat iemand van het ontwikkelteam stand-by staat om technische support te bieden waar nodig.
Tot slot
bij Occhio hebben we veel ervaring met usability en usability testing. Doordat teamleden kunnen meekijken en luisteren via een scherm in aparte afgesloten ruimte zijn we in staat om met meerdere personen (partijen) een onderzoek te doen. Als je meer wilt weten over de mogelijkheden neem dan contact met mij op.
Dit artikel is deels gebaseerd op informatie van uxmatters.com.