Test & Feedback applicatie
Onderzoek naar testmethodes en het verzamelen van
feedback binnen Studio Stomp
Voor u ligt mijn afstudeerrapport “Test & Feedback tool”. Een onderzoek naar het huidige testproces van Studio Stomp en het testen van websites. Dit eindrapport is opgesteld in het kader van mijn afstuderen binnen de opleiding Communication en Multimedia Design aan de HVA.
Dit onderzoek is tot stand gekomen in
samenwerking met Studio Stomp, het bedrijf waar ik nu 1,5 jaar werk en stage heb gelopen. Toen ik bij Studio Stomp binnenkwam
teste ik de producten die ik maakte niet tot zelden. Dit is in een jaar tijd omgeslagen van het niet testen naar het schrijven van een onderzoeksrapport over testen en het maken van een feedback en test applicatie.
Graag wil ik iedereen bij Studio Stomp bedanken voor de tijd die zij in mij hebben gestoken om mij te helpen met het tot stand komen van dit rapport en mijn eindproduct. Verder gaat mijn dank uit naar Avinash Changa van DSRPT, Dennis Maij van We Are Bold en Bas van Bokhorst van GreenBerry die mij enorm hebben geholpen met interviews,
testen en hun professionele input. Als laatst, maar zeker niet als minst, gaat mijn dank uit aan mijn eerste lezer Robert van Boeschoten en tweede lezer Charlie Mulholland van de HVA, die mij altijd weer op het juiste spoor kregen als ik was afgedwaald.
Tim Goosens
Wormer, 1 juni 2014
Dit onderzoeksrapport is opgesteld met als doel het huidige test- en feedbackproces van Studio Stomp te optimaliseren door middel van een online applicatie. Studio Stomp zou graag een applicatie hebben waarin zij een website kunnen testen en waar de klant feedback achter kan laten.
Probleem
Studio Stomp is een bedrijf dat gespecialiseerd is in het ontwikkelen van business-to- consumer websites en applicaties. Zij werken samen met
reclamebureaus als Eigen Fabrikaat, Fitzroy en Rapp. Om hoogwaardige kwalitatief goede websites in de markt te zetten dient er uitvoerig getest te worden. Het huidige test- en feedbackproces is verre van ideaal. Studio Stomp omschrijft het huidige proces als onvolledig, tijdrovend en foutgevoelig.
Onderzoek
Om meer inzicht te krijgen in het huidige proces en waar de knelpunten liggen, zijn er interviews gehouden met medewerkers van Studio Stomp en de klant. Er is onderzoek
gedaan naar verschillende testmethodes en daaruit is gebleken dat een website op twee manieren getest dient te worden. Aan de hand van mijn onderzoek zijn er eerste schetsen gemaakt voor de applicatie en is er een paper prototype uitgevoerd met medewerkers van Studio Stomp.
Applicatie
Op basis van de paper prototype zijn er wireflows en ontwerpen gemaakt. De
ontwerpen zijn omgebouwd tot een werkend prototype waarin alle functies die vooraf waren opgesteld inzitten. Na het bouwen van de applicatie zijn er tests uitgevoerd met Studio Stomp en haar klanten.
Advies
Uit deze tests zijn enkele punten naar boven gekomen die de applicatie verbeteren, maar waar onvoldoende tijd voor beschikbaar was om te verwerken in de eerste versie van de applicatie. De huidige applicatie dient als proof of concept, maar met een paar verbeteringen en een toevoeging van een backend systeem heeft de applicatie de
potentie om het test- en feedbackproces van Studio Stomp drastisch te verbeteren.
Conclusie
De applicatie ondersteunt zowel functionele tests, aan de hand van een checklist,
en een usability test door middel van user scenario’s. Door slim in te spelen met de nieuwste technieken is het mogelijk om binnen de applicatie een website te bekijken en daar feedback op te geven met behulp van screenshots en browser gegevens.
Zo is het voor Studio Stomp meteen duidelijk waar het probleem zich voordoet.
De klant hoeft op zijn beurt niet meer zelf achter de browser gegevens aan en kan altijd terughalen wat er met zijn feedback is gedaan. Alle functionaliteiten binnen de applicatie zorgen ervoor dat het test- en feedback proces binnen Studio Stomp sneller, eenvoudiger en overzichtelijker verloopt.
Inhoudsopgaven
Inleiding 7
1.1 Studio Stomp 7 1.2 Probleemstelling 7 1.3 Onderzoeksvraag 8 1.4 Deelvragen 8 1.5 Indeling rapport 8 1.6 Begrippenlijst 9Probleemsituatie 10
2.1 Onvolledig 10 2.2 Tijdrovend 10 2.3 Chaotisch 10 2.4 Doelstelling 11 2.5 Oplevering 11De doelgroep
13
3.1 Testsituatie Studio Stomp 13
3.2 Testplan 13
3.3 Hoe test de klant 14
3.4 Knelpunten 14 3.5 Conclusie 15
Testmethodes 16
4.1 Usability testing 16 4.2 User scenario’s 17 4.3 Functioneel testen 19 4.4 A/B testing 20 4.5 Prototyping 21 4.6 Conclusie 22Concurentie analyse
23
5.1 Cage App 23 5.2 Track Duck 24 5.3 Launchlist 25 5.4 UserTesting 26 5.5 Conclusie 27Waarom testen?
28
6.1 Waarom testen belangrijk
is volgens Steve Krug 28
6.2 Waarom test
Studio Stomp? 29
6.3 Het belang van de
klant en gebruikers 29 6.4 Conclusie 30
Functionele eisen
32
7.1 Projecten 32 7.2 Feedback 32 7.3 Tests 32 7.4 Agenda 32 7.5 Randvoorwaarden 33Schetsen 34
8.1 Inspiratie 34 8.2 Eerste schetsen 35 8.3 Gedetailleerde schetsen 35 8.4 Paper prototype 36 8.5 Conclusie 37Interactie ontwerp
38
9.1 Wireflow 38Functionele prototype
39
10.1 Stappen 39 10.2 Prototype 39 10.3 Conclusie 40Ontwerp 41
11.1 Dashboard 41 11.2 Project pagina 4211.3 Project detail pagina 42
11.4 Bekijk project 42
11.5 Feedback van het project 43
11.6 Test overzicht pagina 43
11.7 Checklist test 43
11.8 User scenario test 44
11.9 Test uitslag 44 11.10 Agenda 45
De applicatie
46
12.1 Tools 46 12.2 Bouwproces 46 12.3 Testresultaten 46Conclusie 49
Advies 51
14.1 Backend 51 14.2 Features 51Tot slot
53
Bronnenlijst 54
A. Interviews
57
Interview Michel Stomp
en Jelleke Raats 57
Interview Michel Stomp 59
Interview Avinash Changa
(DSRPT, We Make VR) 61
Interview Dennis Maij
(We Are Bold) 65
Interview Bas van Brokhorst
(GreenBerry) 67
B. Testresultaten
70
Paper prototype
testresultaten 70
Testresultaten Studio Stomp 70
Testresultaten Avinash Changa
(DSRPT, We Make VR) 70
Testresultaten Dennis Maij
(We Are Bold) 71
C. Testplan
72
D. Wireflow
76
Hoofdstuk 1 - Inleiding
Hoofdstuk 2 - Probleemsituatie
Mijn afstudeeropdracht is in samenwerking gemaakt met Studio Stomp. De doelstelling van het rapport en product is om het huidige testproces van Studio Stomp te optimaliseren.
1.1 Studio Stomp
Studio Stomp is een bedrijf dat
gespecialiseerd is in het ontwikkelen van business-to-consumer webapplicaties. Zij werken samen met reclamebureaus als Eigen Fabrikaat, Fitzroy en Rapp. Ze leveren professionele webapplicaties die bijdragen aan sterke cross mediale campagnes. Studio Stomp is gelegen in Amsterdam aan de Willem de Zwijgerlaan. Opgericht in 2008, door Michel Stomp en Benjamin de Wit, was Studio Stomp van origine een Flash development bureau. Al snel ontdekte Studio Stomp dat Flash werd ingehaald door HTML 5 en CSS 3 en hebben zij Flash development laten vallen. Studio Stomp was één van de eerste webdevelopment bureau’s in Nederland die zich volledig richtte op responsive webdesign. Op dit moment werken er ongeveer tien man bij Studio Stomp.
1.2 Probleemstelling
Bij Studio Stomp kijken ze altijd hoe ze zichzelf kunnen verbeteren en hun marktpositie kunnen versterken. Studio Stomp beschouwt de samenwerking tussen de klant als één van de belangrijkste aspecten van het proces. Echter is dit een
tijdrovende en uitdagende klus. Er komt veel e-mail en belverkeer bij kijken. Op dit
moment heeft Studio Stomp geen centrale plek waar klanten hun feedback kunnen afgeven en testresultaten kunnen delen. Bij Studio Stomp wordt er voornamelijk
functioneel getest. Ook de klant test in het huidige proces alleen functioneel. Studio Stomp omschrijft het huidige testproces als onvolledig, tijdrovend en foutgevoelig.
1.3 Onderzoeksvraag
Aan de hand van de probleemstelling is de volgende onderzoeksvraag gedefinieerd:
Hoe kan een online
testtool bijdragen aan het
optimaliseren van het test- en
feedbackproces van Studio
Stomp zodat het voor Studio
Stomp en haar klanten
gemakkelijker wordt te testen
en feedback te leveren?
1.4 Deelvragen
Om tot een goed onderbouwd antwoord te komen op de onderzoeksvraag zijn de volgende deelvragen opgesteld:
• Welke onderdelen van het ontwikkelproces worden getest en feedback opgegeven?
(Zie hoofdstuk 3. Doelgroep)
• Waar zitten volgens de medewerkers van Studio Stomp de knelpunten bij het huidige test- en feedbackproces? (Zie hoofdstuk 3. Doelgroep)
• Welke testmethodes zijn er om een website of applicatie te testen voordat deze live gaat en welke methodes worden er in andere testtools gebruikt?
(Zie hoofdstuk 4. Testmethodes & 5. Concurrentie analyse)
• Wie heeft er baat bij het testen van een website of applicatie en welk belang hebben zij hierbij?
(Zie hoofdstuk 6. Waarom testen?)
• Wat draagt testen bij aan het gewenste resultaat van de klant? (Zie hoofdstuk 6. Waarom testen?)
• Aan welke eisen moet de testtool voldoen, zodat het voor Studio Stomp en haar klanten, gemakkelijk is feedback te leveren?
(Zie hoofdstuk 7. Functionele eisen)
1.5 Indeling rapport
Het rapport is in drie stukken verdeeld. Het eerste deel gaat over de probleem
situatie bij Studio Stomp (Hoofdstuk 1. Inleiding en hoofdstuk 2. Probleemsituatie). Het tweede deel zal uit het onderzoek bestaan welke een antwoord geeft op mijn
eerste vijf deelvragen (Hoofdstuk 3. Doelgroep, hoofdstuk 4. Testmethodes, hoofdstuk 5. Concurrentie analyse en hoofdstuk 6. Waarom testen?). Het laatste deel zal antwoord geven op deelvraag 6 en mijn onderzoeksvraag (Hoofdstuk 7. Functionele eisen, hoofdstuk 8. Schetsen, hoofdstuk 9. Interactie ontwerp, hoofdstuk 10. Ontwerp & hoofdstuk 11. De applicatie).
1.6 Begrippenlijst
Ter verduidelijking worden er hieronder enkele worden en afkortingen uitgelegd die terug komen in mijn rapport:
IXO: IXO is een afkorting die door Studio
Stomp wordt gebruikt voor interaction design.
Front-end: Voorkant van de applicatie, dit
is wat de gebruikers zien.
Back-end: Achterkant van de applicatie, dit
is waar Studio Stomp projecten en tests kan toevoegen aan de applicatie.
Iteratief proces: Een iteratief proces is een
proces waarbij onderdelen zich stelselmatig herhalen.
Scrum: Scrum is een ontwikkel methode
waar door middel van korte sprints en in teams, producten worden gemaakt.
OS: Afkorting voor operating system, ook
wel besturingssysteem genoemd. Dit kan Windows, Mac OSX of Linux zijn.
Elk product, of dit nou een website,
webapplicatie, mobiele app of een Facebook app is, moet bij Studio Stomp getest worden. Helaas is het huidige testproces van Studio Stomp niet optimaal en gaat er veel tijd verloren. Tijdens interviews met de creative director en project manager bij Studio Stomp zijn er drie knelpunten naar boven
gekomen van het huidige proces.
2.1 Onvolledig
Het huidige testproces is onvolledig. Er worden alleen functionele tests uitgevoerd en vaak worden de test uitgevoerd door de developers die ook aan het project hebben gewerkt. Developers die aan het project hebben gewerkt weten precies wat de website moet doen en waar alles staat. Zij kunnen geen valide gebruiksvriendelijkheid tests uitvoeren.
2.2 Tijdrovend
Studio Stomp werkt aan de hand van zogeheten testplannen. Deze testplannen worden door alle testgebruikers ingevuld en na het testen wordt er een meeting gehouden
om alle testresultaten door te nemen. Dit is een tijdrovende klus en een testcyclus kan hierdoor een halve tot hele dag duren. Dit is kostbare development tijd die veel beter gebruikt zou kunnen worden in het verbeteren van het product.
2.3 Chaotisch
Als Studio Stomp zijn producten laat testen door de klant kunnen de testresultaten op verschillende manieren terug worden gekoppeld. Sommige klanten sturen een e-mail met openstaande punten, andere sturen een Word document door en sommige geven alle resultaten door via de telefoon. Studio Stomp heeft op dit moment geen centraal systeem waar alle testresultaten worden verzameld. Hierdoor is het voor Studio Stomp ook moeilijk om testresultaten terug te halen en tests te baseren op
voorgaande tests.
De testcyclus kan een halve tot
hele dag duren.
2.4 Doelstelling
De doelstelling van mijn tool is om het test- en feedbackproces te optimaliseren.
Het moet mogelijk zijn om in de tool een project te bekijken, feedback te leveren en verschillende tests uit te voeren. Voor de klant moet het gemakkelijk zijn feedback achter te laten en overzichtelijk zijn wat er met de feedback wordt gedaan. Voor Studio Stomp moet het makkelijk zijn tests uit te voeren en het test- en feedbackproces minder tijd te laten kosten.
2.5 Oplevering
Ik zal een product opleveren waarvan alleen de voorkant werkt. Het product dient
als proof of concept en moet de belangrijkste functies bevatten (zie hoofdstuk 7). De
achterkant van de applicatie valt buiten de scope. Wel is de applicatie zo gebouwd dat het redelijk gemakkelijk is om een
achterkant te koppelen aan de voorkant. Er is een interaction design in de vorm van een wireflow gemaakt, design en een volledig werkend prototype.
Hoofdstuk 3 - De doelgroep
Hoofdstuk 4 - Testmethodes
Hoofdstuk 5 - Concurentie analyse
Hoofdstuk 6 - Waarom testen?
Het product kent twee doelgroepen. Studio Stomp, welke websites creëert en de klant waar Studio Stomp de websites voor maakt. Met beide doelgroepen zijn interviews gehouden om er zo achter te komen hoe er door beide doelgroepen worden getest en tegen welke problemen zij aanlopen tijdens het testen.
3.1 Testsituatie Studio Stomp
Studio Stomp werkt aan de hand van een iteratief proces met meerdere fases. Deze fases kunnen in verschillendesamenstellingen één project vormen. Een project kan bestaan uit één of meerdere fases. Studio Stomp kent de volgende fases:
• Inceptie: Concept ontwikkeling, briefing /
debriefing, vaststellen outer scope
• Functioneel ontwerp: Keuze medium,
vaststellen randvoorwaarden, inner scope
• Interactieontwerp: Persona’s, user stories, user
flow, interaction design, wireframes
• Visueel ontwerp: Grafisch ontwerp, UX design • Development: Technische realisatie van
product(en)
• Implementatie
Iedere fase wordt getest. Volgens de processen van Studio Stomp heeft iedere fase een aantal voorwaarden waaraan het deelproduct moet voldoen. Daarnaast worden uit iedere vorige fase de criteria gesteld voor de volgende fase. Hoe eerder in het proces een fout wordt gevonden, hoe minder fouten later kunnen worden teruggevonden.
3.2 Testplan
Studio Stomp test zijn producten door middel van testplannen. Deze testplannen worden opgesteld door de project manager. In een testplan wordt vooral de functionaliteit van de website of applicatie behandeld.
Het testplan is een Word document (Zie bijlage C) waar het voor de tester mogelijk is de vragen met ja of nee te beantwoorden en eventueel een opmerking te plaatsen. Denk hierbij aan vragen als “Linkt het logo terug naar de homepage?”, “Werkt het formulier?” en “Is de navigatie responsive?”.
Alle testers krijgen een testplan. Na het invullen van dit testplan levert de tester het testplan weer in bij de project manager.
Deze bundelt alle testresultaten en neemt deze door. Als alle testplannen zijn verzameld volgt er een zogeheten testresultaten
bespreking. In deze bespreking worden alle resultaten door genomen en behandeld. Zo wordt er in dit gesprek gefilterd wat echte problemen zijn en wat voor prioriteit
deze hebben. Na deze bespreking verwerkt de projectmanager alle problemen in Redmine (issue tracking systeem).
3.3 Hoe test de klant
Elke klant test op zijn eigen manier.Afhankelijk van het product wordt er getest op de verschillende browsers en diveces. De producten die Studio Stomp opleveren worden door de klant functioneel getest en de designs worden nagekeken, om zo te bepalen of alles op de juiste plek staat.
Het noteren van de openstaande punten en issues is ook verschillend. De meeste klanten noteren het in een Excel sheet en sommigen noteren het in een project management tool zoals Basecamp.
Vaak is de klant van Studio Stomp niet de eindklant van het project. In dat geval wordt het product ook nog doorgestuurd naar de
eindklant voor goedkeuring. Als de klant en eventuele eindklant klaar is met testen wordt de lijst met openstaande punten doorgestuurd naar Studio Stomp. Dit wordt op verschillende manieren gedaan.
Meestal via e-mail, maar kan ook via een telefoongesprek of face-to-face contact.
3.4 Knelpunten
De manier van testen binnen Studio Stomp is een tijdrovende klus. Op dit moment zijn er teveel tussenstappen in het testproces. Hierdoor kan het testen een halve tot hele dag duren. Studio Stomp geeft aan dat ze hierdoor te weinig tijd en budget hebben om uitvoerige tests te doen voor elk product. Studio Stomp geeft tevens aan dat het huidige testproces onvolledig is. Er wordt weinig tot geen usabillity tests uitgevoerd en Studio Stomp zou graag willen zien dat functionele tests aan het begin van het project worden opgesteld, om zo tijdens het project de test meerdere malen te kunnen uitvoeren.
Doordat het verzamelen van feedback van de klant via verschillende kanalen gaat, raakt Studio Stomp snel het overzicht kwijt. Er is op dit moment geen centrale plek waar alle feedback verzameld en gearchiveerd kan worden. Studio Stomp vind het lastig te achterhalen wat de vorige resultaten waren en wat hiermee gedaan is. Hierdoor zijn op dit moment de tests doorgaans niet gebaseerd op input en resultaten uit voorgaande fases. Klanten van Studio Stomp geven aan dat het lastig is om goede feedback terug te krijgen van eindklanten als zij als tussenpersoon werken. De eindklanten beschikken vaak niet over de technische kennis om op de juiste manier feedback terug te koppelen. De feedback bestaat dan meestal uit punten als “Het werkt niet” en “Ik kan geen tekst copy/ pasten”. Ook is het moeilijk te achterhalen op welke browser, device en context dit probleem zich dan voordoet.
3.5 Conclusie
Uit de interviews is naar voren gekomen dat de huidige testsituatie niet ideaal is.
De manier van testen is tijdrovend en het verkrijgen van feedback van de klant is te divers. Ook het verkrijgen van de juiste gegevens (zoals browser en browser versie)
waar bepaalde problemen zich voordoen is lastig te achterhalen.
Er zijn verschillende test methodes om een website te testen. Elke methode kan
worden ingezet in één of meerdere fases van een project. In dit hoofdstuk staat een
overzicht van de meest voorkomende methodes, hoe je deze moet inzetten en wanneer deze ingezet dient te worden.
4.1 Usability testing
Usability testing is een vorm van testen dat gebruikt maakt van het observeren
van een persoon die een website of applicatie gebruikt en richt zich op de gebruiksvriendelijkheid van deze website of applicatie. Steve Krug legt in zijn boek “Rocket Surgery Made Easy” in één zin uit wat usability testing inhoud. Vrij vertaald komt dit neer op:
“Bekijken hoe mensen
uitproberen wat jij aan het
maken/ontwerpen/bouwen
bent, met de intentie om (a)
het makkelijker te maken voor
de mensen die het gebruiken
of (b) te bewijzen dat het
makkelijk in gebruik is.”
(Krug 13)
Het idee achter usability testing is er achter komen wat een gebruiker denkt en doet bij het gebruiken van een website, om zo er achter te komen of de website logisch en simpel in gebruik is.
Steve Krug geeft verder aan dat een usability test de volgende elementen bevat. Een testbegeleider, deze notuleert en begeleidt de test. Een testdeelnemer, degene die de website of applicate test. Een computer waar de website of applicatie op wordt getest. Een geluidsrecorder en een schermrecorder. (65) Tijdens het testen wordt er aan de
testdeelnemer gevraagd of hij een opdracht kan uitvoeren op de website, een zogeheten user scenario (zie hoofdstuk 4.2 User scenario’s). Er wordt gevraagd of de deelnemer alles wat hij denkt hardop te zeggen.
De testbegeleider notuleert alles wat er wordt gezegd en gebeurt en stuurt de test aan. Ondertussen wordt er zoveel mogelijk opgenomen. In de uitgebreidste vorm wordt zowel de audio, het scherm als het gezicht van de gebruiker opgenomen. Vaak wordt er achter de schermen door de developers mee gekeken met de test.
Usability testing kan in verschillende vormen worden ingezet. Zo heb je de professionele manier waar gebruik wordt gemaakt van een geoptimaliseerde computer waar het scherm en de gebruiker wordt opgenomen en een usability expert die de test begeleid. Het komt bij professionele usabilty tests ook voor dat de deelnemer alleen in een kamer zit en de begeleider achter een spiegelruit. De opdrachten worden dan via een microfoon aan de deelnemer verteld. Het probleem met professionele usability test is dat deze zeer prijzig zijn en het aanbod professionele usability tester laag is. Steve Krug geeft in zijn boek “Rocket Surgery Made Easy” aan dat er 10.000 usability professionals wereldwijd zijn waar maar een fractie van usability tests uitvoert. (7)
Een usability test kan echter ook uitgevoerd worden zonder een professional.
Het zogeheten doe-het-zelf usability
testing. Deze tests worden met een normale computer, schermrecorder en geluidsopname apparatuur uitgevoerd. De kosten voor dit soort test zijn vele malen lager dan de tests die door professionals worden uitgevoerd. Usability testing wordt gezien als
één van de betere testmethodes om gebruiksvriendelijkheid problemen op te lossen. Ongeacht de vorm en testdeelnemer worden er altijd problemen gevonden, die door de developers over het hoofd worden gezien, omdat ze te diep in het project zitten en er niet meer oprecht naar kunnen
kijken.
4.2 User scenario’s
User scenario’s zijn een belangrijk onderdeel van usability tests, maar kunnen ook
losstaand gebruikt worden. Een user scenario is een verhaal van een gebruiker wat
kan voorkomen op de website die getest wordt. Het wordt gebruikt om te kijken of het voor een potentiële gebruiker makkelijk is om een bepaalde handeling op de website te voltooien. Vaak worden user scenario’s verward met user stories en user cases.
Op Cloudforrest Design (http://www. cloudforrestdesign.com) leggen ze het verschil uit aan de hand van voorbeelden. Een user scenario is meestal een uitgebreid verhaal over de gebruiker, wat ze willen en wat ze al weten. Een user scenario wordt geschreven in een verhalende vorm. (Cloudforrest Design)
Voorbeeld:
John is een 30 jarige manager van een reclame bureau, metroseksueel en een bierliefhebber. Hij wil graag een nieuw soort bier uitproberen in een trendy locatie. Hij gebruikt ook graag verschillende sociale apps op zijn smartphone. Hij leest een review op Yelp over een nieuw burger & bier tent in de stad met meer dan 100 verschillende bier op de tap en beslist om na het werk er heen te lopen om te bekijken of het wat is.
(Cloudforrest Design)
Een user story is een verkorte versie van een user scenario en wordt gebruikt om de essentie van een gebruikersbehoefte te
definiëren. Vaak worden user stories gebruikt bij de Scrum methode en gedefinieerd aan het begin van een development sprint.
(Cloudforrest Design) Voorbeeld:
Een gebruiker moet een bar willen vinden en een biertje drinken.
(Cloudforrest Design)
Een use case beschrijft precies wat een gebruiker doet en wat het systeem teruggeeft. Het is een soort stappenplan met input van de gebruiker en mogelijke output, reacties
of fouten van het systeem. Vaak wordt een user case ingezet voor een gedetailleerde product eisen beschrijving. (Cloudforrest Design)
Voorbeeld:
• Klant loopt naar restaurant • Klant loopt restaurant binnen • Klant vindt een kruk bij de bar • Klant bestudeerd de kaart • Klant kiest een biertje • Klant besteld een biertje • Barman neemt orde aan • Barman tapt een biertje • Barman levert biertje af • Klant drinkt biertje
• Klant betaald voor het biertje
(Cloudforrest Design)
Zoals je kan lezen zit er wel degelijk een verschil tussen user scenario’s, user stories en user cases. Ze worden ook in verschillende situaties ingezet. User scenario’s zijn
uitermate handig om tijdens tests te
gebruiken. Via een user scenario betreed je in de belevingswereld van een gebruiker en kan
je uit hun oogpunt een website testen.
Hiermee test je de flow en gebruikersgemak van een website of applicatie.
De test- en feedback applicatie zal user scenario’s ondersteunen. Op dit moment is Studio Stomp aan het overstappen op de Scrum methode. Zodra dat voltooid is zal Studio Stomp tijdens de development fase ook user stories gaan gebruiken. User scenario’s zouden dan gebaseerd kunnen zijn op de user stories en vice versa.
4.3 Functioneel testen
Bij functioneel testen wordt er door de testpersonen gekeken of alles op een website werkt en goed staat. Deze test wordt meestal gedaan door personen die betrokken zijn bij het project en weten hoe alles moetwerken. Functioneel testen gebeurt meestal in een vorm van een checklist. In deze checklist staan alle punten waar naar gekeken worden en de punten kunnen beantwoord worden met JA of NEE. Bij Studio Stomp wordt er op dit moment gewerkt met een zogeheten testplan. In dit plan staan alle punten en is er ruimte om per punt een extra opmerking te plaatsen. Ook zijn er online alternatieve zoals Launchlist (http://www.launchlist.net/).
Bij functioneel testen wordt de
gebruiksvriendelijkheid van de website achterwegen gelaten. Het gaat er hier alleen om of alle functies werken zoals zij horen te werken. Als voorbeeld kunnen we een contactformulier nemen. Bij het invullen van het formulier kunnen er verschillende scenario’s voorkomen. Als alles goed gaat zou na het invullen van het formulier een bevestigingsbericht moeten worden getoond om zo de gebruiker te informeren dat het versturen van het formulier is gelukt. Het is echter mogelijk dat een veld van het formulier wordt vergeten of niet goed is ingevuld.
Hier moet de gebruiker dan een melding van krijgen. Dit wordt bij een functionele test gecontroleerd. Het verschil met functioneel testen en usability testen kun je als volgt omschrijven:
Functioneel testen kijkt of
iets werkt, terwijl usability
testing kijkt of iets makkelijk
in gebruik is.
Functioneel testen kan in verschillende stadia van het ontwikkelproces worden ingezet, maar wordt vaak aan het einde van een project gebruikt om zo de laatste bugs uit de
4.4 A/B testing
A/B testing is het vergelijken van twee ontwerpen, om er zo achter te komen welke versie het meest succesvol is om de doelen van een website te behalen. Dit kunnen kleine verschillen zijn als de kleur van een button tot een volledig andere layout. Meestal wordt A/B testing ingezet om een nieuw design te vergelijken met het oude design. Het kan echter ook gebruikt worden in de IXO en ontwerpfase, om zo twee
ontwerpvoorstellen uit te testen. In het eBook van Smashing Magazine “A Field Guide To Usability Testing” wordt er uitgelegd wat A/B testing in het kort inhoud.
Bij A/B testing heb je
twee ontwerpen voor een
website: A en B. Meestal is
A de bestaande website en
B het nieuwe ontwerp. Het
verkeer van de website wordt
verdeeld tussen deze twee
versies en er wordt gemeten
welke er beter presteert aan
de hand van eigenschappen
die jij belangrijk vindt
(conversie, verkoop,
weigeringspercentage, etc.).
Na de testperiode wordt de
versie gekozen welke het best
presteert.
(Chopra et al. 6)
Hoewel A/B testing op zichzelf vrij simpel in elkaar steekt moet er toch op bepaalde
dingen worden gelet bij het testen. In het zelfde boek van Smashing Magazine worden er enkele do’s en don’ts vermeld. Zo is het belangrijk dat beide versies tegelijk worden getest. Test niet eerst versie A en een week later versie B. Het kan zijn dat de ene week meer bezoekers komen dan de andere. Dit kan zorgen voor een vertekend beeld. (8) Verder is het van belang dat je de juiste tijdspan kiest voor je A/B test. Te vroeg stoppen kan betekenen dat je te weinig informatie vergaart voor een zinvol testuitslag. Als je te lang een A/B test
doorvoert met een slecht presterende variatie kan je conversie en verkoop mislopen. Voor het kiezen van de juiste tijd zijn er enkele online applicaties die dit voor je kunnen berekenen (http://visualwebsiteoptimizer. nl/ab-split-test-duration/). (9)
Een uitgebreide lijst van alle do’s en don’ts zijn te vinden in het boek op pagina 8 en 9.
4.5 Prototyping
Prototypes worden ingezet in het begin van een project en worden gebruikt om de
functionaliteiten en flows van een website of applicatie te testen. Een prototype kan verschillende vormen aannemen, maar zijn bijna altijd gebaseerd op wireframes.
In een wireframe worden de verschillende blokken en layout elementen in een kader neergezet. Ze bestaan meestal uit lijnen, blokken en grijstinten (Afb. 4.5.1).
Afb 4.5.1 - Wireframe van een Website. Chris Bannister via Dribbble
Het idee van een wireframe is om de layout en flow van een website te definiëren en wordt er nog niet gekeken naar de visuele stijl. Een prototype kan worden uitgevoerd
via papier of digitaal. Het is een verzameling van wireframes van verschillende pagina’s en functies en kan doorlopen worden.
Paper prototypes worden ingezet in het begin van de conceptfase, om zo snel verschillende ideeën te kunnen uitwerken. Tegenwoordig zijn er ook enkele apps die het mogelijk maken om paper prototypes op een smartphone of tablet uit te voeren.
Een voorbeeld is POP welke het mogelijk maakt foto’s te maken van je schetsen en aan elkaar te koppelen. Hierdoor kan de gebruiker op zijn mobiel de prototype doorlopen (Afb. 4.5.2).
Een andere vorm van prototyping zijn digitale prototypes. Dit zijn uitgewerkte wireframes en zijn niet zo ruw als de schetsen van een paper prototype. Deze prototypes zijn gemaakt in HTML en CSS en kunnen worden gebruikt in de webbrowser. Ze simuleren een echte website. Deze prototypes worden vaak aan het einde van de concept of IXO fase gemaakt, om zo de flow en functionaliteit van de website te demonstreren. Een digitale prototype kan gebruikt worden als bewijs dat de website werkt en is meestal de laatste fase voordat er een ontwerp wordt gemaakt.
Afb. 4.5.2 - POP App in actie. POP App
4.6 Conclusie
Elke testmethode test iets anders. Zo testen usability tests, user scenario’s en
protoypes de gebruiksvriendelijkheid van een website of applicatie. De functionele
tests worden uitgevoerd om er achter te komen of bepaalde functionaliteiten werken. Hier wordt niet gekeken of de manier waarop iets werkt het meest
gebruiksvriendelijkst is voor de gebruiker. A/B tests worden meestal ingezet na livegang, om er zo achter te komen of een nieuw design meer conversie oplevert.
Om een website goed te testen moet je zowel testen op gebruiksvriendelijkheid als
Er bevinden zich verschillende tools op de markt om websites en applicaties te testen. Elke tool heeft zijn eigen sterke en minder sterke punten. Per tool zal er een omschrijving worden gegeven en een lijst met sterke en minder sterke punten.Voor elke tool is er gekeken naar wat voor type test er kan worden gedaan, in welke fase van een project de tool kan worden gebruikt en de unieke functies van de tool.
5.1 Cage App
http://www.cageapp.com
Cage App is een collaboratie tool die zich richt op designers. Doormiddel van de online
applicatie kunnen designers hun ontwerp voorstellen uploaden en kunnen collega’s of klanten feedback en commentaar geven op het geüploade werk.
Cage biedt een aantal sterke functies aan voor de gebruiker. Zo is het mogelijk om
direct notities te maken en een kleine discussie te starten op een selectie van een design (Afb. 5.1.1). Ook biedt Cage de mogelijkheid aan om revisies bij te houden (Afb. 5.1.2). Dit houdt in dat het voor de
gebruiker, collega’s en klant duidelijk te zien is welke stappen er zijn genomen tijdens het proces. Zodra de klant tevreden is kan hij binnen de applicatie aangeven dat het design goedgekeurd is. Het project wordt dan
opgeslagen in het archief zodat alle
betrokkenen er later nog bij kunnen mocht dat nodig zijn.
Afb. 5.1.1 - Notitie en discussie op een selectie van het design binnen Cage
Afb 5.1.2 - Overzicht van revisies
Andere functionaliteiten binnen Cage zijn To-do lists, mogelijkheid om een team aan te maken en een optie om een presentatie van enkele designs aan te maken.
Pros:
• Notities en discussies op een selectie van een design
• Revisies
• Archivering van afgeronde projecten • Overzicht van lopende projecten
Cons:
• Alleen gericht op design
5.2 Track Duck
http://www.trackduck.com
Track Duck is een feedback applicatie die zich richt op de design en development fase
van een project. Designs kunnen net als bij Cage worden geüpload in de applicatie, waar de klant feedback op kan geven. Ook is het mogelijk om revisies te bewaren zodat de gebruiker een makkelijk overzicht krijgt van de genomen stappen en de voortgang van het project.
Naast design ondersteunt Track Duck ook live websites. Door een javascript bestand
toe te voegen aan de site wordt er een Track
Duck feedback functie toegevoegd. Met de functie kan de gebruiker een selectie maken van de sectie waar de gebruiker een probleem tegenkomt en feedback op wilt geven (Afb. 5.2.1). Dit werkt op dezelfde manier als bij Cage. Waar Cage alleen een screenshot maakt van de selectie, stuurt Track Duck ook de browser gegevens mee van de tester. Zo is het snel duidelijk op welk systeem en browser het probleem zich voordoet.
Afb. 5.2.1 - Gebruiker geeft feedback op een deel van de website
Binnen Track Duck is het mogelijk om aan gebruikers rollen te hangen. Dit loopt van reporter tot administrator. Hoe hoger je rol hoe meer functies er tot je beschikking komen binnen de applicatie.
Pros:
• Ook geschikt voor live websites • Revisies
• Gebruikers rollen
• Te integreren met de bekendere project management tool
Cons:
• Testen van live site vereist extra javascript bestand op de site, hierdoor bevindt zich niet alles in de applicatie zelf.
• Geen mogelijkheid om teams aan te maken.
5.3 Launchlist
http://www.launchlist.net
Launchlist is een applicatie die kan worden ingezet vlak voor live-gang van een
website of applicatie. De applicatie is een checklist in zijn puurste vorm. Door middel van de checklist kan de gebruiker bekijken of alles functioneel werkt. Dit houd in dat er wordt gekeken naar zaken als “Linkt het logo naar de homepage?”, “Werkt het contact formulier?”, “Bevinden er geen spelfouten in de tekst?” en “Zijn alle meta-data toegevoegd?” (Afb. 5.3.1).
Launchlist heeft enkele handige functies die het proces van de checklists aanmaken en uitvoeren versnellen. Zo is het mogelijk om
templates aan te maken. In deze templates kan er een aantal punten worden gedefinieerd die vaak terugkomen in verschillende
projecten (Afb. 5.3.2). Bijvoorbeeld de vraag “Zijn alle meta-data toegevoegd?”. Ook is het mogelijk om in teams tegelijk een checklist te doorlopen. Dit zorgt ervoor dat er snel en gemakkelijk een checklist kan worden uitgevoerd. Verder heeft Launchlist een overzichtelijk dashboard waar je al je projecten kan bekijken en kunt zien wat de status van het project is.
Afb. 5.3.2 - Overzich van aangemaakte templates per soort website
Pros:
• Makkelijk in gebruik • Templates aanmaken
• Met meerdere mensen tegelijk een checklist invullen
• Overzichtelijk
Cons:
• Sommige punten zouden automatisch door de applicatie gechecked kunnen worden.
• Alleen functionele tests
5.4 UserTesting
http://www.usertesting.com
UserTesting is anders dan de andere test applicaties die hier zijn beschreven. In plaats dat je zelf de tests uitvoert laat je de tests uitvoeren door andere mensen. Het idee
achter de applicatie is om jouw product, of het nou een website of Facebook app is, te laten testen door echte gebruikers die in jouw doelgroep passen.
Een gebruiker maakt een nieuwe test aan met enkele user scenario’s die doorlopen
moeten worden (Afb 5.4.1). Je kiest zelf wat voor gebruikers deze test moeten
uitvoeren, bijvoorbeeld een huismoeder met twee kinderen of een computer-expert
van middelbare leeftijd. De website belooft in één uur de eerste testresultaten binnen
te hebben.
Afb 5.4.1 - Gebruiker maakt een user scenario aan
De gebruiker krijgt via zijn mail een link naar de video van een testpersoon die zijn website of applicatie gebruikt (Afb. 5.4.2).
De tester geeft tijdens het gebruiken van de website continu commentaar en vertelt waarom hij of zij bepaalde handelingen doet op de website. De tester voert dus een echte usability test uit.
Afb 5.4.2 - Een gebruiker bekijkt een video van een testpersoon
Pros:
• Echte usability tests
• Snel, binnen een uur test resultaat
• Voorgedefinieerde user scenario’s templates • Grote database aan testers
• Testen van verschillende soorten websites, applicaties of games
Cons:
• 50 dollar per test
• Niet van te voren weten of een tester betrouwbaar is
5.5 Conclusie
Op dit moment zijn er verschillende tools in de markt die ingezet kunnen worden om tests uit te voeren in één of meerdere fases van het project. Elke tool heeft zijn eigen sterke punten welke het uniek maakt ten aanzien van hun concurrenten.
Er mist op dit moment echter een tool die verschillende soorten tests ondersteund. Studio Stomp zou verschillende tools moeten gebruiken om verschillende tests uit te
voeren. Dit loopt aardig op in de kosten en is ook niet toegankelijk voor klanten om zelf te testen. Alle gegevens zouden hierdoor worden verspreid.
Nu het duidelijk is op welke manieren er getest kan worden en welke tools hiervoor beschikbaar zijn is het ook belangrijk om te weten waarom er getest dient te worden. In dit hoofdstuk zal er eerst worden uitgelegd waarom testen belangrijk is aan de hand van Steve Krug, schrijver van de boeken “Don’t Make Me Think” en “Rocket Surgery Made Easy”. Daarna zal er in worden gegaan waarom Studio Stomp test en welke belangen de klant en gebruikers bij een getest product hebben.
6.1 Waarom testen belangrijk
is volgens Steve Krug
Steve Krug legt in zijn boek “Don’t Make Me Think, Revisited” uit waarom testen
belangrijk is in drie statements.
Als je een geweldige website wil, dan moet je testen.
Op het moment dat je aan een website werkt, ook al is het maar voor een paar weken, kan je niet meer met een open blik naar de website kijken. Je zit zo in het project dat je precies weet waar je alles kunt vinden op de website. Als je de website laat testen door een persoon die nog niet met de website heeft gewerkt kom je achter problemen die anders niet aan het ligt waren
Studio Stomp geeft zelf aan dat ze dit nog te weinig doen in hun huidige testproces.
“Het gebeurt te vaak dat wij de
producten laten testen door de
mensen die het hebben
gemaakt”
- Michel Stomp (Studio Stomp)
Testen met één gebruiker is 100% beter dan helemaal niet testen.
Testen werkt altijd, zelfs met de slechts mogelijke tests. Je komt altijd achter problemen die je anders niet zou hebben ontdekt.
(Krug 114)
Een test uitvoeren aan het begin van het project is beter dan vijftig tests uit te voeren aan het eind van het project.
Het is belangrijk om vroeg in het proces, als er nog tijd is om aanpassingen te maken, te testen. Een gebruikelijke aannamen in web development is dat het gemakkelijk is om snelle aanpassingen te maken. Echter, zeker als het om grote veranderingen gaat, is het niet zo makkelijk om veranderingen te maken. Als een website live staat zal een percentage van gebruikers zich tegen de gedane veranderingen keren. Elke fout die je in het begin van het proces kan veranderen zal je een hoop problemen in latere fase schelen.
6.2 Waarom test Studio
Stomp?
Studio Stomp geeft aan dat zij testen om de kwaliteiten van hun producten te
waarborgen. Als een product vol fouten zit is dit slecht voor de naam Studio Stomp
en slaan de producten die Studio Stomp niet aan bij de gebruikers. Wie wil er nou een product gebruiken wat vol fouten zit? Je wilt fouten zo vroeg mogelijk ontdekken en eruit halen, om zo een zo sterk mogelijk product in de markt te zetten.
6.3 Het belang van de klant
en gebruikers
De klant komt bij Studio Stomp om een product te realiseren waarvan zij verwachten dat deze veel zal worden gebruikt. Ze willen een zo’n best mogelijk ervaring bieden aan hun gebruikers. Het product zien zij als hun kindje en die moet zo goed mogelijk presteren. Als er door slecht testen cruciale fouten over het hoofd worden gezien zou het kunnen dat dit product niet aanslaat bij de gebruikers.
“Zodra er niet goed wordt
getest kunnen wij de plank
mis slaan”
De gebruikers zijn uiteindelijk de gene die het product moeten gebruiken. Op het
moment dat een product niet werkt zoals ze verwachten dat het werkt zullen zij snel afhaken.
“Testen herinner je eraan
dat niet iedereen denkt als
jij, weet wat jij weet en het
internet gebruikt zoals jij
doet.”
- Steve Krug (Krug 114)
In het artikel “How Long Do Users Stay on Web Pages?” van Jakob Nielsen op Nielsen Norman Group (www.nngroup.com) wordt er uitgelegd dat de eerste 30 seconden het belangrijkst zijn voor een gebruiker om te bepalen of zij op de website blijven. Zolang het niet meteen duidelijk is voor de gebruiker wat het doel is van de website haken zij
af. (Nielsen Norman Group 2014) Als een website wordt getest op
gebruiksvriendelijkheid is de kans vele malen groter dat het doel bij de gebruiker snel overkomt en zal de gebruiker minder snel afhaken.
6.4 Conclusie
Testen is belangrijk voor Studio Stomp om de kwaliteit van zijn producten te waarborgen. Voor de klant is het belangrijk omdat zij een product op de markt willen zetten die veel gebruikt wordt en de gebruikers willen een zo makkelijk en gebruiksvriendelijk
mogelijke ervaring. Zodra dat er niet is, haken gebruikers snel af.
Hoofstuk 7 - Functionele eisen
Hoofstuk 8 - Schetsen
Hoofdstuk 9 - Interactie ontwerp
Hoofdstuk 10 - Functionele prototype
Hoofdstuk 11 - Ontwerp
Hoofdstuk 12 - De applicatie
Aan de hand van de interviews met Studio Stomp, haar klanten en de onderzoeksresultaten zijn er enkele functionele eisen opgesteld waaraan het product moet voldoen. In de eerste versie van het product zullen alleen de meest belangrijke functies zitten. Dit kan later worden
uitgebreid met extra functionaliteiten.
7.1 Projecten
Het moet voor Studio Stomp en haar klanten gemakkelijk zijn om projecten te bekijken. Elk project kan meerdere versies bevatten. Er wordt na elke test en verbeterronde een nieuwe versie geüpload door Studio Stomp met daarin punten die zijn opgepakt.
7.2 Feedback
Op elke versie moet er gemakkelijk feedback kunnen worden gegeven. De gebruiker zou een screenshot moeten kunnen nemen van een sectie waar een probleem zich voordoet en daar een aantekening bij moeten kunnen maken. Uit de interviews bleek het voor de klanten lastig te zijn te achterhalen welke browser, browser versie,
schermafmeting en OS (operating system) zich een probleem voordoet. Dit moet tijdens het plaatsen van het feedback
automatisch worden achtergelaten. Hier moet het ook duidelijk zijn wat Studio Stomp met dit feedback gaat doen.
7.3 Tests
Naast het kunnen bekijken van een project en daar feedback op te leveren moet het ook mogelijk zijn bepaalde tests uit te voeren. Om een website goed te testen dient er zowel een functionele als usability test te worden uitgevoerd. Voor de functionele test is een checklist bedacht. Een checklist werkt gemakkelijk, snel en is overzichtelijk. Als usability test wordt er een user scenario test toegevoegd. Dit is een gemakkelijk op te zetten usability test die niet te veel tijd kost om uit te voeren voor een gebruiker.
7.4 Agenda
Omdat Studio Stomp vaak een deadline stelt voor het aanleveren van feedback dient
het ook mogelijk te zijn bepaalde deadlines te stellen voor feedback en het uitvoeren
van tests. Deze moeten overzichtelijk worden weergegeven in een agenda.
7.5 Randvoorwaarden
Toen het project begon was het eerste idee om het product helemaal uit te werken tot een volledig werkende applicatie met voor en achterkant. Na verloop van tijd en veel
onderzoek bleek het project te grootschalig te zijn om door één persoon in een half
jaar tijd te bouwen. Daarom is in overleg met Studio Stomp besloten om het project als proof of concept te beschouwen. Dit betekent dat er alleen een voorkant zal worden
gemaakt die de belangrijkste functionaliteiten bezit. De applicatie zal geoptimaliseerd
worden voor Google Chrome met een minimale schermafmeting van 1280px bij 800px.
Na het vast stellen van de belangrijkste functionaliteiten is er begonnen om de eerste schermen te schetsen. Om inspiratie op te doen en een goed beeld te krijgen hoe
webapplicaties in elkaar zitten heb ik gekeken naar verschillende ontwerpen van
webapplicaties. Deze heb ik gevonden op Dribbble (www.dribbble.com).
Dribbble is een digital designer community. Elke dag plaatsen de beste designers en talenten uit de digitale design industrie hun werk. Er wordt zowel werk in uitvoering geplaatst, als werk wat af is. Om in de community te komen moet je worden uitgekozen door leden van Dribbble aan de hand van je werk. Op Dribbble zitten o.a. designers van Google, Spotify en Dropbox.
8.1 Inspiratie
Tijdens het zoeken naar inspiratie heb ik gekeken naar patronen die veel voorkomen bij webapplicaties. Een veel voorkomend patroon is de navigatie die aan de zijkant wordt geplaatst. De navigatie bevat iconen voor extra visuele confirmatie wat er op elke pagina te vinden is. Bijvoorbeeld een
navigatie item voor de agenda pagina heeft een kalender icoon. Op kleinere schermen worden alleen de iconen getoond om zo optimaal gebruik te maken van de beschikbare ruimte.
Verder is een veel voorkomend patroon een balk aan de bovenkant. Hier kan informatie kwijt als de pagina titel, zoekbalk en
gebruikersinfo.
Enkele voorbeelden die als inspiratie hebben gediend van mijn applicatie:
Afb. 8.1.1 - My Form UI. Vincent Tantardini via Dribbble
Afb 8.1.2 - Mixpanel Survery Analytics UI/UX. Mason Yarnell via Dribbble
Afb. 8.1.3 - Aspree. Zulal Ahmed via Dribbble
Wat mij vooral aansprak bij deze voorbeelden zijn het slim kleur gebruik om secties
van elkaar te scheiden. Verder zijn deze voorbeelden volgens de flat design stijl en wordt er handig gebruik gemaakt van steunkleuren om accenten te leggen. Ook wordt er slim gebruik gemaakt van de
beschikbare ruimtes. Het menu en de bovenste balk blijven vrij smal, zodat er genoeg ruimte is om alle informatie kwijt te kunnen.
8.2 Eerste schetsen
Na inspiratie opgedaan te hebben, is er begonnen met het schetsen van de eerste schermen. Deze zijn zeer ruw en snel gemaakt, om zo een paar verschillende varianten uit te proberen (Afb.8.2.1). De schermen zijn besproken met de interactie designer bij Studio Stomp en na overleg is er bepaald om gedetailleerder schermen te schetsen.
Afb. 8.2.1 - Een eerste schets van de applicatie
8.3 Gedetailleerde schetsen
Na de eerste schetsen is er gekozen om enkele schermen gedetailleerder uit te werken(Afb. 8.3.1 & Afb. 8.3.2). De schermen
en geven de belangrijkste functionaliteiten aan. De uitgewerkte schetsen zijn gebruikt om een eerste paper prototype te houden binnen Studio Stomp.
Afb. 8.3.1 - Gedetailleerde schets van de dashboard (beginscherm)
Afb. 8.3.2 - Gedetailleerde schets van een functionele test
8.4 Paper prototype
De paper prototype is gehouden met de interaction designer en lead developer
bij Studio Stomp. Belangrijkste bevindingen tijdens de paper prototype waren
voornamelijk op de dashboard (beginscherm) gericht.
Bij de eerste schetsen waren alle projecten te zien, onderverdeeld in open en
afgesloten projecten. In de praktijk blijkt dat de meeste projecten nooit afgesloten zijn. Er worden altijd nog bug fixes en
verbeteringen na live gang van een project gedaan. Daarom is er besloten om de vier meest recente projecten te tonen. Een project is recent als er een nieuwe versie is geüpload, nieuwe feedback is geplaats of als er
gereageerd is op feedback.
Verder werd er op de dashboard een agenda en recente activiteiten getoond. De
recente activiteiten zijn op de dashboard geschrapt voor een overzicht van de laatste test. Dit is gedaan omdat je op de dashboard de meest relevante informatie wilt
tonen. Recente activiteiten waren tevens overbodig op de dashboard, omdat recente projecten al aangeeft dat er recente activiteit is geweest.
8.5 Conclusie
De gedetailleerde schetsen hebben de basis gevormd voor de rest van het project. De paper prototype heeft bewezen dat, mits enkele aanpassingen, een goed startpunt zijn voor het beginnen van het interactie ontwerp. De belangrijkste functionaliteiten zijn met de paper prototype uitgewerkt en getest.
Om een goed overzicht te krijgen van de applicatie, zijn pagina’s en de functionaliteiten is een goed interactie ontwerp van belang. Robert Reimann, mede auteur van het populaire boek “About Face 3: The Essentials of Interaction Design”, omschrijft in zijn blog post op cooper.com (http://www.cooper.com/journal/2001/06/ so_you_want_to_be_an_interacti.html) interactie design als volgt:
“Interaction Design is een
ontwerp discipline gewijd aan
het definiëren van het gedrag
van voorwerpen, omgevingen
en systemen”
- Robert Reimann
Als interactie ontwerp is er tijdens dit project gekozen voor wireflow.
9.1 Wireflow
Een wireflow is een combinatie van
wireframes (zie hoofdstuk 4.5. Prototype) en een flowchart.
“Een flowchart is een grafische
representatie over hoe een
proces werkt, welke minstens
de opeenvolging van de
stappen volgt.”
- Edraw (http://www.edrawsoft.com/Flowchart-Definition.
php)
In een wireflow worden micro-wireframes (kleinschalige wireframes die alleen
globaal de vlakindeling bepalen) aan elkaar gekoppeld, om zo de flow van de website te bepalen. Een wireflow is tijdbesparend, omdat de wireframes niet gedetailleerd uitgewerkt te worden. Verder zijn wireflows overzichtelijker dan een flowchart en
beter te begrijpen voor mensen die weinig ervaring met flowcharts hebben.
Zie bijlage D voor de wireflow van de test- en feedbackapplicatie.
Een belangrijke functie binnen de applicatie is het achterlaten van feedback. Voordat er verder werd gegaan met het ontwerpen van de applicatie is er een prototype van deze functionaliteit gemaakt, om er achter te komen of het manier van feedback achterlaten realiseerbaar was.
10.1 Stappen
Na overleg met Studio Stomp is er besloten om het achterlaten van feedback via de volgende stappen te laten werken:
• De gebruiker bekijkt een website.
• De gebruiker ziet een fout in de website welke hij aan Studio Stomp wil doorgeven.
• De gebruiker drukt op de knop feedback plaatsen • De gebruiker maakt een selectie van de website
waar het probleem zich voordoet.
• De applicatie maakt een screenshot van de selectie en haalt de browser, OS (operating system) en schermafmetingen op.
• De gebruiker beschrijft de fout en plaatst de feedback in de applicatie.
10.2 Prototype
Het prototype (Afb. 10.2.1) is opgebouwd door middel van HTML 5 en javascript.
Door middel van het nieuwe HTML 5 element canvas is het mogelijk html om te zetten naar een afbeelding.
Afb. 10.2.1 - Gebruiker maakt een selectie in het prototype
De techniek achter het maken van de
screenshot is vrijwel identiek aan de manier waarop Google Feedback dat doet (http:// www.google.com/tools/feedback/intl/nl/). Op het moment dat een gebruiker feedback wilt achterlaten wordt de huidige html van de pagina opnieuw opgebouwd in een canvas element. Dit kent wel enige limitaties.
Het is niet mogelijk om html van een externe website in een canvas element te laden.
Dit betekent dat de test- en
feedbackapplicatie op dezelfde server moet draaien als dat de producten van Studio Stomp doen. Dit is echter geen probleem aangezien Studio Stomp een eigen testserver heeft.
Ook zijn de screenshots die worden gemaakt niet één op één hetzelfde met wat de
gebruiker ziet. Het canvas element kan op dit moment nog niet alle nieuwe CSS3 regels even goed presenteren.
Na overleg met Studio Stomp is besloten dat dit ook geen obstakel vormt bij het
achterlaten van feedback. De screenshot in samenwerking met de omschrijving en de browser gegevens van de gebruiker is voor Studio Stomp voldoende om het probleem te identificeren.
10.3 Conclusie
Dankzij het prototype is bewezen dat één van de belangrijkste functionaliteiten van
de applicatie realiseerbaar is. De voor en nadelen zijn zorgvuldig overwogen en er is er voor gekozen om de functionaliteit toe te voegen aan de applicatie. Op het moment dat de functionaliteit niet of onvoldoende werkte was er weer terug gegaan naar de tekentafel om een nieuwe manier van
feedback achterlaten te bedenken. Dit bleek niet nodig te zijn. Uiteindelijk is de code van het prototype gebruikt tijdens het realiseren van de applicatie.
Belangrijk tijdens het ontwerpen van de applicatie was om de nieuwe huisstijl van Studio Stomp als basis te gebruiken. Studio Stomp lanceert rond het schrijven van dit rapport zijn nieuwe website. De nieuwe huisstijl is gebaseerd op het flat design principe.
“Flat design is het
vereenvoudiging van een
interface door middel van
het verwijderen van extra
elementen zoals schaduwen,
schuine randen, texturen en
gradiënten die een 3D-look
creëren.”
- Antonio Pratas (http://www.awwwards.com/flat-design-an-in-depth-look.html)
In dit hoofdstuk zullen de belangrijkste schermen in de applicatie aanbod komen. Screenshots van alle pagina’s zijn te vinden in bijlage E.
11.1 Dashboard
Het dashboard is de eerste pagina die een gebruiker ziet zodra hij is ingelogd. De belangrijkste functionaliteit van een dashboard is het tonen van de meest
relevante informatie voor de gebruiker. In het boek “Design Interfaces. 2nd Edition” legt Jennifer Tidwell uit waarom een dashboard goed werkt voor een webapplicatie.
“Dashboards zijn een
vertrouwde en herkenbare
stijl van pagina’s. Zij hebben
een lange geschiedenis, zowel
online als in de fysieke
wereld en gebruikers weten
hoe dashboards werken. Ze
vertonen nuttige informatie en
worden vanzelf vernieuwd met
nieuwe data.”
(Tidwell 168)
Op de dashboard zijn de recente projecten, overzicht van de beschikbare tests en de agenda met daarin de deadlines te vinden. Meer over het totstandkoming van de dashboard is te vinden in hoofdstuk 8.4 Paper prototype.
11.2 Project pagina
Op de project pagina is een overzicht te vinden van alle projecten die gekoppeld
zijn aan de gebruiker. Een klant zal alleen zijn eigen projecten kunnen bekijken. Een
medewerker van Studio Stomp zal alle projecten kunnen bekijken die in de
applicatie zijn geplaatst. Om het voor Studio Stomp overzichtelijk te houden is er voor gekozen om projecten te groeperen bij klant.
11.3 Project detail pagina
Zodra een gebruiker een project opent zal hij op het project detail pagina komen. Op
deze pagina zijn alle versies van het project te bekijken. Er wordt een nieuwe versie
aangemaakt door Studio Stomp op het moment dat een test- en feedbackronde is afgerond en de punten zijn verbeterd en verwerkt. Tijdens het testen kwam naar boven dat de klant graag een overzicht zou willen zien van welke punten er zijn
opgepakt en verwerkt. In een volgende versie
van de test- en feedbackapplicatie zou dit moeten worden toegevoegd.
11.4 Bekijk project
Op het moment dat een versie wordt geopend door een gebruiker wordt de website
binnen de applicatie getoond. De gebruiker kan de website bekijken en gebruiken zoals hij normaal ook zou doen. Aan de zijkant van de applicatie is er een paneel. In dit paneel zitten verschillende opties. Zo is het mogelijk om al geplaatste feedback te tonen of te verbergen (de gele bolletjes op de pagina).
De gebruiker kan tevens nieuwe feedback plaatsen zodra hij of zij een fout of probleem tegen komt op de website. Hoe dit in zijn werk gaat kunt u lezen in hoofdstuk 10. Functionele prototype.
Verder is het mogelijk om te switchen tussen drie verschillende weergaven. Door middel van deze functie kan de website worden bekeken in de desktop weergave, tablet weergave en de mobiele weergave. Door op de gele bolletje in de pagina te klikken kan er reeds geplaatste feedback worden bekeken.
Dit voorkomt dat er dubbele feedback wordt geplaatst.
Boven aan de pagina is het mogelijk om naar de feedback pagina van het desbetreffende project te navigeren.
Komt de gebruiker voor het eerst op deze pagina dan zal er door middel van een tooltip informatie worden getoond over deze functies en hoe deze te gebruiken zijn.
11.5 Feedback van het
project
De feedback die is geleverd kan op twee verschillende manieren worden bekeken. Op het moment dat de feedback pagina wordt geopend ziet de gebruiker verschillende feedback blokken met daarin een screenshot, browser informatie en reacties. Dit is een visuele weergaven van al het feedback. Echter neemt deze vorm ook veel ruimte in beslag. Daarom is het mogelijk om ook over te gaan naar een lijstweergave. De lijstweergave zorgt voor meer overzicht en is handig voor projecten waar veel feedback op is geleverd. In beide gevallen is het mogelijk voor de gebruiker om te reageren op reeds geplaatste feedback.
11.6 Test overzicht pagina
De testpagina is vrijwel identiek aan de project pagina. Hier zal dan ook niet dieper op in worden gegaan. Zodra de gebruiker een project opent via de test pagina komt hij op de test overzicht pagina van dat project. Op deze pagina staat een overzicht van de open en afgesloten tests. Verder zijn er enkele statistieken te bekijken, om zo een sneloverzicht te hebben van het project.
De statistieken bestaan uit een weergave van het aantal open tests tegen het totaal aantal tests, aantal tests per testtype en hoeveel tests er reeds zijn ingevuld door gebruikers.
Er is gekozen om in de eerste versie twee type tests toe te voegen. Een functionele test in de vorm van een checklist en een usabillity test met behulp van user scenario’s. Meer over deze type tests is te vinden in hoofdstuk 4.2. User scenario’s en hoofdstuk 4.3. Functioneel testen.
11.7 Checklist test
Zodra een test wordt gestart komt de
gebruiker op een vergelijkbare pagina terecht als de bekijk project pagina. Echter is de paneel aan de zijkant anders. Bij een checklist test zal er in het paneel enkele vragen worden gesteld die kijken of de functionaliteiten
van de website werken. Door middel van de switches aan of uit te schakelen kan de gebruiker antwoord geven op de vragen. Zodra de gebruiker klaar is met de vragenlijst kan hij door op de groene knop te drukken verder gaan naar de volgende pagina of de test beëindigen (afhankelijk van de aantal pagina’s of secties binnen de website).
De checklist lijkt in zijn functionaliteit veel op die van Launchlist (zie hoofdstuk 5.3.
Launchlist). Launchlist is erg makkelijk en vriendelijk in gebruik en daarom is er ook gekozen om binnen de test- en
feedbackapplicatie niets te veranderen aan deze functionaliteit en deze over te nemen van Launchlist.
11.8 User scenario test
Bij een user scenario test krijgt de gebruiker een kort verhaaltje over een potentiële
gebruiker van de website. De gebruiker heeft een bepaald doel op de website en het
is aan de tester om dit doel te voltooien. Als de gebruiker het doel haalt zal de test
automatisch stoppen, lukt de gebruiker het niet om de test te halen kan hij de test alsnog stoppen door op de rode knop met beëindig test te klikken.
Tijdens de user scenario test wordt alles wat de gebruiker doet geregistreerd.
Gaat de gebruiker met zijn muis over een navigatie item? Dan zal dit in de test worden opgeslagen. Verder registreert de applicatie hoe lang een gebruiker bezig is met het uitvoeren van een test. Lange tijden kunnen betekenen dat het voor de gebruiker te moeilijk is om bepaalde doelen binnen de website te voltooien.
11.9 Test uitslag
Na het voltooien van een test komt de gebruiker op de test uitslag pagina. Op deze pagina is afhankelijk van de type test de uitkomsten te zien.
Bij een checklist test zal er een overzicht worden gegeven van de afgekeurde en goedgekeurde punten per pagina.
Bij een user scenario is een overzicht te zien van alle handelingen die er zijn gedaan tijdens het testen. Zo kan Studio Stomp precies
zien waar eventuele gebruiksvriendelijkheid problemen optreden. In een volgende versie van de test- en feedbackapplicatie zou het toevoegen van heatmaps extra inzicht kunnen leveren in de testresultaten.
“Een heatmap is een
visualisatie die wordt gebruikt
om drie dimensionale data te
visualiseren. Twee dimensies
vormen de x en y coordinaten
en de derde wordt gebruikt
om de intensiteit van een
datapunt te visualiseren.”
- Patrick Wied (http://www.patrick-wied.at/static/heatmapjs/)
Met de heatmap is het mogelijk om
bijvoorbeeld te bekijken waar de gebruiker het meest op geklikt heeft.
11.10 Agenda
De agenda pagina is een vergrote versie van de agenda op het dashboard. Een belangrijke toevoeging op deze pagina is de mogelijkheid om de deadlines te exporteren naar de
gebruikers favoriete agenda programma zoals iCal of Gmail.
Zodra er door Studio Stomp een nieuwe deadline is ingesteld zal de gebruiker een e-mail krijgen met daarin de mededeling dat er een nieuwe deadline is vastgesteld.
Tevens zal de gebruiker een reminder via
e-mail krijgen zodra er een deadline op komst is.
Alle ontwerpen zijn uitgewerkt in een werkend product. In dit hoofdstuk wordt er beschreven welke tools en talen er gebruikt zijn om de applicatie te bouwen en hoe het bouwproces in elkaar zat. Nadat de grootste gedeelte van de applicatie gebouwd was zijn er testmomenten geweest met Studio Stomp en haar klanten.
12.1 Tools
Tijdens het bouwen is er voor gekozen om de applicatie te bouwen op Backbone.
js (http://backbonejs.org/). Backbone is een javascript library speciaal gemaakt om
webapplicaties te maken. Door de sterke fundering van Backbone en het niet moeten refreshen van de pagina’s is de applicatie snel en gemakkelijk in gebruik.
Andere noemenswaardige javascript plugins en libraries die zijn gebruikt om de applicatie te bouwen zijn require.js (http://requirejs. org/) voor het inladen van de verschillende javascript bestanden en jQuery (http:// jquery.com/) voor DOM manipulaties.
Bij Studio Stomp wordt er gebruik gemaakt van SASS (http://sass-lang.com/) in
combinatie met Compass (http://compass-style.org/). Deze twee libraries zorgen ervoor dat je eenvoudiger en sneller css kan schrijven.
12.2 Bouwproces
Functionaliteit was voor Studio Stomp belangrijker dan het uiterlijk van de
applicatie. Daarom is tijdens het bouwen van de applicatie pas op het laatste moment de vormgeving toegevoegd. Tijdens het
bouwproces waren de pagina’s opgebouwd uit wireframes. Er werd per pagina gebouwd en pas verder gegaan naar een volgende pagina als alle functionaliteiten binnen de pagina werkte. Nadat alle pagina’s zo goed als af waren gerond is de vormgeving toegevoegd.
12.3 Testresultaten
Nadat de applicatie was gebouwd zijn er enkele testmomenten geweest met Studio Stomp en haar klanten. De applicatie is voorgelegd aan de testpersonen en deze kregen de taak om te omschrijven wat ze op
de verschillende pagina’s binnen de applicatie volgens hen konden doen. Verder werd er gevraagd of zij feedback konden achterlaten op een project en een test naar keuze uit te voeren.
De grootste problemen kwamen naar voren op de “Bekijk project” pagina. Daar werd gevraagd of zij feedback konden achterlaten op de website die zij bekeken. Allen drukten ze op de “nieuwe feedback” knop en wachtten ze tot er wat ging gebeuren. Nadat er werd uitgelegd dat ze een selectie moesten maken van de website hadden ze het snel door. Om dit probleem te tackelen zijn er tooltips toegevoegd aan de “Bekijk project”,
“Checklist test” en “User scenario test” pagina (Zie afb. 12.1.1). Deze tooltips worden getoond op het moment dat een gebruiker één van deze pagina’s voor het eerst bezoekt. In de tooltips wordt er uitgelegd wat er op de pagina kan worden gedaan en hoe je dat moet doen. Op de “Bekijk project” pagina wordt er bijvoorbeeld uitgelegd dat je een na het klikken van de nieuwe feedback button een selectie moet tekenen op de website.
Afb 12.1.1 - De tooltip in actie
Naast deze grote usability issue kwamen er vooral veel kleinere bugs naar boven.
Deze bugs zijn genoteerd en de meest kritieke bugs zijn opgelost en verbeterd in de
Hoofdstuk 13 - Conclusie
Hoofdstuk 14 - Advies
Hoofdstuk 15 - Tot slot
Hoofdstuk 16 - Bronnenlijst
Aan het begin van het project is als doel gesteld om een applicatie te ontwikkelen welke het test- en feedbackproces binnen Studio Stomp optimaliseert, zodat het voor Studio Stomp en haar klanten gemakkelijker wordt te testen en feedback te leveren.
Om de probleemsituatie te schetsen zijn er als eerst interviews gehouden met de creative director en project manager bij Studio Stomp (zie hoofdstuk 2). Daarin is vastgesteld dat het huidige proces verre van ideaal is. Er zijn vervolgens verdere interviews gehouden met Studio Stomp en haar klanten om meer te weten te komen over de doelgroep van de applicatie (zie hoofdstuk 3). In dit hoofdstuk is er dieper op de probleemsituatie ingegaan en is er gekeken naar de huidige manier van testen door Studio Stomp en haar klanten. Daar is naar voren gekomen dat er in het huidige proces enkele knelpunten bevinden. Om een applicatie te maken welke het mogelijk maakt websites te testen, moest er eerst onderzoek worden gedaan naar de verschillende testmethodes die er zijn om een
website te testen (zie hoofdstuk 4). Hieruit is de conclusie getrokken dat een website pas optimaal getest is zodra er zowel op functionaliteit als op gebruiksvriendelijkheid tests zijn uitgevoerd. Aan de hand van deze criteria en testmethodes is er gekeken naar de concurrenten in de markt (zie hoofdstuk 5). Hoewel elke reeds beschikbare tool in de markt zijn eigen sterke punten heeft, bestaat er geen tool waarbij het mogelijk is om zowel een functionele als een
gebruiksvriendelijkheid tests uit te voeren. Er is verder gekeken naar de verschillende belangen die er spelen bij de doelgroep als een product getest dient te worden (zie hoofdstuk 6). Aan de hand van interviews is er achterhaald dat de doelgroep om verschillende redenen test. Studio Stomp vindt het belangrijk om de kwaliteit van het product te waarborgen, de klant wil graag een product op de markt brengen die aanslaat bij de potentiële eindgebruikers en die willen op zijn beurt een product zonder fouten anders haken zij snel af.
