Sjoerd van Gestel – 500617965
sjoerd.van.gestel@hva.nl
CMA Amsterdam
Afstudeerbegeleider: Marije ten Brink
V1.0 - dinsdag 10 juni 2014
EINDRAPPORT:
INTRODUCING UX TESTING IN AN APP
DEVELOPMENT PROJECT
Voorwoord
Bij de start van de studie CMD in september 2010 had ik alleen maar kunnen dromen dat ik zover gekomen zou zijn als waar ik nu ben beland. Ik heb bij aFrogleap mijn richting gevonden als Android ontwikkelaar. Ik heb veel te danken aan de kans die ik kreeg om zonder echte programmeerervaring toch als stagiaire aan de slag te gaan. Daarom wilde ik mijn afstudeerproject wijden aan iets waar het bedrijf mogelijk profijt van zou kunnen ondervinden. De focus kwam al snel te liggen op gebruikersonderzoeken, omdat dit nog geen deel uitmaakt van de ontwikkelcyclus van aFrogleap. Daarbij wilde ik kijken of ik een all-in-one oplossing kon creëren als prototype. De smartphone is per slot van rekening een zeer krachtige zakcomputer dus daar zou het niet aan kunnen liggen. Het ontwerp en de uiteindelijke bouw van het prototype beschouw ik persoonlijk als zeer geslaagd. Als ik terug kijk op het pad dat ik heb bewandeld om hier te komen, kan ik niet anders dan bekennen dat ik veel steun heb ontvangen van de mensen in mijn directe omgeving. De mentale steun van mijn lieve vriendin Rebecca, mijn ouders, schoonouders en vrienden. Zij waren er voor me op momenten dat ik het zwaar had of het even niet meer zo rooskleurig voor me zag. Een speciaal dankwoord gaat uit naar Linda voor haar geweldige steun op het gebied van taal. Mijn dyslexie is een handicap waar ik zelf redelijk mee om kan gaan, maar zonder haar scherpe oog voor taal- en stijlfouten had ik niet ver gekomen. Ook de opdrachtgever van dit project ben ik zeer dankbaar. Mijn stagebedrijf aFrogleap heeft me talrijke mogelijkheden gegeven dit project uit te voeren zoals ik het voor me zag. Ik heb veel gehad aan de feedback van Noor en Michiel, hun input is verweven door het gehele project heen. Voor allen die ik hiervoor genoemd heb en de mensen die ik vergeten ben: Bedankt voor alles!
Inhoudsopgaven
Voorwoord ... 1 Managementsamenvatting . 3 Inleiding ... 5 Probleemstelling ... 6 Hoofdvraag ... 6 Doelstellingen ... 6 Eindproduct ... 6 Onderzoekvragen en methoden ... 7 1 – Methodiek en werkproces bij aFrogleap ... 10 1.1 – Gehanteerd werkproces ... 10 1.1.1 – Sprints ... 101.2 – Het test proces ... 10
1.2.1 – Toekomstscenario . 11 1.2.2 – Hier en nu ... 11 1.3 – De methode in detail 12 1.3.1 – Testomvang ... 12 1.3.2 – Metrics ... 12 1.3.3 – Indeling ... 13 1.4 – Validiteit ... 13 1.4.1 – Omgeving... 13 1.4.2 – Gebruiker ... 14 1.4.3 – Testscenario ... 14 1.4.4 – Product ... 14 1.4.5 – Beoordeling ... 14 1.5 – Conclusie ... 15
2 – Het program van eisen 15 2.1 – Usecase analyse ... 15 2.1.1 – Vereisten voor doelgroep 1 ... 16 2.1.2 – Vereisten voor doelgroep ... 16 2.2 – Afleidingfactor ... 16 2.3 – Meetpunten ... 17 2.3.1 – Task timing ... 17 2.3.2 – Succes rate ... 18
2.3.3 – Task review + Thinking Aloud ... 18 2.4 – Conclusie ... 18 3 – Concretisering ... 18 3.1 – Applicatieflow ... 19 3.3 – Wireframes ... 19 3.3.1 – Test toevoegen ... 19 3.3.2 – Test uitvoeren ... 20 3.3.3 – Testgegevens terugzien ... 21 3.4 – Vormgeving en stijl ... 21 3.4.1 – Kleurgebruik... 21 3.4.2 – Lettertype ... 22 3.4.3 – Vormgeving ... 22 3.5 – Ontwerp ... 22 3.5.1 – Test introductie ... 22 3.5.2 – bedieningsmodule buiten de app ... 23 3.5.3 – Ondersteunende notificatie ... 23 3.5.4 – Interface... 24 3.6 – Technische invulling .. 24
3.6.1 – Begeleiding met Text To Speech ... 24
3.6.2 – Audio opname met stilte herkenning ... 24 3.6.3 – Floating view ... 25 3.6.4 – Root toegang ... 25 3.7 – Conclusie ... 25 H4 – Pilot test ... 25 4.1 – Testsessie ... 25 4.1.1 – Feedback proefpersonen ... 25 4.1.2 – Feedback testbegeleiders ... 26 4.2 – Conclusies ... 26 Onderzoek conclusies ... 27 Kanttekeningen & aanbevelingen ... 28 Persoonlijke reflectie ... 29 Bibliografie ... 30 Bijlagen ... 31 Vergelijkbare apps en services op het gebied van UX testing voor smartphones .. 31
Overzicht testmethoden .... 31
Interview: geschikte testmethode ... 32
Interface en afleiding ... 34
Hallway testing experiment: Thinking aloud ... 36
Root toegang ... 38
Prototype flowchart ... 39
Concept schetsen – fase 1 40 Concept schetsen – fase 2 . 45 Wireframe schetsen – eerdere versies ... 60
Wireframe schetsen – final versie ... 68
Schermontwerpen ... 73
Introductie script ... 78
Evaluatieverslag pilottest ... 79
Managementsamenvatting
De toenemende complexiteit van projecten bij aFrogleap heeft effect op het design van apps. Gebruikerservaring is hier erg belangrijk. Om dit te kunnen waarborgen moet er getest worden met echte gebruikers, maar dit wordt nog niet gedaan. Daarom richt dit project zich op het beantwoorden van de vraag:
Hoe kan een Android app data van hallway UX tests vanuit de achtergrond vastleggen, zodat hiermee de user experience van nieuw ontwikkelde apps kan worden getest binnen de ontwikkelcyclus?
Hallway testing staat hierin als testmethode centraal. De keuze hiervoor is voortgekomen uit interviews met het designteam van aFrogleap. De opzet en uitvoering zijn laagdrempelig en de data die het kan opleveren draagt bij aan het verbeteren van de gebruikerservaring van de apps.
De basis voor het antwoord op de hoofdvraag vormt het ontwerp van het prototype applicatie die bij het testen zal worden gebruikt. Hierbij staan de doelgroepen en hun behoeften centraal. De groepen zijn voortgekomen uit de analyse van usecase van een gebruikersonderzoek.
Groep 1 zijn testbegeleiders, deze rol wordt vertolkt door een lid van het design team. Voor deze groep is de taak het voorbereiden van een test en het analyseren van verzamelde testdata. Uit gesprekken met de doelgroep is naar voren gekomen dat het prototype data uit vier meetpunten vastlegt. Deze vier punten (task timing, success rate, task review en thinking aloud) zijn samen gekozen omdat hiermee een geheel beeld van de gebruikerservaring kan worden geschetst. Data wordt geregistreerd door het meten van gebruikersinput en door het opnemen van de stem. De testdata kan naderhand worden geanalyseerd om inzichten te verkrijgen voor verbetering van designs. De vastgelegde data moet wel betrouwbaar zijn, daarom is er een methode om de gegevens te beoordelen op validiteit. Hiervoor moeten de testgegevens op vier punten worden beoordeeld: omgeving, gebruiker, testscenario, product. Het beoordelingsproces moet waarborgen dat de verzamelde testdata ook representatief is voor de daadwerkelijke eindgebruiker en dat de inzichten die de analyse van de gegevens genereert zonder twijfel kunnen worden gebruikt in het ontwikkelproces.
Groep 2 zijn proefpersonen, deze worden vertolkt door de doelgroep van de applicatie waarop getest gaat worden. De behoeften voor deze doelgroep liggen in het uitvoeren van de test. Hierbij is uitleg en begeleiding belangrijk, maar zonder dat de gebruiker teveel wordt afgeleid. Onderzoek naar de manier van afleiding heeft uitgewezen dat het switchen van context of het overdekken van grote delen van het scherm zeer afleidend werkt, wat resulteert in onbetrouwbare testdata. Er is hier veel geëxperimenteerd met verschillende oplossingen, maar uiteindelijk is er gekozen voor een combinatie van een begeleidende computerstem en bediening via een zwevende bedieningsmodule. De bedieningsmodule is een kleine knop aan de rechter kant van het scherm, die wordt gebruikt om de test te kunnen uitvoeren. De knop biedt de gebruiker de mogelijkheid het huidige testdoel af te ronden als het is gelukt of niet. Ook is het mogelijk om de begeleidende stem het huidige doel nog eens te laten uitspreken. De begeleidende stem is een Android feature. De stem is vrouwelijk en klinkt redelijk overtuigend. De tone of voice voor de begeleiding bevat humor zodat het spreekwoordelijke ijs wordt gebroken en de proefpersoon zich meer op z’n gemak zal voelen.
Met de opsomming van de bovengenoemde punten hebben we het antwoord op de hoofdvraag: door vier
meetpunten (task timing, success rate, task review en thinking aloud) vanuit de achtergrond opnemen, waarbij de proefpersoon via spraak wordt begeleid, hardop denkt en de test kan bedienen via een zwevende bedieningsmodule. De opgenomen informatie kan worden terug gekeken / geluisterd om inzichten te krijgen in de gebruikerservaring van de getestte apps.
Voor het opzetten en uitvoeren van de testsessie waarbij het prototype wordt gebruikt dienen een aantal richtlijnen aangehouden te worden. Deze richtlijnen zijn opgesteld op basis van de kennis van usability experts uit het vakgebied. Per testsessie zijn 5 proefpersonen genoeg om 95% van de fouten in een ontwerp
bloot te leggen (Nielsen, 2000). Het uit te voeren scenario bestaat uit meerdere doelen van het type directed task (Nielsen & Budiu 2013 (p4)) omdat hiermee de applicatie waarop getest gaat worden vast staat. Het scenario moet voldoen aan een zo realistisch mogelijke usecase, om goed beoordeeld te kunnen worden bij het validatieproces.
Het uitvoeren van een testsessie waarbij het prototype is gebruikt en ook de richtlijnen aangehouden was positief. De proefpersonen vonden de ervaring van het testen prettig en konden de humor in the tone of voice waarderen. Het thinking aloud verliep redelijk, maar kan beter worden aangestuurd in de introductie. De introductie werd aan de lange kant bevonden, deze moet dus wat worden ingekort.
De analyse van de verzamelde testdata door leden van het designteam leverde inzichten en verbeterpunten op. Het belangrijkste inzicht was het gemis van visuele informatie door derden die de data analyseren. Het analyseren van de data door een ieder die niet aanwezig was bij het testen voelt blind aan. Dit vormt een probleem voor het overdragen van de data. Wanneer de aanwezige begeleider zelf de testdata analyseert is dit minder problematisch. Uit (onbewuste) observatie van de proefpersoon tijdens de sessie kan bij het horen van de audio opname een beeld worden gevormd. De audio opname van het hardop denken levert een gedetailleerd beeld van de gebruiker en diens emotie. Als hier schermopnamen aan worden toegevoegd maakt dit de informatie completer en zeer waardevol. De mogelijkheid hiervan moet verder worden onderzocht. Er is een theoretische mogelijkheid, maar of dit haalbaar is valt zonder verder onderzoek niet te zeggen.
Als vervolg van dit project zullen de verbeterpunten moeten worden uitgewerkt. Daarna zou er gekeken kunnen worden naar de mogelijkheid tot verdere integratie in het bedrijfsproces. Integratie met de gebruikte spintplanningstool heeft veel toegevoegde waarde. Zelfs zoveel dat het project als commercieel product zou kunnen worden voortgezet.
Inleiding
Het bedrijf aFrogleap is een full service mobiel bureau in Amsterdam dat sinds 2009 enorm aan de weg heeft getimmerd. Ze hebben al een scala aan interessante apps geproduceerd voor grote en kleinere namen. Hierdoor hebben zij nieuwe projecten weten aan te trekken met toenemende omvang en complexiteit. Deze opdrachtgevers willen in plaats van simpele apps complete services ontwikkeld hebben. Deze ontwikkeling heeft binnen het bedrijf de nodige veranderingen teweeggebracht om hier goed op in te kunnen spelen. Deze veranderingen boden mij de gelegenheid voor een onderzoek naar de mogelijke integratie van gebruikersonderzoek in de ontwikkelcyclus, om zo de gebruikerservaringen bij complexe projecten te kunnen valideren.
Mijn rol als Android ontwikkelaar en CMD professional is te onderzoeken hoe gebruikersonderzoek in de werkflow van aFrogleap past. Met daarbij als doel een prototype te ontwikkelen dat gebruikt kan worden voor het begeleiden van het onderzoek en het vastleggen van data uit dat onderzoek. Dit alles om bij te dragen aan een geweldige gebruikerservaring van apps die aFrogleap produceert.
Dit document is het resultaat van het onderzoek dat is uitgevoerd voor dit project. De indeling van het document ziet er als volgt uit:
• Probleemstelling
Wat is de startpositie van dit project? • Onderzoeksvragen en methoden
Opbouw onderzoek en gebruikte onderzoeksmethoden. • Methodiek en werkproces bij aFrogleap
Hoe wordt er gewerkt bij aFrogleap, hoe past gebruikersonderzoek in dit proces? • Het program van eisen
Waaraan moet het prototype voldoen? • Concertatie
Van idee, naar design , naar prototype. • Pilot test
Het validatieonderzoek voor dit project. • Conclusie
Wat is de uitkomst van alles tezamen? • Kanttekeningen & aanbevelingen
Gedachten en advies over de voortzetting na afloop van dit project. • Reflectie
Persoonlijke reflectie op het doorlopen traject.
Probleemstelling
De toename van complexiteit in mobiel georiënteerde projecten is het gevolg van een markt die volwassener aan het worden is1. Waar complexere systemen worden ontworpen, valt dat ook direct terug te zien in het design van apps. Veel meer functies, meer informatie en backend communicatie maakt dat ook de beleving voor de eindgebruiker drastisch is veranderd ten opzichte van simpelere apps. Het maken van apps draait uiteindelijk om de eindgebruiker. Als de beleving voor hun niet goed is, zullen zij de app niet gebruiken.
Om deze verandering goed op te vangen heeft aFrogleap recentelijk een switch gemaakt naar Scrum. Deze agile werkmethodiek maakt het mogelijk om apps veel doelgerichter te bouwen. Met korte sprints wordt gewerkt aan het toevoegen van nieuwe functionaliteiten. Designers en developers werken zij aan zij om zo binnen de sprint een werkend product op te leveren. De user story staat hier centraal en wordt als uitgangspunt gebruikt voor het valideren van design.
Het valideren gebeurt momenteel vrijwel exclusief door middel van de expert review methode. Echter is er met het toenemen van de complexiteit van projecten steeds meer vraag vanuit het design team om ook de eindgebruiker te betrekken in het proces. Dit levert een input die de keuzes kan valideren of sturen in de juiste richting. Om dit mogelijk te maken zou er een vorm van gebruikerservaring onderzoek moeten worden geïntroduceerd in de huidige projectstructuur.
Hoofdvraag
Hoe kan een Android app data van hallway UX tests vanuit de achtergrond vastleggen, zodat hiermee de user experience van nieuw ontwikkelde apps kan worden getest binnen de ontwikkelcyclus?
Doelstellingen
De hoofddoelstelling van dit project is het introduceren van gebruikerservaring onderzoek in de huidige projectstructuur van aFrogleap door middel van een eenmalige pilot. Deze pilot focust zich op één project (Mijn Team2) en zal daarbij één testsessie uitvoeren waaruit geëvalueerd kan worden of de gekozen aanpak en het prototype werkt.
Eindproduct
Er zijn diverse methoden om de gebruikerservaring van digitale producten te testen. Veel van deze methoden vereisen speciale omgeving, apparatuur of aanpassing van het digitale product om er mee te kunnen testen. Hier biedt het mobiele platform zeer interessante mogelijkheden. Smartphones zijn zeer krachtige computers met een scala aan sensoren die theoretisch ingezet kunnen worden voor het vastleggen van gegevens uit gebruikersonderzoeken.
Uit een eerste peiling blijkt ook nog eens dat er nog niets vergelijkbaars bestaat voor het Android platform (zie bijlagen “Vergelijkbare apps en services op het gebied van UX testing voor smartphones”). Daarbij ben ik zelf de aangewezen persoon om ook daadwerkelijk een werkend prototype bij dit project op te leveren. Het eindproduct van dit project is een werkend prototype voor Android Smartphones, waarmee een testsessie kan worden uitgevoerd waarvan gegevens worden opgeslagen voor latere analyse. Dit eindproduct zal worden gebruikt om aan de doelstelling van dit project te voldoen.
1 Mark de Bruin: Mobile marketing 2007-2014: apps worden volwassen en evolueren verder - https:// linkd.in/1p73dfJ 2 Mijn Team is een voetbal app voor amateur clubs, het app is al beschikbaar voor het publiek - http://www.mijnteamapp.nl/
6
Onderzoekvragen en methoden
Dit hoofdstuk behandelt de onderzoeksvragen die centraal staan binnen het onderzoek samen met de methoden die ervoor zijn gebruikt om tot een antwoord te komen. Bij iedere deelvraag en sub-deelvraag valt in het kort terug te lezen wat het onderzoek heeft opgeleverd, welke discussies er zijn ontstaan en wat voor conclusies hieruit getrokken kunnen worden. De verwijzing naar het hoofdstuk in de kern van dit rapport geeft een uitgebreide beantwoording op de desbetreffende deelvraag.
Deelvraag 1
Vraag: Welke usability test methode past het beste bij de ontwikkelcyclus die bij aFrogleap gehanteerd wordt?
Methodiek: Deskresearch, Interview / gesprek Objectieve resultaten:
• Geconstrueerde lijst met testmethoden met details • Geschikte testmethoden voor project
Discussie:
• Welke usability test methodes worden er gekozen bij het schetsen van een ultiem toekomstscenario.
• Welke methode zou een eerste stap in die richting kunnen vormen? Conclusie:
• Remote user testing gezien als de meest bruikbare methoden voor toekomst. Testen met echte users in meer realistische omgeving, al dan niet begeleid.
• Hallway usability testing geschikte methoden voor eerste stap. Laagdrempelig, vrij genoeg om te kunnen experimenteren. Project als pilot met focus op 1 app: Mijn team.
Behandeld in hoofdstuk: 1.2 - Het test proces
Sub-deelvraag 1.1
Vraag: Wat houdt de gekozen methode in voor het verzamelen van testdata? Methodiek: Deskresearch
Objectieve resultaten:
• Achtergrond voor gekozen testmethoden. Details voor het opzetten en uitvoeren. • Achtergronden over meetpunten bij het uitvoeren van gebruikersonderzoeken. • Verschillende categorieën te verzamelen testdata: independent en dependent.
Conclusie: Ideale grootte van testopzet is 5 per testdoel. Dit op basis van de usability problems curve diagram van Jacob Nielsen.
Behandeld in hoofdstuk: 1.3 - De methode in detail
Deelvraag 2
Vraag: Hoe kan het testen worden geïntegreerd in het bestaande werkproces? Methodiek: Observatie, Interviews
Objectieve resultaten:
• Inzicht in werkproces/projectstructuur van aFrogleap. • Scrum methode met sprints.
Discussie: Waar past het testen binnen de projectloop?
Conclusie: Er wordt in een sprint naar een werkende versie toegewerkt. Aan het einde van een sprint vindt een moment van testen plaats. In deze tijd zou er een testsessie kunnen worden uitgevoerd. De resultaten van deze sessie kunnen daarna worden geanalyseerd. Verbeterpunten kunnen direct aan de backlog worden toegevoegd zodat ze bij de volgende sprint worden verbeterd.
Behandeld in hoofdstuk: 1.1 - Gehanteerd werkproces
Deelvraag 3
Vraag: Hoe kan de verzamelde testdata op validiteit worden beoordeeld? Methodiek: Deskresearch
Objectieve resultaten: Validiteit van gebruikerservaring onderzoeken op basis van vier punten worden beoordeeld: omgeving, gebruiker, testscenario, product.
Discussie: Hoe moet er bij het vastleggen van testgegevens rekening worden gehouden met deze vier punten?
Conclusie: Door bij het testen independent values zoals leeftijd, smartphone type, locatie van test vast te leggen, kan achteraf worden geëvalueerd of de test valide is op de punten omgeving en gebruiker. Voor testscenario zullen bij het creëren van de tests zo realistisch mogelijke usecase worden gebruikt. Het product waarop wordt getest moet zo dicht mogelijk bij het eindproduct staan, omdat er in sprints werkende versies worden opgeleverd kan er bij het testen daarop gericht worden.
Behandeld in hoofdstuk: 1.4 - Validiteit
Deelvraag 4
Vraag: Waar moet het prototype Android app aan voldoen om testdata tijdens het testen vast te leggen? Methodiek: Deskresearch, Interview / gesprek, Experiment, Prototyping
Objectieve resultaten:
• Een lijst met meetpunten geschikt voor de gekozen vorm van gebruikerservaring onderzoek. • Een keuze in meetpunten die samen een geheel beeld kunnen vormen over het volbrengen van
een taak door een proefpersoon.
• Inzichten in de manier hoe proefpersonen omgaan met hardop denken. • Technische haalbaarheid van gekozen meetpunten
Discussie:
• Welke meetpunten vormen samen een duidelijk beeld van de gebruiker tijdens het volbrengen van een taak?
• Zijn deze meetpunten makkelijk realiseerbaar? • Hoe gaan gebruikers om met het hardop denken?
Conclusie: Er is gekozen voor de volgende vier meetpunten: task timing, success rate, task review, thinking aloud. Deze vier meetpunten geven een totaal overzicht. Waarbij thinking aloud zeer belangrijk is voor het inzicht in de gedachtegang van de proefpersoon. Uit het experiment blijkt dat afleiding en gemoedstoestand (je op je gemak voelen) zeer belangrijk zijn. De technische uitvoerbaarheid van de gekozen meetpunten blijkt realistisch op basis van een proof of concept.
Behandeld in hoofdstuk: 2.3 - Meetpunten vaststellen
Sub-deelvraag 4.1
Vraag: Welke behoefte heeft de gebruiker? Methodiek: Interview / gesprek
Objectieve resultaten: Minimale eisen voor de twee doelgroepen aan de hand van de analyse van een usecase.
Discussie: Wie is onze doelgroep?
Conclusie: De doelgroep is in tweeën te delen: testbegeleiders & proefpersonen. Iedere groep heeft zeer specifieke vereisten die niet met elkaar overeen komen.
Behandeld in hoofdstuk: 2.1 - Doelgroep
Sub-deelvraag 4.2
Vraag: In hoeverre mag het prototype zichtbaar zijn voor de proefpersoon? Methodiek: Deskresearch, Prototyping
Objectieve resultaten: Inzicht in de manier van omgang van context en posture
Discussie: Hoe om te gaan met de interactie tussen prototype en testonderwerp, zonder de testresultaten te beïnvloeden.
Conclusie: Het breken van de flow van de proefpersoon heeft negatieve effecten op de algehele ervaring. Hierdoor is duidelijk geworden dat het switchen van context moet worden voorkomen. Dit kan worden bereikt door de interactie tussen het prototype via een floating window te laten plaatsvinden, zodat de context van het testen niet verandert.
Behandeld in hoofdstuk: 2.2 - Afleidingsfactor
Deelvraag 5
Vraag: Welke Android functionaliteiten of hardware features kunnen bij het testen op usability worden gebruikt?
Methodiek: Deskresearch, Prototyping
Objectieve resultaten: Een overzicht van gebruikte feature van de smartphone die worden gebruikt bij het vastleggen van de meetpunten bij het testen. Voor alle meetpunten diverse software feature gebruikt, voor sucess rate, task review wordt microfoon van het toestel gebruikt. Voor de testbegeleiding worden de speakers gebruikt.
Discussie: Kan de proefpersoon worden ingelicht als er niet hardop wordt gedacht?
Conclusie: Door de audio opnamen te analyseren tijdens het opnemen kan er stilte worden waargenomen. Na een onafgebroken stilte van 15 seconden wordt de gebruiker gevraagd hardop te denken.
Behandeld in hoofdstuk: 3.4 – Technische invulling
Sub-deelvraag 5.1
Vraag: Is het wenselijk om features te gebruiken waar root toegang voor is vereist? Methodiek: Deskresearch, Interview
Objectieve resultaten: Inzicht in de reden voor rooten, de voor en nadelen.
Discussie: Is het wenselijk / vereist roottoegang nodig te hebben voor het prototype applicatie.
Conclusie: Roottoegang brengt veiligheidsrisico’s met zich mee, de meeste testtoestellen zijn daarom ook niet geroot. Het is daarom niet wenselijk. Vanuit een technische achtergrond is roottoegang niet vereist. Het prototype maakt geen gebruik van functionaliteiten die dit vereisen.
Behandeld in hoofdstuk: 3.6.4 - Root toegang
1 – Methodiek en werkproces bij aFrogleap
Er zijn diverse methoden om de gebruikerservaring van digitale producten te testen. Omdat elke testvorm een andere aanpak vereist en andere data / inzichten oplevert moet er worden overwogen welke methoden het beste geschikt zijn. Om hier achter te komen moet er worden gekeken naar diverse aspecten. Hoofdzakelijk moet de methode passen bij het werkproces die bij aFrogleap wordt gehanteerd, daarbij ook data / inzichten opleveren die geschikt zijn om de gebruikerservaringen van projecten te valideren. Hiervoor nemen we eerst het werkproces onder de loep.
1.1 – Gehanteerd werkproces
Ongeveer een half jaar geleden is er een ommezwaai gekomen in de projectopzet. Er werd tot dan gewerkt volgens de waterval methodologie, wat al zo was sinds de oprichting van het bedrijf. Inmiddels wordt er gewerkt met de scrum methodologie. Scrum3 is een flexibele (agile) werkmethodiek die het ontwikkelen van complexe projecten opdeelt in stukjes (sprints) die op elkaar voortbouwen. Het werken onder deze structuur maakt het een stuk eenvoudiger om complexe projecten gefaseerd tot een goed einde te brengen.
1.1.1 – Sprints
Projecten zijn opgedeeld in sprints van één of meerdere weken. Iedere sprint heeft als doel een werkende versie van het product op te leveren. Idealiter start een project met sprint zero. In deze eerste sprint kan worden gewerkt aan designs door de designers zodat er in sprint one direct kan worden begonnen met het ontwikkelen. Op deze manier heeft het designteam altijd een sprint voorsprong om zo genoeg tijd te hebben. Omdat het echter niet altijd loopt volgens het ideale pad kan het voorkomen dat het design niet voorloopt maar gelijk op gaat. In dit geval werken de ontwikkelaars vaak aan taken die nog geen design vereisen of doen voorwerk totdat de designs zijn goedgekeurd.
Wat voor werk er uitgevoerd gaat worden in een sprint wordt vooraf bepaald. In een zogeheten sprint meeting worden de doelen bepaald aan de hand van user stories4 die in de product werklijst (backlog) staan. Hiermee wordt een sprint werklijst (sprintlog) gevuld die het werk voor de komende sprint omvat. Een user story bestaat uit een omschrijving van een gebruiker en wat hij te weten wil komen of het doel dat hij wil bereiken (voorbeeld: As a user I want to know if my message was sent). Aan de hand van deze omschrijving kunnen tickets worden gecreëerd die het werk omvatten om het doel te verwezenlijken. Aan het einde van een sprint kunnen de user stories worden gebruikt om het werk te valideren middels testen. Het testen gebeurt in principe gedurende de gehele loop van een project, aan het einde van elke sprint. De gevonden problemen worden aan de nieuwe sprintlog toegevoegd, in de volgende sprint worden ze verholpen. De testfase in een sprint lijkt daarom een goed moment om de gebruikerstests uit te voeren en daarmee te integreren in het bestaande werkproces. Problemen die aan het licht zijn gekomen kunnen aan de backlog worden toegevoegd, zodat ze in de volgende sprint worden aangepakt.
1.2 – Het test proces
Binnen aFrogleap testen de verantwoordelijke designers de applicaties vaak zelf. Uit gesprekken met Noor Schopman (hoofd van het design team bij aFrogleap) en Michiel Essen (lead Android designer bij aFrogleap) kon dan ook een hoop worden opgemaakt uit de huidige testmethoden. De manier van testen die door hun werd omschreven leek het meeste overeen te komen met een vorm van expert review(Zie bijlagen “Interview: geschikte testmethode”). In de tests wordt er gekeken naar inconsistenties in designimplementatie. Daarnaast wordt er gezocht naar crashes en bugs in de applicatie.
Een tweede methode die uit de gesprekken naar voren kwam was het gebruik van usage analytics. Applicaties worden uitgerust met een analytisch platform zoals Flurry5. Deze leveren gedetailleerde gebruikersstatistieken op. Er kan tot in detail worden gezien hoeveel gebruikers er gebruik maken van
3 Zie voor een gedetailleerde uitleg over de scrum methodologie: https://www.scrum.org/Resources/What-is-Scrum 4 Zie voor een gedetailleerde uitleg over userstories: http://guide.agilealliance.org/guide/user-stories.html
5 Flurry analytics is een platform waarmee gebruikers statistieken uit apps kunnen worden vastgelegd. http://www.flurry.com/
10
bepaalde features in de applicatie. Echter wordt deze informatie zelden ingezet voor het verbeteren van applicaties. Wel worden ze gebruikt als prestatie cijfers voor apps.
Een tweede analytisch platform dat wordt gebruikt is Crashlytics6. Hiermee worden fouten en crashes in apps vastgelegd. Met de inzichten die hieruit naar voren komen kunnen problemen in bestaande apps zeer doelgericht vastgesteld en opgelost worden.
1.2.1 – Toekomstscenario
Tijdens de individuele gesprekken die werden gevoerd met de leden van het design team kwam een toekomstscenario ter sprake. Dit scenario zou de perfecte invulling van user testing zijn binnen een willekeurig project, zonder rekening te houden met eventuele uitvoeringsbelemmeringen. Bij het samenstellen van dit perfecte scenario werd er gebruik gemaakt van een lijst met bruikbare methodiek. Deze lijst zag er als volgt uit7:
Beide designers hadden na een korte bedenkperiode een invulling van de methoden die zij in het toekomstscenario vonden passen. De uitkomst was deels gelijk, waarbij ze beide voor remote ux testing kozen. Deze methode was volgens hun zeer interessant voor het bedrijf omdat er getest kan worden met echte gebruikers in de passende context van het product. Dit zagen zij als een zeer belangrijk punt dat in veel van de andere opzetten niet of maar deels mogelijk zou zijn.
Ook bij de overige methoden was een overeenkomst te bespeuren. Beiden hadden voorkennis met het werken met deze methode. Hier valt niet met zekerheid over te zeggen of hun onderbouwing voor deze keuze is gebaseerd op die voorkennis of dat ze het daadwerkelijk een goed passende methode vinden. De afgevallen methoden waren A/B testing en Automated expert review.
1.2.2 – Hier en nu
Hoe de uitvoerbaarheid en realiseerbaarheid bij het toekomstscenario geen invloed hadden op de keuze van methoden, is dat nu wel het geval. De uitvoerbaarheid moet uiteraard passen binnen de scoop van dit project en de ontwikkelcyclus van aFrogleap.
Remote ux testing zou een te grote technisch uitdagende opzet vergen. Een opzet waarbij de gebruiker kan worden geïnstrueerd, kan meten en detecteren wat de gebruiker vervolgens doet en dit bewaren en opsturen. Deze opzet kan technisch een grote uitdaging zijn volgens experts uit het vakgebied. Vooral een moderated sessie, waarbij iemand mee kijkt en instructies kan geven in real time kent een aantal grote obstakels (Alfonso de la Nuez besprak de mogelijkheden van remote testing tijdens het jaarlijkse MoDevUX conference, (Nuez 2013)).
Het is nu dus van belang dat de methode haalbaar zal zijn, maar toch inzichten oplevert over de gebruikerservaring. Met deze doelstelling bleek het kiezen van een methode wat lastiger. Er volgden korte discussies waarin de afweging werd gemaakt tussen de verschillende voor en nadelen van iedere methode. Uiteindelijk bleef in beide gevallen de methode Hallway testing over als meest geschikt.
De manier van opzet van deze methode lijkt simpel van aard, maar dit geeft een hoop bewegingsvrijheid. Dit geeft ruimte om te experimenteren met een prototype die bij het testen data vastlegt. Het meten van de gebruikersinput en het verkrijgen van feedback met het prototype zijn in dat opzicht te vergelijken met een remote ux test. Dit zou betekenen dat deze keuze voor hallway testing een eerste stap zou vormen richting het toekomstscenario dat eerder werd geschetst. Het voorbereiden en uitvoeren van een test zou 6 Crashlytics is een uitgebreid error registratie systeem voor Android en iOS http://try.crashlytics.com/
7 Voor de volledige lijst zie bijlagen “Overzicht testmethoden” • Klassieke usability testing
• Remote UX testing – Moderated / Unmoderated • Expert review
• Automated expert review (Automated tests) • A/B testing
• Hallway testing
• Focus groups • Beta-testing • User surveys
• Usage analytics (google analytics) • User diaries
• User interviews
11
prima kunnen passen in de testfase aan het einde van een sprint. Dit maakt dat hallway testing als methode zeer goed lijkt te passen bij de ontwikkelcyclus die bij aFrogleap gehanteerd wordt.
1.3 – De methode in detail
Nu er meer afbakening heeft plaatsgevonden is het tijd om dieper in de gekozen methode te duiken. Wat houdt hallway testing nou precies in? Om meer over deze methode te weten te komen moeten we op zoek gaan naar een persoon die ons hier meer over kan vertellen. Deze zoektocht brengt ons bij Joel Spolsky, software ontwikkelaar en auteur van diverse boeken over het onderwerp usability8. Met zijn ervaring weet Spolsky de methode kinderlijk eenvoudig uit te leggen:
A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. Spolsky (169)
De opzet lijkt dus zeer laagdrempelig, iets wat als positief kan worden gezien in de opzet van de pilot. Daarbij biedt het hulp het idee dat gebruikerstesten omslachtig zijn te weerleggen. Het dwingen van mensen laten we echter achterwege, dit lijkt op een komische noot van de auteur en zou in het echt niet nodig moeten zijn.
1.3.1 – Testomvang
De omvang van de test is een belangrijke factor voor de pilot. Hoe meer mensen er nodig zijn, hoe lastiger de uitvoerbaarheid wordt. Echter is het belang van succes ook iets wat mee weegt. Waar ligt de gouden grens voor usability testing? Hiervoor raadplegen we de kennis van usability veteraan Jakob Nielsen. Nielsen heeft hiervoor een formule ontwikkeld. Door middel van deze formule is uit te rekenen wanneer de effectiviteit van een usablitity test is bereikt.
In earlier research, Tom Landauer and I showed that the number of usability problems found in a usability test with n users is:
N (1-(1- L ) n ) where N is the total number of usability problems in the
design and L is the proportion of usability problems discovered while testing a single user. The typical value of L is 31%, averaged across a large number of projects we studied. Plotting the curve for L =31% gives the following result: Zie figuur 19 (Nielsen 2000)
De curve geeft goed weer dat een test met twee gebruikers al bijna 50% van de potentiele usablitity problemen oplevert. Na vijf neemt dit echter hard af en pas bij vijftien wordt de 100% bereikt. Dit sluit naadloos aan op het antwoord dat Spolsky hierop gaf:
If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.
Spolsky (169)
Grotere groepen dan vijf leveren dan ook minder op voor meer inspanning. Dit houdt voor de gekozen methode in dat een set van 5 uitgevoerde sessies voldoende inzichten moeten geven om zo’n 95% van alle problemen te vinden binnen de testscope.
1.3.2 – Metrics
Het uitvoeren van gebruikerstesten geeft op diverse manieren inzichten aangaande het testonderwerp. Er kan ten tijde van de test ook data worden verzameld. Deze data wordt uit verschillende meetpunten vastgelegd voor latere analyse. Deze data (ook wel metrics genoemd) vormen de basis voor het validatieproces van de gebruikerservaring. We willen er nu achter komen welke metrics middels welke meetpunten kunnen worden vastgelegd.
Bij een hallway test wordt de proefpersoon gevraagd een set opdrachten achter elkaar uit te voeren. Deze opdrachten zijn doelen die de proefpersoon probeert te bereiken. Nielsen maakt hierin twee verschillen in opdracht en uitkomst:
8 Joels Spolskys boeken overzicht: http://www.joelonsoftware.com/BuytheBooks.html
9 Bron afbeelding figuur 1 http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ Figuur 1
12
The open-ended tasks let users decide what app or website they would use to complete the task. The directed tasks indicate the app or website that the user had to use. Nielsen & Budiu 2013 (p4)
Een testopzet met open-ended tasks heeft als doel erachter te komen welke keuze de proefpersoon maakt om zijn taak te verwezenlijken. Dit komt niet overeen met het doel dat dit project heeft. De directed task is daar in tegen wel geschikt, hierin staat namelijk het project al vast en laat je de gebruiker binnen die context gerichte taken uitvoeren.
We gaan er nu vanuit dat de proefpersoon bij de test directed task uitvoert. Tijdens het uitvoeren van de opdrachten kunnen er op diverse manieren metrics worden vastgelegd. Zoals de lijst hieronder weergeeft zijn er veel opties10. Veel van de meetpunten kunnen ook samen worden ingezet om zo een scala van metrics te verzamelen voor analyse naderhand.
De lijst met meetpunten geeft goed weer dat er heel veel gemeten kan worden. Echter moet er voor de scope van dit project wel verder afgebakend worden welke meetpunten er in het prototype verwerkt gaan worden. Hierin kan een afweging gemaakt worden tussen complexiteit van implementatie en de inzichten die het oplevert. Dit gebeurt in hoofdstuk 2.
1.3.3 – Indeling
Er kan dus een zeer breed scala aan metrics uit de test worden vastgelegd. Dit betekent wel dat de metrics allemaal in een ander formaat zijn. De tijd die het duurt om een taak te volbrengen is een tijdsaanduiding in seconden of milliseconden. De metrics uit eye tracking zouden coördinaten kunnen zijn of video die vastgelegd is. Taak review zou bijvoorbeeld weer in tekst of audio opnamen kunnen zijn. Erg divers dus, maar er is een manier om de metrics die is verzameld in te delen in categorieën: independent en dependent.
Independent variables are the things you manipulate or control for, such as designs you’re testing or the ages of your participants. Dependent variables are the things you measure, such as success rates, number of errors, user satisfaction, completion times, and many more. Albert & Tullis (16)
Gedurende het testen zal er vooral worden gefocust op dependent informatie. Deze metrics komt voort uit het gebruik van de app door de proefpersoon. De independent metrics wordt rondom de test verzameld. Locatie, leeftijd en geslacht zijn hier voorbeelden van. Deze informatie is nodig om de verzamelde dependent metrics te valideren.
1.4 – Validiteit
De metrics die met de gebruikerstesten worden verzameld dienen net als andere onderzoek vormen, valide van aard te zijn. Met de term valide wordt bedoeld in welke mate de verzamelde testgegevens kunnen worden vertrouwd (Zie voor een uitgebreide achtergrond over validiteit Goodwin 131-133). Om de validiteit van een uitgevoerde gebruikerstest te kunnen beoordelen moet het bekend zijn dat een test de werkelijkheid zo goed mogelijk simuleert. Dit betekent simpel gezegd dat het daardoor 100% waar kan zijn (Chrisnell, Rubin 25-26). Er zijn vier factoren die hier invloed op uitoefenen: omgeving, gebruiker, testscenario en product (Andreas 13-16).
1.4.1 – Omgeving
De omgeving (ook wel context genoemd) waarin een applicatie wordt gebruikt is veelal van invloed op de gebruikerservaring. Omdat een test een simulatie is valt dit gedeelte weg. Neem als voorbeeld de NS Reisplanner app. Deze app wordt door veel mensen vrijwel alleen onderweg gebruikt. Beeld jezelf in dat je
10 Lijst gevormd op basis van het boek Albert & Tullis, 2013 • Wat voor gebruiker is het? (user details) • Waar kijkt de test gebruiker? (eye tracking) • Waar klikt de test gebruiker? (click tracking) • Hoe snel is de taak voltooid? (task timing) • Kon de taak worden voltooid? (succes rate) • Wat zijn de gedachten na het volbrengen van
de taak? (task review)
• Wat voor lichaamshouding straalt de test gebruiker uit? (bodylanguage)
• Wat denkt de gebruiker? (thinking aloud)
• Hoe moeilijk was het volbrengen van de taak?
(difitculty rate)
• Hoeveel fouten maakte de test gebruiker? (number
of errors)
13
onderweg naar het station bent en er halverwege achter komt dat je trein over 30 seconden vertrekt. Probeer dat maar eens te simuleren in een rustige ruimte. Nu hebben niet alle apps zulke usecases als in het voorbeeld. Vaak kan een test in een rustige ruimte enigszins voldoen. Al moet hier wel rekening mee worden gehouden.
Als de context van de app nou overeenkomt met een publieke ruimte zoals een koffiehuis, kan er altijd gebruik gemaakt worden van de Guerilla Usability Testing11. Hier kan de omgeving gewilde afleiding genereren. Gewilde afleiding is vorm van afleiding die overeenkomt met daadwerkelijk gebruik. Deze manier van testen is zeker niet exclusief voor apps die een overeenkomst hebben in de context, het is namelijk ook een zeer doeltreffende manier om aan poefpersonen te komen. Gewapend met een muffin of een kopje koffie zijn ze al snel bereid proefpersoon te zijn.
1.4.2 – Gebruiker
De proefpersoon bij een gebruikerstest voldoet idealiter aan de doelgroepomschrijving die voor de applicatie is gesteld. Echter gaat een doelgroep nog veel dieper dan alleen leeftijd en geslacht. Sociale invloeden, geloofsovertuiging, werk, vrijetijdsbesteding, muziekvoorkeur, merkloyaliteit enz. zijn hierop allemaal van invloed. Bij hallway usablity testing is het echter zo dat er gebruik wordt gemaakt van passanten. Hierdoor is de selectieprocedure iets soepeler. Wel moeten deze passanten ongeveer aan de doelgroep voldoen. Ondanks dat dit bij de testmethode hoort moet dit wel worden meegenomen in het oordeel over de validiteit van de onderzoeksresultaten.
1.4.3 – Testscenario
Bij een gebruikerstest wordt er vrijwel altijd gewerkt met gebruiksscenario’s. Dit kunnen doelen / taken in opeenvolging zijn, of een compleet uitgeschreven scenario. Welke vorm dan ook, het heeft als doel gebruik te simuleren. Het is hier belangrijk dat het scenario zo dicht mogelijk bij de werkelijkheid staat. De moeilijkheidsgraad moet ook overeenkomen met die van een realistische setting. Dit matcht met de opzet van gewilde afleiding. Dit voegt een laag van realisme toe aan het testscenario en heeft een positief effect op de validiteit. Anderzijds heeft het een negatief effect hierop.
1.4.4 – Product
Testen gebeurt in de meeste gevallen voordat het applicatie ontwikkelproces is afgerond. De staat waarin de applicatie zich bevindt hangt af van het testmoment. Dit kan dus een onaf product of zelfs een prototype zijn. Als het prototype niet in vergelijking staat met de uiteindelijke versie, heeft dit aanzienlijke gevolgen voor de validiteit van de testgegevens.
Een agile werkmethode heeft hier echter een voordeel. Zoals al eerder is beschreven heeft het doel van werken met sprints het opleveren van een product dat zou kunnen worden gepubliceerd (live zetten). In theorie kan er aan het einde van een sprint, of in de volgende dus worden getest met een versie van de applicatie die af is.
1.4.5 – Beoordeling
Er moet bij het uitvoeren van gebruikerstesten al rekening worden gehouden met het validiteitsproces. Dit houdt in dat Independent variables worden vastgelegd die de boven genoemde factoren dekken. Met deze informatie kan achteraf de validiteit van de gegevens worden beoordeeld. Als gegevens niet valide worden beoordeeld is het onverstandig om de resultaten op te nemen in het ontwikkelproces. Neem als voorbeeld een app met de doelgroep “Ouderen (60-75)”. Als er met jongeren wordt getest kan het zijn dat zij alles duidelijk vinden. Pas wanneer de app in handen van de daadwerkelijke doelgroep valt blijkt dat deze het
11 Achtergrond in Guerilla usbaility testing & bron afbeelding figuur 2 http://www.uxbooth.com/articles/the-art-of-guerilla-usability-testing/
Figuur 2 - Guerilla Usability Testing
14
niet duidelijk vinden door hun achtergrond. Zij hebben bijvoorbeeld minder ervaring, meer moeite met het lezen van de tekstgrootte of interpretatie van iconen. Dit toont aan dat de testgegevens niet valide waren.
1.5 – Conclusie
Dit hoofdstuk heeft een hoop inzichten gegeven voor de verdere voortgang van dit project. Op deelvraag 1: welk usability test methode past het beste bij de ontwikkelcyclus die bij aFrogleap gehanteerd wordt? zijn we uitgekomen op hallway testing vanwege de laagdrempelige opzet en dat het de eerste stap vormt richting het geschetste toekomstscenario. Op sub-deelvraag 1.1: wat houdt de gekozen methode in voor
het verzamelen van testdata? hebben we kunnen vaststellen dat de ideale testgrootte van 5 sessies per
scenario bedraagt, omdat hiermee al zo’n 95% van de problemen aangetoond kunnen worden. Het soort opdracht dat tijdens het testen wordt uitgevoerd is van het type directed task, omdat we gericht zijn op het testen van een door ons gekozen app. Deelvraag 2: hoe kan het testen worden geïntegreerd in het
bestaande werkproces? heeft ons laten kijken naar het werkproces van aFrogleap. Er wordt gewerkt in
sprints, waarbij aan het einde van een sprint tijd is ingepland voor het testen van het verrichtte werk. Het testen zou hierin uitgevoerd kunnen worden en past daarmee in het bestaande werkproces. Tot slot hebben we voor deelvraag 3: hoe kan de verzamelde testdata op validiteit worden beoordeeld? een manier tot validiteitsbeoordeling gevonden. Bij het uitvoeren van gebruikerstests moet rekening worden gehouden met vier punten: omgeving, gebruiker, testscenario, product. Hierbij is het nodig om independent metrics bij het testen vast te leggen, omdat hiermee de validiteit kan worden bepaald.
2 – Het program van eisen
De opzet van een gebruikerstest kan veel voeten in de aarde hebben. Afhankelijk van het soort test en het platform heb je al snel een aardige waslijst met benodigdheden. Moderne smartphones hebben echter een enorm scala aan hardware en software mogelijkheden die veel van deze benodigdheden overbodig maken. In dit hoofdstuk gaan we op zoek naar de benodigdheden voor het maken van een Android applicatie die bij de pilot gebruikt kan worden. Deze applicatie (vanaf heden aan gerefereerd als prototype) heeft als doel metrics uit de test vast te leggen. Op welke manier dat gaat vinden we uit door onder andere te kijken naar de doelgroep.
2.1 – Usecase analyse
Het prototype is anders dan bij een normale applicatie niet bedoeld voor het grote publiek. Dit neemt niet weg dat de applicatie een doelgroep heeft. Het vaststellen van de doelgroep verschaft inzichten in de richting waarin de applicatie ontwikkeld gaat worden. Het geeft richting in het designproces en geeft de mogelijkheid tot toetsing van ideeën. Hiervoor moet er in kaart worden gebracht wat de gebruiker nodig heeft. Hiervoor moeten we weten wie de gebruikers van het prototype zullen zijn. Hierin zijn twee groepen vast te stellen, namelijk: testbegeleiders en proefpersonen. Gebaseerd op deze twee groepen is er al veel vast te stellen over de wijze van gebruik van het prototype. Een gebruiksscenario kan ons deze inzichten geven.
De test begeleider is voorafgaande aan de user test bezig met de voorbereiding. De test wordt gecreëerd en geconfigureerd. Als de test is voorbereid kan de sessie worden begonnen. De eerste proefpersoon wordt “van de gang geplukt”. De begeleider heet de proefpersoon welkom en geeft de testtelefoon. De proefpersoon krijgt een korte uitleg over de werking van de test, de manier hoe hij te werk moet gaan en hoe de bediening werkt. Hierna volgt de rol waar vanuit hij de taken zal gaan uitvoeren. Zodra hij bekend is met zijn taak wordt de test gestart. De proefpersoon voert zijn taak uit, waarbij hij alle stappen hardop uitspreekt. Als de taak is volbracht geeft hij dit aan, de nieuwe taak wordt nu uitgelegd. Gedurende deze tijd houdt de begeleider zich afzijdig zodat de proefpersoon zo zelfstandig mogelijk kan werken. Zodra de proefpersoon klaar is met de test wordt deze beëindigd. Wanneer de laatste test is afgerond wordt de proefpersoon een kopje koffie aangeboden en natuurlijk bedankt voor zijn of haar medewerking. De begeleider kan de resultaten van de test terugkijken.
Er zijn drie fasen te herkennen in dit scenario: voorbereidend, uitvoerend, analyserend. Per groep binnen de doelgroep zijn er grote verschillen te herkennen in gebruik. De poefpersoon behoudt zich tot de uitvoerende fase. De testbegeleider heeft raakvlakken met alle fases.
2.1.1 – Vereisten voor doelgroep 1, testbegeleider
De testbegeleider zoals deze in het gebruiksscenario wordt omschreven, zal in werkelijkheid worden ingevuld door iemand van het designteam. Dit in samenhang met de huidige projectopzet, waarin de verantwoordelijke het testproces uitvoert. Samen met het designteam is er op basis van het gebruiksscenario een lijst met vereisten opgesteld die zijn te vertalen naar concrete functies.
2.1.2 – Vereisten voor doelgroep 2, proefpersoon
Zoals we in hoofdstuk 1 al hebben vastgesteld geldt voor een hallway test een iets vrijere slag voor het kiezen van de proefpersonen, omdat het toevallige passanten zijn waarmee de test wordt uitgevoerd. Als verdere richtlijn voor het afstemmen van proefpersonen die geschikt zijn moet er gekeken worden naar de app die wordt getest. Daar het voor dit project vast staat op Mijn Team kan daar naar gekeken worden. Voor nu maakt dit echter weinig verschil. We nemen daarom weer het gebruiksscenario zodat we ook voor deze groep de vereisten kunnen vaststellen, wederom in samenspraak met het design team. Deze vereisten zijn ook weer te vertalen naar concrete functies in het prototype.
De meeste vereisten voor deze doelgroep vinden plaats buiten de context van het prototype. Dit vormt een interessante zaak voor het ontwerpproces. Er zijn hier verschillende zaken waar rekening mee moet worden gehouden. Voorop staat dat het prototype app de testresultaten niet mag beïnvloeden. Op welke manier, dat hangt af van de mate waarop afleiding een rol speelt tijdens het testen.
2.2 – Afleidingfactor
Afleiding, we zijn er naar op zoek of het vindt ons. Als het ons weet te vinden gebeurt dat in de meest uiteenlopende vormen. Bij het uitvoeren van een user experiance test kan afleiding de resultaten zowel negatief als positief beïnvloeden. Ze zijn daarom in te delen in twee categorieën: gewilde en ongewilde afleiding.
We hebben het al even kort gehad over gewilde afleiding, maar laten we er toch nog even goed naar kijken. Gewilde afleiding is vorm van afleiding die ook bij het daadwerkelijke gebruik voorkomt. De prestaties van testgebruikers in een rustige omgeving zijn beter dan die van de eindgebruiker in de echte omgeving. Bij het uitvoeren van de test zouden deze afleidingen dus wel aanwezig moeten zijn om een realistischer beeld over de taakvolbrenging te krijgen (Thrift 2012).
Onder ongewilde afleiding valt alles wat tijdens de test aan afleiding word geïntroduceerd. Hier zijn de vier factoren waarop validatie wordt beoordeeld van invloed: omgeving, gebruiker, testscenario en product (Zie hoofdstuk 1.4 “validiteit”).
Het prototype heeft als doel de metrics van het testen vast te leggen, zonder al te veel ongewilde afleiding te genereren. Dit houdt in dat bij de opbouw en bij de werking hiermee rekening wordt gehouden. Het is van belang voor de proefpersoon om de flow zo optimaal mogelijk te houden. Dit wil zeggen dat het
Vereisten Concrete functie
Nieuwe test creëren met meerdere doelen Test toevoegen
De test voortijdig afbreken mocht dit nodig zijn Secundaire bediening met afbreek Het opslaan van data uit tests Verzamelde data automatisch opslaan Het kunnen terug zien van verzamelde data Resultaten weergeven
Het kunnen terug luisteren van de verzamelde data Audio playback bij testresultaten
Vereiste Concrete functie
Het ontvangen van uitleg over de test Test introductie Het ontvangen van een nieuw doel Test begeleiding Op de hoogte zijn van voortgang Notificatie tekst Het kunnen terugluisteren van een doel Herhaling van doel
Een doel afronden Bedieningsmogelijkheden voor het afronden van doel
prototype tussendoor niet het contact met de app waarop getest wordt onderbroken mag worden. Het afwisselen van de gebruikscontext zou de testpersoon als verwarrend kunnen ervaren. Iets wat ongewilde afleiding genereert en dat proberen we juist te voorkomen.
Dit bovenstaande geeft een duidelijke richting voor het antwoord op de onderzoeksvraag In hoeverre mag het prototype zichtbaar zijn voor de proefpersoon? Er moet een nuance gezocht worden tussen bediening en afleiding, zonder de flow te onderbreken die de proefpersoon heeft met het testsubject. Dit vormt een uitdaging voor het ontwerp, waarbij diverse technieken overwogen moeten worden om dit te bewerkstelligen. Het onderzoek dat hiervoor is gedaan is opgenomen in de bijlagen van dit document (Zie bijlagen: “Interface en afleiding”).
2.3 – Meetpunten
Het hoofddoeleind van het prototype is het vastleggen van metrics uit de gebruikerstest. Zoals we in hoofdstuk 1 (metrics) al hebben gezien zijn er veel meetpunten die ieder een apart inzicht verschaffen. Het zou geweldig, maar onrealistisch zijn om te denken dat alle meetpunten in het prototype verwerkt kunnen worden. Daar is de tijdruimte van het project gewoon te kort voor. Door verdere afbakening wordt er echter meer focus in het project verkregen. Het design team was wederom zeer behulpzaam in dit proces. De lijst met verschillende meetpunten en wat zij opleveren was het uitgangspunt voor de afbakening. Deze lijst werd middels de MoSCoW methoden ingedeeld. Nadat Noor en Michiel de verdeling hadden gemaakt ontstond kleine discussie over de verschillen. Er werd nog wat geschoven totdat de volgende lijst ontstond:
Ondanks de kleine discussie was nu beredenering voor de keuze van de meetpunten vrijwel op dezelfde basis gegrond. Namelijk het creëren van een totaalbeeld voor het volbrengen van een taak. Dit lukt geheel met de drie “must have’s”. De “should have” was het punt van onenigheid, Michiel vond deze thuis horen in de won’t have lijst omdat hij er weinig waarde in zag. Noor had daar een andere mening over, zij vond het Juist een “must have”. Ze was er van overtuigd dat het denkproces van de proefpersoon waardevolle extra inzichten oplevert, vooral wanneer iets fout is.
Voor de “could have’s” geldt dat ze wel nieuwe inzichten geven, maar dat daar enigszins overlap plaats vindt met de andere meetpunten. De “won’t have’s” zijn op andere gronden afgevallen. Eye tracking is te ambitieus, dat zou een op zichzelf staand project kunnen zijn. Hier zou in theorie de front facing camera van een smartphone voor kunnen worden gebruikt. Waar het complex wordt is de berekening die dient te worden gemaakt. Hier is de afstand van de camera naar het oog en de kijkhoek naar het scherm van belang. Daarbij is de bijkomende factor dat er voor het Android platform geen bestaande libraries zijn waarmee dit zou kunnen worden gedaan. Dit betekent dat alles vanaf de grond moet worden opgebouwd en dat past niet meer binnen de projectduur. Bodylanguage is om een iets praktischere reden afgevallen. Hiervoor is een uitwendige observator nodig, zoals een camcorder op statief of een persoon die deze taak vervult. Even werd gedacht deze opdracht aan de testbegeleider mee te geven. Dit is op zich een goed idee, maar past niet goed bij de focus die we hebben voor dit project. De kennis die gemoeid gaat met de observatie en interpretatie van menselijke trekken is een studie op zich. Als we er blindelings van uitgaan dat iedereen dit kan, komt dat de validiteit van de onderzoek data niet ten goede.
2.3.1 – Task timing
Bij task timing wordt bijgehouden hoe lang de proefpersoon doet over het volbrengen van een gegeven taak. Vanuit een gehele sessie kan de gemiddelde tijd per proefpersoon en per taak worden berekend. Mogelijk is om dit af te zetten tegen een voorspelling. Alle tijden die hierboven of onder uitvallen zijn interessant voor verdere analyse van andere metrics.
Must have Should have Could have Won’t have
Task Timing Task Review Success rate
Thinking aloud Click tracking
Number of errors Eye tracking Bodylanguage
2.3.2 – Succes rate
De success rate geeft inzichten over de taakvolbrenging van de proefpersoon. Als een proefpersoon niet in staat is een taak te volbrengen, is er duidelijk iets gaande. Dit geeft aanleiding om de overige metrics te analyseren.
2.3.3 – Task review + Thinking Aloud
Task review stelt de proefpersoon in de gelegenheid zijn mening te geven over de zojuist volbrachte taak. Zaken als complexiteit, algehele ervaring (ergernissen / onduidelijkheden) en taak specifieke gedachten kunnen hier belangrijke inzichten verschaffen.
Thinking aloud geeft inzichten in de gedachtegang van de proefpersoon. Nielisen benoemde al in 199312 dat dit de nummer één usability tool is, omdat het zoveel waardevolle infomatie oplevert. Door hardop te denken tijdens elke stap en redenatie kan er worden nagegaan wat voor problemen een proefpersoon ondervindt. Ook kan aan de stem worden opgemaakt of een proefpersoon boos of geïrriteerd raakt. Dit moet te allen tijde worden voorkomen omdat het ten eerste niet goed is voor de relatie met de proefpersoon, ten tweede de testresultaten niet ten goede komt. Hardop denken is niet voor iedereen makkelijk uitvoerbaar. Uit een klein opgezette gebruikerstest (Zie bijlagen: “Hallway testing experiment: Thinking aloud”) bleek dat de meeste mensen zelf na een eerste instructie vooraf hardop denken door de gehele test heen. Er zijn enkele invloeden die de proefpersonen tijdelijk of langdurig weerhoudt van het hardop denken. Afleiding van buiten: bijvoorbeeld geluiden zorgen voor een tijdelijke afleiding. Een tweede is de gemoedstoestand van de testpersoon. Als deze zich niet op z’n gemak voelt dan is het vrijwel onmogelijk hardop te denken. Het is dus van belang dat de proefpersoon zich op zijn gemak voelt. De testbegeleider zou dit in de gaten moeten houden en ingrijpen indien nodig.
Er rust hier een interessante mogelijkheid om task review met thinking aloud te combineren. Door de proefpersoon vooraf te instrueren hardop te denken en door bij het volbrengen van een taak zijn ervaring uit te spreken kan dit worden gerealiseerd. Hoe dit echter in een werkelijke testsetting gaat uitpakken moet nog worden beoordeeld. Door hiermee in het prototype te gaan testen kan hier op een later tijdstip een evaluatie over worden gegeven.
2.4 – Conclusie
In dit hoofdstuk zijn we tot de invulling van het programma van eisen gekomen. Het vaststellen van de doelgroep stelde ons in staat een antwoord te geven op deelvraag 4.1: Welke behoefte heeft de gebruiker? De twee groepen hebben ieder hun eigen behoeften en deze verschillen veel van elkaar. Doelgroep 1: Testbegeleider heeft behoeften rond het voorbereiden van gebruikersonderzoeken en het terugzien van verzamelde testdata. Doelgroep 2: Proefpersoon heeft behoeften rond het ontvangen van uitleg en het uitvoeren van de doelen. Dit is ook waar een grote uitdaging rust voor dit project. Het antwoord op deelvraag 4.2: In hoeverre mag het prototype zichtbaar zijn voor de proefpersoon? gaf deze uitdaging inzichten in de aanpak. Afleiding door het breken van de context van het testonderwerp en andere vormen van afleiding is iets wat we moeten mijden. In het design moet een nuance worden gevonden tussen bediening en afleiding. Hoe er data bij het testen wordt vastgelegd is vastgesteld met het beantwoorden van deelvraag 4: Waar moet het prototype Android app aan voldoen om testdata tijdens het testen vast te
leggen? Hieruit is een lijst met vier meetpunten gevormd: task timing, success rate, task review en thinking
aloud. De meetpunten creëren samen een geheel beeld van de gebruiker bij het uitvoeren van taken wat inzicht moet genereren in de gebruikerservaring.
3 – Concretisering
De volgende stap in het proces is de Concretisering. Op basis van de onderzoeksresultaten die in de eerdere hoofdstukken staan beschreven zal er nu een vertaalslag worden gemaakt naar vorm en functie. Belangrijk
12 Jacob Nielsen, Thinking Aloud: The #1 Usability Tool - http://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/
18
is dat de verschillen tussen de twee doelgroepen goed in acht worden genomen en hun wensen centraal staan bij de keuzes die gemaakt worden.
3.1 – Applicatieflow
De flow waarin de applicatie wordt gebruikt was al eerder omschreven in het gebruiksscenario (Zie “2.1 - Doelgroep”). De analyse van het scenario geeft een aantal gebruiksmogelijkheden en interactiemogelijkheden weer die goed te vertalen zijn naar schermen. Deze schermen kunnen vervolgens weer in serie gezet worden en vormen zo een flowchart voor het prototype (zie bijlage “Flowchart”). De flowchart bevat drie paden die vanuit de hoofdpagina bereikbaar zijn. Deze paden zijn gelijk aan de drie gebruiksfasen die we eerder al omschreven:
• Test toevoegen - gebruiksfase: voorbereiden • Test uitvoeren - gebruiksfase: uitvoerend
• Testgegevens terugzien - gebruiksfase: analyserend
3.3 – Wireframes
Deze drie paden zijn ook aangehouden bij het opbouwen van de wireframes. Hierbij stonden de eisen van de doelgroep centraal (zie hoofdstuk 2 “Het program van eisen”). Het toegepaste designproces draait rond schetsen en experimenteren, waarbij er diverse iteraties zijn gemaakt op basis van nieuwe voortgangen in het onderzoeksproces.
3.3.1 – Test toevoegen
Het hoofddoel is het toevoegen van een nieuwe test voor een project. Wat hier van belang was dat er vrijheid is in het opzetten van een test. Natuurlijk dient de testbegeleider zich wel aan de validatie regels te houden (zie hoofdstuk 1.4 “Validiteit”), wat betekent dat de test een realistisch gebruiksscenario moet voorstellen. Het aantal doelen is vrij, omdat een test in omvang kan verschillen.
In scherm drie is ervoor gekozen om een luisterknop toe te voegen aan het doel. Dit heeft betrekking op de begeleidende stem die wordt gebruikt. Deze stem vertaalt tekst naar spraak. In uitzonderlijke gevallen gaat dit wel eens mis. Het kunnen terugluisteren is hier daarom toegevoegd om vooraf te weten hoe de tekst klinkt, om verwarring bij de proefpersoon tijdens een testsessie te voorkomen.
1. Nieuwe test 2. Doel toevoegen 3. Test met doel
3.3.2 – Test uitvoeren
Het uitvoeren van een test is onderdeel van de uitvoeringsfase, dit betreft de doelgroep proefpersoon.
De test introductie is het eerste contactmoment tussen het prototype en de proefpersoon. De uitleg vormt de basis voor de test. Het ontwerp voor de manier waarop de proefpersoon de introductie voorgeschoteld krijgt is meerdere malen aangepast. Waar er eerst keuze lag op een uitgebreide tekstuele uitleg, is er uiteindelijk gekozen voor een andere weg. De uitleg wordt door een stem voorgelezen, waarbij de proefpersoon kan mee lezen op het scherm. Redenen hiervoor zijn dat een lap tekst mogelijkerwijze wordt overgeslagen, daarnaast vindt ook op dit moment de eerste kennismaking met de computerstem plaats. Dit zou anders pas bij de start van de test gebeuren, wat mogelijk in een korte periode van gewenning had geresulteerd. Dit vindt nu al eerder plaats en zal daardoor de testresultaten niet beïnvloeden.
Na de introductie volgt de roluitleg. Dit scherm bevat meer tekst die niet wordt voorgelezen. Hiervoor is gekozen omdat dit de rol is waar vanuit de proefpersoon de doelen moet gaan uitvoeren. Dit moet ieder op z’n eigen leessnelheid kunnen doornemen. Vanuit hier kan de testsessie worden gestart.
Het ontwerpen van de bediening buiten de context van het prototype is door vele iteraties uiteindelijk tot deze vorm gekomen. Vele overwegingen zijn in dit proces gemaakt waarbij functie tegenover afleiding is afgewogen. Er is uiteindelijk voor deze vorm gekozen omdat het een elegante oplossing biedt, maar toch duidelijk is. De bedieningsknoppen zijn hier slechts zichtbaar wanneer ze nodig zijn. De gehele knop kan over de rechter verticale as van het scherm worden bewogen, om enige blokkade van het onderliggende scherm te voorkomen.
1. Testintroductie 2. Rol uitleg 3. Gedurende test
4. Sessie actief 5. Test gestart 6. Testbediening keuze
De notificatie vormt een extra bedieningsmogelijkheid tijdens het testen. Het heeft voornamelijk als doel dat de testbegeleider de sessie voortijdig kan afbreken indien noodzakelijk. Het stoppen van de sessie zit tamelijk verborgen, omdat voorkomen moet worden dat de proefpersoon de sessie voortijdig afbreekt.
Als de testsessie is voltooid wordt de test afgerond binnen het prototype. Hier is dan ook nog een mogelijkheid om de test te voorzien van aanvullende informatie die kan worden gebruikt bij het valideren van de sessie.
3.3.3 – Testgegevens terugzien
De staat van een test en de verzamelde testgegevens dienen voor de testbegeleider inzichtelijk weergegeven te worden. Hiervoor is getracht veel van de testdata in de interface te verwerken zodat alle belangrijke punten in een oogopslag duidelijk worden. Dit wordt voornamelijk bereikt door het gebruik van iconen en afbeeldingen in plaats van tekst.
3.4 – Vormgeving en stijl
De keuze voor de stijl en vormgeving voor dit project was uitermate makkelijk. Het prototype heeft een duidelijk doel, wat niet ligt bij de communicatie van stijl. Hiervoor was een vrij logische stap de Android design guidelines zo veel mogelijk op te volgen.
3.4.1 – Kleurgebruik
Het kleurgebruik in het design van het prototype volgt de Android stijl. Gekozen is voor een licht thema met donkere tekst en blauwe highlights. De donkere tekst met een lichte achtergrond maakt de tekst goed leesbaar. Waar kleur in de interface wordt gebruikt, valt dat ook extra op.
7. Bedieningsnotificatie 8. Afronding test 9. Aanvullende info
1. Projectoverzicht 2. Testresultaten
Dit helpt om de informatie die belangrijk is in de interface, ook goed op te laten vallen. Deze specifieke kleur blauw is standaard focuskleur die bij Android 4.4 Kitkat wordt gebruikt.
3.4.2 – Lettertype
Het standaard lettertype voor Android apps is het lettertype Roboto en heeft veel weg van Helvetica13. Er zijn diverse stijlen van het font beschikbaar zoals het voorbeeld toont14. De keuze is gegaan naar de light variant. In het design paste deze letterdikte het beste en maakt dat de layout schoon en strak oogt. Waar regular net op de grens zat, was alles dat dikker was al lastig te lezen. Thin maakte het vrijwel onleesbaar op kleinere afmetingen.
3.4.3 – Vormgeving
Voor de vormgeving van de diverse schermen in het prototype is gebruik gemaakt van de card ui pattern. Deze pattern is door Google in de Now applicatie geïntroduceerd als een manier om verschillende soorten data uniform te kunnen presenteren. De card ui pattern is inmiddels in veel van Google’s producten zoals Gmail, G+ en Youtube geïntroduceerd15. De card ui pattern bleek een goede keuze voor het opzetten van de diverse schermen. De stijl van opzet maakt dat het een saamhorig geheel is, maar toch kan elke soort data er op z’n eigen wijze in worden getoond. In de interface zijn verschillende iconen gebruikt. De iconen geven de
uitkomst van een actie weer. Bij een knop betekent dit dat er wat gaat gebeuren, zoals het afspelen van audio of het starten van een test. De iconen worden consistent op dezelfde manier door de gehele applicatie heen toegepast.
3.5 – Ontwerp
Het samenvoegen van stijlkeuze met de wireframes heeft geresulteerd in de schermontwerpen voor het prototype. Deze ontwerpen zijn opgenomen in de bijlagen (zie bijlagen “Schermontwerpen”). Dit hoofdstuk gaat dieper in op de gemaakte keuzen in de diverse onderdelen die voorkomen in het prototype.
3.5.1 – Test introductie
De introductie is het startpunt voor de proefpersoon. Hier wordt er uitgelegd hoe er getest gaat worden, hoe alles werkt en wat er van de proefpersoon wordt verwacht. Dit is ook het moment waarop de eerste kennismaking met de begeleidende stem plaatsvindt.
De stem vertaalt tekst naar spraak, op een redelijk overtuigende manier. Echter moet er rekening worden gehouden dat een proefpersoon de stem niet fijn vindt. Dit komt doordat de computerstem zich in de Uncanny Valley begeeft. Om de proefpersoon zich wat meer op z’n gemak
te laten voelen is de introductie gevormd rond het idee dat de stem een personage is. De stem stelt zich voor als TEss, wat een afgeleide is van de Text-to-Speech engine die de stem genereert.
13 Overeenkomsten tussen Roboto en Helvetica - http://theunderstatement.com/post/11645166791/roboto-vs-helvetica 14 Achtergrond over Android Typography - http://developer.android.com/design/style/typography.html
15 De card ui pattern in Google’s producten - http://www.fastcodesign.com/1672605/how-google-unified-its-products-with-a-simple-index-card
De Roboto font family.
Google Now Kaart
22
Bij de ontwikkeling van het script voor de intro is er gekozen voor tone of voice met een komische noot. Dit om het spreekwoordelijke ijs te breken. Je op je gemak voelen is een belangrijke factor bij het uitvoeren van de taak hardop denken(zie bijlagen “Hallway testing experiment: Thinking aloud”) . Een komische noot kan veel doen om de spanning en mogelijke ergernis aan de computerstem weg te nemen. Het script is opgenomen in de bijlagen (Zie bijlage “Introductie script”).
3.5.2 – bedieningsmodule buiten de app
De bediening die buiten het prototype context plaatsvindt was een grote uitdaging. Zoals al eerder werd benoemd, stonden hier de verhoudingen afleiding en gebruiksgemak centraal bij het maken van de ontwerpkeuzes (zie hoofdstuk 2.2 “Afleidingsfactor”).
De knop is na het beginnen van de test zichtbaar als toplaag binnen de interface van Android. De knop is verankerd aan de rechterkant van het scherm en kan over de verticale as worden versleept. De knop houdt zich aan de schermranden zodat het onmogelijk buiten het beeld kan worden gesleept. Dit gedrag werd boven een vrij verplaatsbare knop verkozen, omdat dit veel meer duidelijkheid communiceert. De werking van de knop is opgedeeld button states:
1. Start test 2. Actieve test 3. Bediening
Elke state heeft een ander doel en ook een ander uiterlijk die het doel communiceert naar de gebruiker. Kleurcodering is hier toegepast om de communicatie kracht bij te zetten.
Start test
Als de test wordt gestart verplaatst het prototype zich naar de achtergrond van het systeem. Vanaf dit moment is de test bedieningsmodule zichtbaar. De test is echter nog niet gestart, dit gebeurt pas als er op de startknop wordt gedrukt. De play icoon geeft dit aan, samen met de groene kleur die een positieve boodschap communiceert.
Actieve test
Als de proefpersoon de knop heeft ingedrukt wordt door de begeleidende stem de taak eerste doel uitgelegd. Op dit moment is de knop grijs. Deze kleur is gekozen omdat het neutraal is. Het icoon geeft aan dat er een actie aan verbonden is in die richting
Bediening
De drie ronde knoppen worden pas zichtbaar als er op de grijze knop is gedrukt. Dit is gedaan om de afleiding tijdens het volbrengen van de taak zo gering mogelijk te maken. De drie knoppen hebben allen een eigen functie: Het positief afronden van een taak middels een checkmark icoon, een kruis icoon om een negatieve afronding van een taak aan te geven, en een oortje om de omschrijving nogmaals te horen. Hierbij wordt ook gebruik gemaakt van kleurcodering om een duidelijke boodschap te communiceren. Waarbij groen en rood staan voor positief en negatief, en blauw voor beluisteren. Zodra een van de knoppen is ingedrukt verandert de knop weer in de state van de actieve test.
3.5.3 – Ondersteunende notificatie
Tijdens een lopende testsessie is er een notificatie actief die verschillende
ondersteunende functies uitvoert. In de normale gang van zaken wordt de notificatie gebruikt om de voortgang van de test te tonen, voor de proefpersoon is dit zichtbaar als een tekst in de notificatiebalk.
Verticale beweging
Vanaf links: Start test, Actieve test, Bediening
Tikkertekst
