Think aloud vs heuristische evaluatie

mei 26, 2009

Inleiding

Tijdens de les werd het think aloud protocol besproken als manier om de bruikbaarheid van een gebruikersinterface te onderzoeken. Buiten het think aloud protocol zijn er nog andere manieren om een gebruikersinterface te evalueren. Het leek me dan ook interessant om een van deze manier te bespreken en te vergelijken met het think aloud protocol. De methodiek die besproken wordt betreft deze van  heuristische evaluatie.

Heuristische evaluatie [1]

De heuristische evaluatie wordt uitgevoerd door een aantal verschillende testpersonen. Deze personen dienen expert te zijn op het vlak van gebruiksvriendelijkheid, of toch minstens vertrouwd te zijn met de concepten binnen dit domein. Concreet wordt aan deze personen de interface gegeven ter evaluatie, eventueel in papieren vorm. Elk van de personen zal individueel de interface bekijken en evalueren. Zeer belangrijk is dat deze evaluatie individueel gebeurt teneinde een onafhankelijk resultaat te bekomen ten opzichte van de overige evaluators. Na evaluatie wordt een rapport afgeleverd met de gedetecteerd mankementen van de interface.

De methode dankt zijn naam aan de manier waarop de evaluatie dient te gebeuren. Deze is namelijk gebaseerd op enkele algemene geldende principes betreffende de goede bruikbaarheid van een systeem, de heuristieken. Eventueel kunnen deze heuristieken aangevuld worden met enkele specifieke principes die gelden in een bepaald domein van applicaties. Een lijst van algemeen geldende heuristieken wordt hieronder gegeven[2].

  • Zichtbaarheid van systeem status

Het systeem dient feedback te geven aan de gebruiker betreffende zijn huidige status en voortgang.

  • Overeenkomst tussen systeem en echte wereld

Een systeem moet verstaanbaar zijn voor de gebruiker. Maak gebruik van natuurlijke taal die de gebruiker begrijpt. Maak acties zoals ze uitgevoerd zouden worden via logische handleingen.

  • Gebruikerscontrole en vrijheid

Biedt een simpele uitweg wanneer een gebruiker zichzelf in problemen heeft gebracht. Geef de gebruiker de mogelijkheid om foutieve handelingen ongedaan te maken of handelingen opnieuw uit te voeren.

  • Consistentie & standaarden

Ga uit van behoud van consistentie binnen de applicatie. Gebruik standaarden.

  • Error preventie

Vermijd het maken van fouten door preventieve controles en/of bevestigingdialogen.

  • Herkennen vs herinneren

Maak dingen herkenbaar. Voorkom dat de gebruiker zelf dingen moet onthouden. Bied eerder gebruikte informatie aan waar ze nodig is.

  • Flexibiliteit & gebruiksefficiëntie

Maak veel gebruikte acties doeltreffend en makkelijk beschikbaar. Laat toe dat gebruikers zelf shortcuts definiëren voor bepaalde acties.

  • Estetisch en minimalistisch design

Ga uit van een minimalistisch design. Vermijd screen clutter.

  • Help bij het oplossen van problemen

Maak foutmeldingen begrijpbaar voor de gebruiker. Vermijd weergave van errorcodes. Biedt hulp aan ter oplossing van het probleem.

  • Documentatie

Indien nodig, biedt voldoende informatie aan. Maak deze makkelijk beschikbaar voor de gebruiker.

Vergelijking

Zowel het think aloud protocol als de heuristische evaluatie methode worden aangewend ter evaluatie van de bruikbaarheid van een gebruikersinterface. Beiden bieden de mogelijkheid om uitgevoerd te worden aan de hand van een paper prototype, wat de ontwikkelingskost van een applicatie sterk kan drukken.

