Tree testing

Doel

Tree testing doen we om erachter te komen of de informatie architectuur van de website (de structuur, navigatie, hiërarchische menu’s of andere taakstructuren) logisch zijn voor de bezoekers. We komen te weten of bezoekers zaken succesvol kunnen vinden in de boomstructuur, zonder al te veel na te hoeven denken. We kunnen achterhalen welke gedeelten van de structuur wel goed werken en welke minder werken. We kunnen oude, nieuwe, mogelijke en verschillende nformatie architecturen met elkaar vergelijken. Als we na het uitvoeren van een Tree testing in een later stadium vindbaarheid problemen tegenkomt, dan ween we dat dit niet te maken heeft met de informatie architectuur.

Uitleg

Tree testing wordt ook wel reverse card sorting of card-based classification evaluation genoemd. Dankzij deze individuele methode kunnen we erachter komen of de navigatie en content overeenkomen met de verwachtingen van de respondenten door respondenten taken te laten uitvoeren. We kunnen gemakkelijk versies met elkaar vergelijken dankzij de kwantitatieve resultaten, hierdoor kunnen we die dingen aanpakken die niet goed lopen. Het uitvoeren van een sessie duurt niet lang, maximaal één half uur. We hebben een aantal kaarten nodig waar de te vinden informatie op staat en een aantal waarop de structuur staat van de website. Op kaart 1 staat het hoofdmenu, kaart twee het submenu van categorie 1, enzovoorts. Op deze manier kan de respondent door de boomstructuur heen gaan tot hij de plek heeft gevonden waarvan hij denkt dat hij de informatie kan vinden.

Planning

We kunnen Tree testing in het gehele ontwikkelproces uitvoeren, het enige wat we nodig hebben is een idee van de navigatie of content die we willen onderzoeken. Aan het begin van het ontwikkelproces kunnen we het gebruiken om de informatie architectuur te analyseren en verbeterpunten te achterhalen. Verder in het ontwikkelproces kunnen we het gebruiken om de informatie architectuur te testen en te zien of het verbeterd is dankzij de aanpassingen die gedaan zijn aan de hand van andere uitgevoerde methoden.

Aanvullende methoden

Input verkregen van de volgende methoden

Om achter realistische taken te komen die uitgevoerd kunnen worden of informatie die gezocht kan worden, kan er gebruik gemaakt worden van de volgende methoden:

• card sorting
• enquêtes
• focusgroep sessies
• interview
• on-site web analyses
• wensen en behoeften analyse

Om ervoor te zorgen dat we kunnen aantonen dat er verbetering zit in de informatie architectuur, kunnen we vervolgens tree testen met de oude website, vervolgens kunnen we methoden uitvoeren die ideeën genereren voor de informatie architectuur. Denk hierbij aan een card sorting en groepstaak analyse. Als de resultaten verwerkt zijn van deze methoden, kunnen we een tree testing uitvoeren om erachter te komen in hoeverre de website verbeterd is. Als deze resultaten verwerkt zijn in de website, kunnen we opnieuw een tree testing uitvoeren om te zien hoe goed het opnieuw verbeterd is of om erachter te komen waarom de problemen zich ergens bevinden.

Vergeleken met andere methoden

Vergeleken met groepstaak analyse

Bij tree testing komen er probleemgebieden boven water met betrekking tot de informatie architectuur en niet zo zeer tot het uitvoeren van taken. Het is een handig middel om te evalueren of de informatie architectuur goed in elkaar zit en om te zien waar de fouten zitten. Vervolgens kunnen er aanpassingen gedaan worden die weer geëvalueerd kunnen worden met behulp van tree testing.

Bij een groepstaak analyse kijk we naar hoe respondenten taken uitvoeren, aan de hand daarvan ga we kijken hoe we de informatie architectuur kan plaatsen en hoeveel stappen de bezoekers moeten nemen om een taak uit te voeren. We kijken hoe de respondenten tegen de website aankijken of taken willen uitvoeren, daardoor kunnen er problemen en oplossingen boven komen.

De ene methode vervangt dus niet de ander.

Vergeleken met card sorting

We kunnen tree testing zien als een goede aanvulling op het uitvoeren van een card sorting door een paar belangrijke verschillen tussen deze twee methoden.

• Bij een card sorting worden de respondenten gevraagd om content te categoriseren, ordenen en organiseren. Bij het uitvoeren van deze methode worden er ideeën opgedaan voor de meest handige informatie architectuur en kan de structuur bepaald worden. Door het uitvoeren van tree testing wordt deze geëvalueerd en worden er problemen achterhaald.
• Daarnaast is het voor respondenten makkelijker om feedback te geven op een structuur die ze aan het testen zijn, dan als ze bezig zijn met het structureren van zaken.
• Bij tree testing voeren de respondenten taken uit, dit is een betere weerspiegeling van de werkelijkheid dan het categoriseren van content. Daarom lijkt tree testing meer op een erg versimpelde observatie dan op een card sorting.

We kunnen tree testing dus zien als een goede aanvulling op het uitvoeren van een card sorting.

Voor- en nadelen en aandachtspunten

Voordelen

• We kunnen gemakkelijk de vindbaarheid van de ene versie vergelijken met die van de ander.
• We hebben korte iteratieslagen: Er kan snel gehandeld worden om de resultaten te verwerken in de website, waarna er nieuwe tree testing uitgevoerd kunnen worden, om deze weer opnieuw te implementeren, enzovoorts.
• Goedkoop en snel.
• We hebben niet veel nodig, alleen een idee van de te testen structuur.
• Het weerspiegelt hoe mensen daadwerkelijk met een website omgaan.
• We hebben geen schetsen of wireframes nodig.
• Makkelijk te leiden, omdat er maar één respondent is.
• Er zijn tools aanwezig / te maken om het uit te voeren.
• We kunnen in een vroeg stadium achter fouten komen, die we dan op tijd kan repareren. Op die manier zijn de reparatiekosten goedkoper, makkelijker en sneller.
• Locatiekeuze is erg flexibel

Nadelen

• Er komen geen nieuwe ideeën naar boven.
• Uitvoering kan lastig zijn voor de respondenten als de structuur erg complex is.

Aandachtspunten

• We testen alleen de structuur, dus niet het browsegemak van de bezoekers. Dit kan gezien worden als een voordeel: de respondent wordt niet afgeleid door andere factoren en richt zich alleen op de structuur, daarnaast weten we dat toekomstige problemen met vindbaarheid niet aan de structuur ligt. Maar het kan ook gezien worden als nadeel, want we komen er niet achter waar het probleem wel ligt, als het niet ligt aan de structuur.
• We kunnen geen kwantitatieve gegevens krijgen bij het uitvoeren van een één-op-één sessie waarbij we actief vragen stellen of met think aloud. De respondent voert namelijk taken langzamer uit als hij moet uitleggen wat hij aan het doen is, daarnaast kan hij vaker heen en weer gaan door de structuur om iets uit te leggen en niet omdat hij dit normaal gesproken ook zou doen. Gebruik dit daarom alleen om erachter te komen waarom iets een probleem is. Als we zowel kwantitatieve als kwalitatieve gegevens wil hebben, kunnen we na het uitvoeren van de sessie vragen stellen over waarom een respondent bepaalde taken op die manier uitvoerde.