Beide methodieken berusten op de input van een onafhankelijk testpersoon. Bij een think aloud echter gebeurt de evaluatie door een onervaren persoon, terwijl die bij de heuristische evaluatie door een expert gedaan wordt. Een vaak voorkomend probleem bij een think aloud is dat de proefpersoon denkt dat hijzelf geëvalueerd wordt, waardoor deze geremd wordt in zijn handelingen uit schrik iets fout te doen. Dit probleem stelt zich niet bij de heuristische evaluatie, daar de proefpersoon slechts een objectief rapport dient af te leveren van zijn bemerkingen.

Het think aloud protocol gaat uit van een actie gedreven evaluatie, terwijl het bij de heuristische evaluatie eerder een objectieve analyse betreft. Het voordeel bij de actie gedreven aanpak is dat problemen gedetecteerd worden die rechtstreeks van toepassing zijn op de bruikbaarheid van de specifieke applicatie. Bij de analytische aanpak worden algemene problemen gedetecteerd, ook deze die mogelijks geen invloed hebben op de goede bruikbaarheid van de applicatie.

Een ander verschil betreft de hoeveelheid aan informatie die vrijgegeven wordt door de afnemer van een test. Zoals gezegd is bij een think aloud het hoofddoel fouten te detecteren door de gebruiker al doende met de applicatie te laten interageren. Aangezien hier ook gepeild wordt of de interface hem in staat stel bepaalde doelstelingen te bereiken, dient de observator terughouden te zijn wat betreft het vrijgeven van informatie. Daar dit argument niet opgaat voor de heuristische evaluatie kan de proefpersoon tijdig bijgestuurd worden indien deze niet weet hoe een bepaalde actie uit te voeren. Hierdoor wordt bij de afname van de test geen kostbare tijd verloren.

Tot slot wordt nog even het taakverschil van de observator aangehaald. Tijdens een think aloud test neemt deze een interpreterend houding in. Hij moet de redenen achter bepaalde handelingen zelf nog mappen op problemen in de gebruikersinterface. Dit met het gevaar dat deze verkeerd geïnterpreteerd worden of toegeschreven aan foutieve items in de interface. Dit in tegenstelling tot een heuristische evaluatie waarbij de observator slechts een rapport in ontvangst dient te nemen van de proefpersoon. Hierop worden de door hem gevonden mankementen duidelijk aangehaald, refererend naar de heuristieken waartegen deze zondigen. Uiteraard betreft dit ook alleen maar de identificatie van het probleem, niet de mogelijke oplossingen.

Conclusie

Het evalueren van een gebruikersinterface is niet altijd even simpel. Hierboven werden twee methodieken vergeleken en geconludeerd kan worden dat geen van beiden optimaal is. Beiden beschikken ze over voor- en nadelen.

Positief aan een think aloud is dat deze wijst op problemen specifiek voor de werking van de applicatie. Nadelig is dat berust wordt op de input van een gebruiker die vaak weerhoudend is om te zeggen wat hij denkt. Tevens kunnen de handelingen van de gebruiker verkeerdelijk geïnterpreteerd worden.

Bij de heuristische evaluatie is positef dat de evaluatie door een expert gebeurt die een objectieve analyse levert op basis van heuristieken. Een negatieve eigenschap is dat heuristieken slechts heuristieken blijven en niet altijd de werkelijkheid aan hun kant hebben. Bovendien zijn deze niet altijd getarget op de specifieke applicatie.

Niets staat een applicatie ontwikkelaar uiteraard in de weg te berusten op beide methodieken teneinde de vruchten van beiden te plukken.

Bronnen

[1] http://www.useit.com/papers/heuristic/heuristic_evaluation.html

[2] http://www.useit.com/papers/heuristic/heuristic_list.html 

One Response to “Think aloud vs heuristische evaluatie”

  1. barttimmermans Says:

    zie ook mijn Delicious bookmark van 3 dagen eerder (23 mei) op http://delicious.com/tag/%23chikul09?page=3


Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers op de volgende wijze: