Test & Feedback applicatie. Onderzoek naar testmethodes en het verzamelen van feedback binnen Studio Stomp

Transcriptie

1 Test & Feedback applicatie Onderzoek naar testmethodes en het verzamelen van feedback binnen Studio Stomp Tim Goosens ( ) Communication and Multimedia Design HVA Begeleider: Robert van Boeschoten Amsterdam, 9 juni 2014

2

3 Voorwoord 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. 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 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, 1

4 Managementsamenvatting 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. 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. 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 testen 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 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 2

5 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. 3

6 Inhoudsopgaven Inleiding Studio Stomp Probleemstelling Onderzoeksvraag Deelvragen Indeling rapport Begrippenlijst 9 Probleemsituatie Onvolledig Tijdrovend Chaotisch Doelstelling Oplevering 11 De doelgroep Testsituatie Studio Stomp Testplan Hoe test de klant Knelpunten Conclusie 15 Testmethodes Usability testing User scenario s Functioneel testen A/B testing Prototyping Conclusie 22 Concurentie analyse Cage App Track Duck Launchlist UserTesting Conclusie 27 Waarom testen? Waarom testen belangrijk is volgens Steve Krug Waarom test Studio Stomp? Het belang van de klant en gebruikers Conclusie 30 Functionele eisen Projecten Feedback Tests Agenda Randvoorwaarden 33 Schetsen Inspiratie Eerste schetsen Gedetailleerde schetsen Paper prototype Conclusie 37 4

7 Interactie ontwerp Wireflow 38 Functionele prototype Stappen Prototype Conclusie 40 Ontwerp Dashboard Project pagina Project detail pagina Bekijk project Feedback van het project Test overzicht pagina Checklist test User scenario test Test uitslag Agenda 45 De applicatie Tools Bouwproces Testresultaten 46 Conclusie 49 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 E. Scherm ontwerpen 77 Advies Backend Features 51 Tot slot 53 Bronnenlijst 54 5

8 Probleemstelling Hoofdstuk 1 - Inleiding Hoofdstuk 2 - Probleemsituatie

9 Inleiding 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 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. 7

10 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) 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). 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) 8

11 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. 9

12 Probleemsituatie 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 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. 10

13 2.4 Doelstelling De doelstelling van mijn tool is om het testen 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. 11

14 Onderzoek Hoofdstuk 3 - De doelgroep Hoofdstuk 4 - Testmethodes Hoofdstuk 5 - Concurentie analyse Hoofdstuk 6 - Waarom testen?

15 De doelgroep 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. 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.1 Testsituatie Studio Stomp Studio Stomp werkt aan de hand van een iteratief proces met meerdere fases. Deze fases kunnen in verschillende samenstellingen éé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 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. Monitoring en onderhoud 13

16 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. 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 , 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. Vaak is de klant van Studio Stomp niet de eindklant van het project. In dat geval wordt het product ook nog doorgestuurd naar de 14

17 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. waar bepaalde problemen zich voordoen is lastig te achterhalen. 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) 15

18 Testmethodes 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. 16

19 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 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. 17

20 Op Cloudforrest Design ( 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) 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: 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) 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 18

21 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 moet werken. 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 ( 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 website of applicatie te halen. 19

22 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. (conversie, verkoop, weigeringspercentage, etc.). Na de testperiode wordt de versie gekozen welke het best presteert. (Chopra et al. 6) 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 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 ( nl/ab-split-test-duration/). (9) 20

23 Een uitgebreide lijst van alle do s en don ts zijn te vinden in het boek op pagina 8 en 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 ). 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 ). 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 Afb 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 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. 21

24 Om een website goed te testen moet je zowel testen op gebruiksvriendelijkheid als functionaliteit. Afb 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. 22

25 Concurentie analyse 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. 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. 5.1 Cage App 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. Afb Notitie en discussie op een selectie van het design binnen Cage 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 ). Ook biedt Cage de mogelijkheid aan om revisies bij te houden (Afb ). Dit houdt in dat het voor de Afb Overzicht van revisies 23

26 Andere functionaliteiten binnen Cage zijn Todo 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 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 ). 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. Cons: Alleen gericht op design 5.2 Track Duck 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. Afb 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. Naast design ondersteunt Track Duck ook live websites. Door een javascript bestand toe te voegen aan de site wordt er een Track 24

27 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. templates aan te maken. In deze templates kan er een aantal punten worden gedefinieerd die vaak terugkomen in verschillende projecten (Afb ). 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. 5.3 Launchlist 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 ). Afb Een checklist wordt ingevuld op Launchlist Launchlist heeft enkele handige functies die het proces van de checklists aanmaken en uitvoeren versnellen. Zo is het mogelijk om 25

28 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 Afb Overzich van aangemaakte templates per soort website Pros: Makkelijk in gebruik 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. 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 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 Afb 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 ). 26

29 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 Een gebruiker bekijkt een video van een testpersoon Pros: 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. 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 27

30 Waarom testen? 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 gekomen. (Krug 114) 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. (Krug 115) 28

31 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 - Bas van Bokhorst (GreenBerry) 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 ( 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. 29

32 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. 30

33 Oplossing Hoofstuk 7 - Functionele eisen Hoofstuk 8 - Schetsen Hoofdstuk 9 - Interactie ontwerp Hoofdstuk 10 - Functionele prototype Hoofdstuk 11 - Ontwerp Hoofdstuk 12 - De applicatie

34 Functionele eisen 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 32

35 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. 33

36 Schetsen 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 ( 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. 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: 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 Afb My Form UI. Vincent Tantardini via Dribbble 34

37 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 Afb Mixpanel Survery Analytics UI/UX. Mason Yarnell via Dribbble schermen zijn besproken met de interactie designer bij Studio Stomp en na overleg is er bepaald om gedetailleerder schermen te schetsen. Afb 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 Afb Een eerste schets van de applicatie voorbeelden volgens de flat design stijl 8.3 Gedetailleerde schetsen en wordt er handig gebruik gemaakt van Na de eerste schetsen is er gekozen om enkele steunkleuren om accenten te leggen. Ook schermen gedetailleerder uit te werken wordt er slim gebruik gemaakt van de (Afb & Afb ). De schermen bevatten de grote contouren van de applicatie 35

38 en geven de belangrijkste functionaliteiten aan. De uitgewerkte schetsen zijn gebruikt om een eerste paper prototype te houden binnen Studio Stomp. 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 Afb Gedetailleerde schets van de dashboard (beginscherm) Afb Gedetailleerde schets van een functionele test 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. 36

39 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. 37

40 Interactie ontwerp 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 ( 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 ( 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. 38

41 Functionele prototype 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 Prototype Het prototype (Afb ) 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 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. Afb 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 ( 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. 39

42 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. feedback achterlaten te bedenken. Dit bleek niet nodig te zijn. Uiteindelijk is de code van het prototype gebruikt tijdens het realiseren van de applicatie. 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 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 40

43 Ontwerp 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 ( In dit hoofdstuk zullen de belangrijkste schermen in de applicatie aanbod komen. Screenshots van alle pagina s zijn te vinden in bijlage E 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) 41

44 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 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 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 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. 42

45 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 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 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 snel overzicht 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 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 43

46 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 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 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. 44

47 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 ( krijgen zodra er een deadline op komst is. Met de heatmap is het mogelijk om bijvoorbeeld te bekijken waar de gebruiker het meest op geklikt heeft 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 krijgen met daarin de mededeling dat er een nieuwe deadline is vastgesteld. Tevens zal de gebruiker een reminder via 45

48 De applicatie 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 Tools Tijdens het bouwen is er voor gekozen om de applicatie te bouwen op Backbone. js ( 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 ( org/) voor het inladen van de verschillende javascript bestanden en jquery ( jquery.com/) voor DOM manipulaties. Bij Studio Stomp wordt er gebruik gemaakt van SASS ( in combinatie met Compass ( Deze twee libraries zorgen ervoor dat je eenvoudiger en sneller css kan schrijven 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 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 46

49 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 ). 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 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 applicatie. 47

50 Afronding Hoofdstuk 13 - Conclusie Hoofdstuk 14 - Advies Hoofdstuk 15 - Tot slot Hoofdstuk 16 - Bronnenlijst

51 Conclusie 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. 49

52 Aan de hand van de onderzoeksresultaten zijn er functionele eisen gesteld aan de applicatie (zie hoofdstuk 7). De applicatie ondersteunt zowel functionele tests, aan de hand van een checklist en een usability test doormiddel 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. 50

53 Advies De applicatie heeft de potentie om het test- en feedbackproces van Studio Stomp drastisch te verbeteren. Uit onderzoek, interviews en tests is naar voren gekomen dat het voor zowel Studio Stomp als de klant gemakkelijk in gebruik is en een hoop knelpunten wegneemt. Deze applicatie diende echter als proof of concept en is het nog niet zo ver ontwikkeld dat het nu ingezet kan worden. Om de applicatie gebruiksklaar te maken dienen er enkele toevoegen en aanpassingen gedaan te worden Backend Op dit moment is alleen de front-end (voorkant) van de applicatie gerealiseerd. Echter dient er ook een backend (achterkant) gemaakt te worden. In de backend moet het mogelijk zijn voor Studio Stomp om project toe te voegen, versies te uploaden en tests aan te maken. Of hiervoor een externe applicatie zou moeten worden gebouwd of dat de backend in de huidige applicatie past zou verder onderzocht moeten worden Features Tijdens de laatste test zijn er enkele punten naar boven gekomen die de applicatie sterk zouden verbeteren, maar waar geen tijd meer voor was om te realiseren Logboek Bij een project kunnen meerdere versies worden geüpload. Elke versie verschijnt na een test- en feedbackronde. Een versie bevat verschillende bug fixes en verbeteringen. Voor de klant zou het overzichtelijk zijn om bij elke versie een logboek met de fixes en verbeteringen op de kunnen vragen. Zo weet de klant welke problemen er zijn opgepakt en wat er nog open staat Jira Uit onderzoek blijkt dat Studio Stomp en de klant graag een koppeling ziet tussen de applicatie en het issue tracking systeem Jira. Met behulp van Jira zou het mogelijk zijn voor Studio Stomp om feedback om te zetten naar een issue. Jira heeft een eigen API, wat het gemakkelijk maakt om via een externe applicatie issues te importeren naar 51

54 dit systeem. Zo weet de klant wat er met zijn feedback wordt gedaan en scheelt het Studio Stomp tijd om feedback over te zetten naar het issue tracking systeem. De precieze invulling en hoe dit eruit zou zien moet verder onderzocht worden. 52

55 Tot slot Dit rapport en de bijbehorende applicatie was nooit tot stand gekomen dankzij de hulp van verschillende mensen. Als eerst wil ik Studio Stomp bedanken voor hun tijd, creativiteit en technische hulp die zij tijdens het hele project beschikbaar stelden. Verder gaat mijn dank uit naar Avinash Changa van DSRPT, Dennis Maij van We Are Bold en Bas van Bokhorst van GreenBerry voor hun tijd die zij hebben vrijgemaakt voor interviews en testmomenten. Ook wil ik graag Robert van Boeschoten en Charlie Mulholland van het HVA bedanken voor de begeleiding tijdens het project. Toen ik bij Studio Stomp bijna twee jaar geleden binnen kwam, teste ik mijn producten nooit op de juiste manier. Ik nam vaak aan dat producten werkte en teste het dan ook niet op de verschillende browsers. In de tijd dat ik bij Studio Stomp werkte ben ik steeds meer en meer gaan testen. Dit heeft mij ook doen inzien hoe belangrijk testen is voor een product en toen Studio Stomp met de vraag kwam om mijn afstudeerproject te gaan doen om het testproces van Studio Stomp te verbeteren, was dit voor mij ook niet meer dan een logische vervolgstap. Dit project heeft mij geleerd dat testen nog altijd een moeilijk onderwerp is in het ontwikkelproces. Veel bedrijven hanteren verschillende methodes en er is geen één gouden regel voor testen. Het belangrijkste is dat er wordt getest en om de meeste fouten eruit te halen moet je zowel op functionaliteit, als op gebruiksvriendelijkheid testen. Verder heb ik tijdens dit project veel nieuwe technieken geleerd die mij zullen helpen in de rest van mijn loopbaan als developer. Als laatst gaat mij dank uit aan u voor het lezen van mijn rapport. Ik hoop dat u dit rapport met plezier heeft gelezen. 53

56 Bronnenlijst A/B, Split and Multivariate Test Duration Calculator. Visual Website Optimizer. N.p., n.d. Web. 10 Apr < Ahmad, Zulal. Aspree. Digital image. Dribbble. N.p., 30 Jan Web. 11 Mar < dribbble.com/shots/ aspree>. A Javascript Module Loader. RequireJS. N.p., n.d. Web. 04 Apr < Backbone.js. Backbone.js. N.p., n.d. Web. 04 Apr < Bannister, Chris. Desktop. Digital image. Dribbble. N.p., 10 Mar Web. 7 Apr < Chapman, Cameron., Chopra, Paras., Munroe, Lee., and Gremillion, Ben. A Field Guide to Usability Testing. Freiburg, Germany: Smashing Media GmbH, ebook. Compass. Compass. N.p., n.d. Web. 04 Apr < Dribbble. N.p., n.d. Web. 11 Mar < Feedback. Google. N.p., n.d. Web. 26 May < Definition.php> JQuery. JQuery. N.p., n.d. Web. 04 Apr < Krug, Steve. Don t Make Me Think, Revisited: A Common Sense Approach to Web Usability. Berkeley, CA: New Riders Pub., Print. Krug, Steve. Rocket Surgery Made Easy: The Do-it-yourself Guide to Finding and Fixing Usability Problems. Berkeley, CA: New Riders, Print. Nadine. User Stories, Scenarios & Use Cases Cloudforrest Design. N.p., 25 apr Web. 7 apr Flow Chart Definition. Edraw. N.p., n.d. Web. 29 May < < 54

57 Nielsen, Jakob. How Long Do Users Stay on Web Pages? Nielsen Norman Group. N.p., 12 Sept Web. 03 May < POP App in actie. Digital image. POP App. N.p., n.d. Web. 7 Apr < Sass: Syntactically Awesome Style Sheets. Sass: Syntactically Awesome Style Sheets. N.p., n.d. Web. Apr < Tantardini, Vincent. Form generator UI. Digital image. Dribbble. N.p., 6 Mar Web. 13 Mar < Tidwell, Jenifer. Designing Interfaces 2e. Sebastopol: O REILLY MEDIA, INC, USA, epub. User Research Results in 1 Hour. UserTesting: Remote Usability Testing Software. N.p., n.d. Web. 10 Apr < Wied, Patrick. What Is a Heatmap? Heatmap.js. N.p., n.d. Web. 28 May < Website Checklist Application. Launchlist Pro. N.p., n.d. Web. 07 Apr < net/>. Yarnell, Mason. Mixpanel Survey Analytics UI/UX. Digital image. Dribbble. N.p., 23 Jan Web. 13 Mar < &tag=dashboard&offset=32>. 55

58 Bijlage Bijlage A - Interviews Bijlage B - Testresultaten Bijlage C - Testplan Bijlage D - Wireflow Bijlage E - Schermontwerpen

59 A. Interviews Interview Michel Stomp en Jelleke Raats Dit interview is opgesteld aan de hand van verkeer met Michel Stomp (Creative Director) en Jellek Raats (Project Manager) van Studio Stomp. In welke fase s wordt er getest bij Studio Stomp? Studio Stomp kent binnen een project een iteratief proces met meerdere fases. Deze fases kunnen in verschillende samenstellingen één project vormen. Een project kan bestaan uit alle fases of 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, innerscope Interactieontwerp: Persona s, user stories, user flow, interaction design, wireframes Visueel ontwerp: Grafisch ontwerp, UX design Development: Technische realisatie van product(en) Implementatie Monitoring en onderhoud 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. Na afronding van iedere fase moet een checklist worden opgesteld voor de volgende fase. De checklist bestaat voor een deel uit vaste punten en deels uit punten die specifiek voor een project gedefinieerd zijn. In een ideale wereld wordt iedere fase door meerdere subjecten getest. Per fase kan verschillen of meer dan één test nodig is, bijvoorbeeld gericht op type gebruiker. Wie zijn de eindverantwoordelijken bij het testen? Het is per fase verschillend wie de eindverantwoordelijke is bij het testen. In 99% van de gevallen zijn de algemeen, 57

60 technisch of creatief directeur de eindverantwoordelijke bij het testen. Bij zeer kleine en korte projecten kan het voorkomen dat de gene die aan het project heeft gewerkt de eindverantwoordelijke is voor het testen. Onderstaande lijst geeft aan wie in welke fase eindverantwoordelijke is: Inceptie: Algemeen directeur Interactie: Creatief directeur Visueel: Creatief directeur Development: Technisch directeur Implementatie: Algemeen directeur Monitoring en onderhoud: Algemeen directeur Welke testmethodes worden er op dit moment ingezet bij Studio Stomp? Studio Stomp test zijn producten doormiddel van testplannen. Deze testplannen worden opgesteld door de project manager. In de testplannen worden vooral de functionaliteit van de website of applicatie behandeld. en Is de navigatie responsive?. User Scenarios worden er op dit moment nog niet gebruikt tijdens het testen, dit wilt Studio Stomp echter wel in de toekomst gaan toepassen. Hoe wordt op dit moment feedback verzameld en verwerkt? 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 zo gehete 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). Het testplan is een Word document 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? Nadat elke fase wordt er ook een link of bestand, hangt af van de fase, naar de klant toegestuurd. Deze bekijkt de voortgang en test de website of applicatie voor zichzelf. Zijn bevindingen kunnen dan op erschillende manieren worden teruggekoppeld aan 58

61 Studio Stomp. De ene klant stuurt een mail, de ander belt Studio Stomp op of er wordt een Word document terug gestuurd met feedback en testresultaten. tussenstappen in het testen en het verzamelen en het verwerken van de testresultaten. Studio Stomp ziet dit graag geautomatiseerd worden. Dit alles is een erg tijdrovende klus en is niet naar wens van Studio Stomp. Ook raakt Studio Stomp snel het overzicht kwijt. Zeker in het geval van feedback van de klant. Deze komen via allemaal verschillende manieren binnen en er is op dit moment geen centraal punt waar dit verzameld en gearchiveerd kan worden. Welke problemen treden zich op bij de huidige manier van testen? Studio Stomp geeft aan dat de test vaak onvolledig zijn. Ze missen een generieke checklist per type project of fase met criteria waaraan alle (deel)producten (van dat type) moeten voldoen. Op dit moment zijn de tests vaak niet gebaseerd op input en resultaten uit voorgaande fases. Dit komt mede omdat het al snel onoverzichtelijk wordt wat de vorige resultaten waren en wat daar mee is gedaan. Het verzamelen van feedback is daarom erg tijdrovend. Er zitten op dit moment teveel Ook is Studio Stomp niet tevreden met de testplannen die zijn opgemaakt in Word. Deze zijn moeilijk tot niet doorzoekbaar, slecht geformatteerd en fout gevoelig. Interview Michel Stomp Dit interview is opgesteld om meer te weten over jullie testmethodes en de redenen waarom jullie testen. Om te beginnen, op welke manier testen jullie een product? Op dit moment hebben wij geen vaste methodes om te testen. Eigenlijk is het een beetje een rommeltje. In het verleden hebben wij wel gebruik gemaakt van testmethodes. Deze werden geleid door de project manager. Die schreef aan de hand van criteria, waaraan het product moet voldoen, user scenario s en functionele vragen. Dit kwam in een document en deze werd verspreid onder een aantal testers. Elke tester kreeg een aantal platformen met bijbehorende browsers. Bijvoorbeeld ik, Michel, jij moet deze scenario s doorlopen op een Mac met de browsers Chrome 59

62 en Safari. Met vragen als Zit dit erin?, Werkt alles goed? en Staat alles op de goede plek?. Daarnaast heb je developers die gewoon moeten testen wat ze bouwen. We hebben een aantal keer de focus proberen te leggen op zelf je browser tests uit te voeren, maar dit is nog niet voldoende in ons systeem verankerd. Momenteel benoemen we een aantal testers welke het product op verschillende devices en browser proberen. Dit doen ze zonder dat er een plan of document of iets dergelijks achter zit. Dit zijn ook meestal de mensen die al aan het product werken. Bevalt deze manier van testen? Kunnen jullie op deze manier de grootste gedeelte van de fouten opsporen? De testscenario s werden meestal aan het einde van het proces geschreven. Dit is eigenlijk niet ideaal. Ze zouden aan het begin van het proces moeten worden geschreven. Iets als hier en hier moet het aan voldoen en deze criteria tijdens meerdere testrondes laten terug komen. Als je dit van tevoren doet kun je ook steeds terugvallen op de testscenario s en kan je tijdens het developen steeds je product daarop testen. Waarom is het voor Studio Stomp belangrijk om een product goed te testen? Dit is belangrijk om de kwaliteit van het product te waarborgen. Als je niet test kun je alles wel maken. Maar dan weet je dat het vol fouten gaat zitten. Je doet het om fouten van je product of het nou design of functionaliteit is, zo vroeg mogelijk eruit proberen te halen. Het gebeurt nu nog steeds te vaak dat wij pas aan het eind beginnen met testen, terwijl dit toch eerder naar voren zou moeten komen. Merken jullie verschil in resultaten met geteste producten tegenover niet geteste producten? Ja, ik denk dat het op het moment wel steeds beter gaat. Dat het bij ons nu echt een product af is als wij zeggen dat het af is. Voorheen zeiden we wel eens dat een product af was en dan kregen we feedback terug van de klant of gebruikers met problemen waar wij helemaal geen rekening mee hadden gehouden. Door goed te testen loop je hier minder vaak tegen aan. Testen jullie alle producten op dezelfde manier? Nee, dat is heel verschillend. Ik denk dat dit ook altijd verschillend zal blijven. 60

63 Dit komt omdat wij verschillende soorten producten bouwen. Zo heb je producten die specifiek mobile zijn, die kun je bijvoorbeeld niet hetzelfde testen als een desktop product. Welke problemen heb je door het testen kunnen achterhalen, die anders niet naar voren waren gekomen? Een voorbeeld is bijvoorbeeld een aanmeld formulier op een website. Je kan je dan aanmelden op drie verschillende manieren. Met , Facebook en Twitter. is dan vrij gemakkelijk. Je laat je adres achter, je krijgt een bevestigings mail en dat is dat. Bij Facebook werkt dat anders, je bent ingelogd of niet ingelogd op Facebook. Als developer ben je vaak ingelogd op je Facebook en dat geeft een heel ander scenario terug als dat je niet ingelogd bent. Als je dat niet goed test loop je tegen problemen aan. Dan krijg je feedback van gebruikers terug dat het niet werkt om in te loggen met Facebook, terwijl wij dan zeggen ja het werkt wel. Maar de fouten die zich voor doen komen dan van gebruikers die nog niet zijn ingelogd in Facebook. Tegen dat soort dingen loop je aan als je niet goed en uitvoerig test. Ik weet dat de testscenario s die wij voorheen gebruikte vrij functioneel gericht waren, mis je bijvoorbeeld een usabillity test? Ja, zeker bij projecten die wij helemaal zelf maken, waar we zelf bezig zijn met het ontwikkelen van een nieuw concept. Dan zou je wel gebruikerstests willen doen. Om er echt achter te komen of wat wij hebben gedacht goed werkt. Dit hebben we in het verleden ook bij sommige projecten niet goed gedaan. Maar vaak missen wij tijd en budget. Het gebeurt nu ook te vaak dat wij de producten laten testen door de mensen die het hebben gemaakt. Je zou willen dat bijvoorbeeld drie andere mensen van kantoor, die niks met het project gedaan hebben, het product testen. Interview Avinash Changa (DSRPT, We Make VR) Bedankt dat je tijd wilt vrij nemen om een interview met mij te houden. Zou je jezelf kunnen voorstellen? Mijn naam is Avinash, oprichter en eigenaar van DSRPT Communications. Wij produceren digitale producten in het breedste zin van het woord. Dit loopt uiteen van digitale karakter animaties, after effects voor films, muziekvideo s, maar ook websites en apps. Daarnaast ben ik eigenaar van het bedrijf We Make VR. We Make VR specialiseert zich in het maken van virtual 61

64 reality en wij zijn één van de pioniers op het gebied van VR en de Oculus Rift. Zo zijn wij bezig met het ontwikkelen van een camera voor de Oculus Rift waarbij het mogelijk is 360 graden te filmen. Hoe zijn jullie in aanraking gekomen met Studio Stomp? Ik ken Michel al een langere tijd. Via via zijn wij in contact gekomen. Michel wou naast muziek maken leren developen. Hij is Flash gaan leren en mensen uit mijn vrienden kring geef ik altijd een kans. Toen hij net begon heb ik hem wat kleine klusjes gegeven. Dit ging eigenlijk prima. Zodoende heb ik Studio Stomp zien ontwikkelen, later kwam Benjamin erbij als zakenpartner en zijn ze een paar keer bij mij terecht gekomen als ze zakelijke of juridische vragen hadden. Als er nu een web gerelateerd project binnenkom denk ik als eerst aan Studio Stomp. Welke projecten heeft Studio Stomp voor jullie gedaan? Één van de eerste projecten die wij samen hebben gemaakt was een online vertaal systeem. Het doel van dit project was om digitale producties gemakkelijker te laten verlopen. In onze branche komt het voor dat er bijvoorbeeld een tv commercial wordt gemaakt. Deze commercial wordt gemaakt in het engels, maar dat het ook moet worden vertaald naar vijf andere talen. Het vertalen ging doorgaans via een excel sheet of power points, want klanten hebben daar meestal geen standaarden voor. Toen ben ik met het idee gekomen om een online systeem te maken. Het systeem bestond uit online invul formulieren, voor de vertalingen, die konden worden ingevuld en deze gingen dan automatisch naar de developer. Dit was één van de eerste projecten die ik samen met Studio Stomp heb gedaan. Daarnaast veel nieuwsbrieven, flash banners en promosites. Op dit moment zijn wij bezig met het bedenken en uitwerken voor een app voor de kanaal rondvaartboten in Amsterdam. Hoe test u het product dat Studio Stomp oplevert? Via verschillende manieren. Wij testen het intern, afhankelijk van het target platform, op verschillende machines en browsers. Hierbij houden wij ons eigen excel sheets bij met bugs en andere zaken die ons opvallen. Na het verwerken van de eerste feedback en bugs wordt er een versie gestuurd naar de eindklant. Met de klant maken wij afspraken dat zij groepen hebben van verschillende gebruikers en deze laten wij bepaalde 62

65 handelingen en functies uitvoeren. Dus naast functioneel testen wij ook op usability. Wij proberen van het feedback dat wij terugkrijgen een onderscheid te maken tussen technische bugs, usabillity issues en nonissues. Dit is altijd het lastigste, want als je een klant laat testen komen ze altijd terug met feedback als Het werkt niet. of Ik kan geen tekst copy/pasten, maar in welke situatie dit zich voordoet, waar dit niet kan en op welke platform dat gebeurt is altijd heel erg lastig te achterhalen. Het is voor een klant, die weinig tot geen technische kennis bezit, erg lastig om aan te geven op welke browser ze werken, welke versie van de browser en welke versie van bijvoorbeeld Mac OSX. Dat stuk van het proces is heel moeilijk te formaliseren. Zelfs als je ze een heel gestructureerd vragenlijst en instructies stuurt krijg je nog feedback terug als Het werkt niet als ik op die knop druk, maar wat de context is kom je niet achter. Je gaat dan toch proberen dingen te reproduceren en je in te leven in de gebruiker, maar je komt er dan toch niet achter. Op welke manier levert u testresultaten en feedback aan Studio Stomp? De excel sheets gaan door naar de gene die het project managet bij Studio Stomp. Als een excel sheet niet voldoende is proberen wij het uit te werken in een pdf met screenshots en notities. Dit hangt ook van het probleem af. Sommige problemen moet je zien om te begrijpen wat er aan de hand is. Doen jullie dit op dezelfde manier voor projecten die je niet bij Studio Stomp laat doen? Dit hangt heel erg van het soort product af. Veel dingen die wij maken is geanimeerd werk en dit testen wij dan vooral op kleur en render kwaliteit. Op het moment dat het gaat om de wat complexere zaken. Bijvoorbeeld een project dat wij hebben gedaan voor een nieuwe attractie in een pretpark in Oslo, kan je dat niet goed intern testen. Dan moet je zelf in het vliegtuig stappen, in de karretjes gaan zitten en kijken of alle projecties kloppen en of de beleving is zoals wij bedoeld hebben. Wat wij wel proberen is om de gebruikersbeleving hier te simuleren, maar een exacte test is niet altijd mogelijk. Is het voor u altijd duidelijk wat er met uw feedback wordt gedaan? Soms wel, soms niet. Soms, zeker als je dicht tegen de oplever fase zit, dan zijn er veel dingen die tegelijk lopen. Wat er dan bijvoorbeeld dgebeurt is dat er nog acht 63

66 issues openstaan. We hebben dan een versie getest waarbij een aantal punten zijn opgepakt. Dit wordt doorgestuurd naar de klant en komt dan weer feedback op. Dit sturen wij weer door naar Studio Stomp, die op zijn beurt dan weer aangeeft dat deze punten al opgepakt zijn en geen issues meer zijn. De versies komen dan niet meer overeen. Hierdoor gaat er wel eens feedback verloren of loopt er feedback door elkaar. Hoe vindt u het huidige testproces gaan bij Studio Stomp? Wisselend. Er is zeker ruimte voor verbetering. Er wordt nu een lijst opgesteld met punten die moeten werken. Dit wordt getest en dan zijn er een paar die werken, maar ook een paar niet. Wat je dan eigenlijk wilt is dat bij een volgende versie al deze punten weer mee worden genomen en opnieuw worden getest. Dit gebeurt op dit moment niet. Wat wel een gemis is. Dit zorgt ervoor dat je niet voort kan bouwen op eerdere test resultaten. Van onze kant proberen we dat te structureren, maar het zou makkelijker zijn als Studio Stomp daar een systeem voor had. Studio Stomp geeft meestal een deadline voor het leveren van feedback. Zou je het prettig vinden als dit op een centrale plek wordt bijgehouden, waar je altijd terug kan kijken wanneer er ook alweer een deadline is? Dit gaat altijd via . Dit betekent dat er aan onze kant de project manager de deadline in de agenda zet. Er is op dit moment niet een online systeem hiervoor, waar je bijvoorbeeld automatisch een reminder krijgt met een mededeling dat er een deadline aankomt. Het is op dit moment niet een echt gestructureerde manier van deadlines plannen. Meestal zijn het de project managers die met elkaar overleggen wanneer de deadlines plaatsvinden. Is het voor jullie duidelijk welke issues er tijdens een project openstaan en aan welke Studio Stomp werkt? Dit gaat via verkeer. Dit is ook de rede dat het soms een beetje scheef loopt. Wij houden een lijstje bij met welke issues uitstaan en het komt dan voor dat er bijvoorbeeld acht van de tien issues zijn opgelost en dat er bij de volgende versie de openstaande niet meer op de lijst staan. Die zijn dan gewoon vergeten. Vaak komt dit omdat er dan een versie wordt afgesloten en in die versie zouden alle tien de issues zijn opgelost, maar dit is dan niet altijd het geval. 64

67 Dit kan irritatie opwekken bij de klant, omdat die bijvoorbeeld twee maanden geleden het probleem al hebben aangegeven. Dit is doorgegeven aan Studio Stomp en dan een maand later en twee versies verder is dit probleem nog niet opgelost. Dit komt voornamelijk door het verkeer, mensen die langs elkaar heen werken en het niet inzichtelijk genoeg maken van de issues voor iedereen. Als Studio Stomp een applicatie ontwikkelt waarin het gemakkelijk is een product te bekijken en daar feedback op te leveren, zou je dit dan overwegen om te gebruiken? Ja zeker. Dit zou bijvoorbeeld voor het meest recentelijk project wat wij samen met Studio Stomp hebben gemaakt voor Syngenta zeker een oplossing zijn geweest. Want dan heb je een online omgeving waar je je versies en feedback kan bijhouden. Dit zou helemaal ideaal zijn als het feedback wat wordt geleverd gekoppeld kan worden aan een echt issue tracking systeem. Waarbij het mogelijk is om feedback om te zetten naar echte issues mocht dat nodig zijn. Interview Dennis Maij (We Are Bold) Bedankt dat je tijd wilt vrij nemen om een interview met mij te houden. Zou je jezelf kunnen voorstellen? Ik ben Dennis Maij en ben eigenaar van We Are Bold. We Are Bold is een web ontwikkel bureau en wij doen alles op het gebied van web. Concept, design, development en advies. Hoe zijn jullie in aanraking gekomen met Studio Stomp? Voordat ik met We Are Bold begon hadden mijn broer Steven en ik een bedrijf dat hete Tera Preta. Dat zat tegenover Studio Stomp in hetzelfde gebouw. Wij kwamen geregeld bij elkaar binnen als één van ons een klusje had voor elkaar. Verder heeft mijn broer regelmatig technische ondersteuning geboden bij projecten van Studio Stomp. Welke projecten heeft Studio Stomp voor jullie gedaan? Wij hebben een tijdje terug een redelijk groot project begeleid bij Studio Stomp waar een externe developer uit de Filipijnen bij betrokken was. Verder hebben wij ook mee geholpen met het opzetten van de Studio Stomp website en hebben wij nog wat 65

68 kleinere klusjes als banners etc uitgewisseld. Hoe leveren jullie projecten op aan een klant? Dat verschilt per project. Bij kleinere projecten developen wij direct op de server waar de website op gaat draaien, op het moment dat er een versie klaar is die voor acceptatie naar de klant moet delen wij de link met ze. Met grotere projecten developen wij op drie verschillende locaties. De eerste is onze localhost, waar alleen wij toegang tot hebben. Daarnaast hebben wij een testserver staan waar steeds afgeronde versies op komen en bekeken moeten worden door de klant. Als alles goed is komt het op de server en voeren wij nog wat kleine aanpassingen door. Op welke manier levert de klant feedback terug aan jullie? Dat verschilt per project. Soms komt de klant persoonlijk langs en gaan we door de website heen. Daaruit rollen dan een aantal punten welke nog opgepakt moeten worden. Bij andere projecten waar het niet mogelijk is om fysiek af te spreken krijgen wij meestal een excel sheet terug. Je geeft aan dat je soms een Excel sheet terug krijgt, is dit ideaal? Nee eigenlijk niet. Het is soms moeilijk te achterhalen wat de klant bedoelt. Zeker met klanten die niet technische kennis hebben is dit lastig. Het is dan lastig te achterhalen waar de problemen zich voordoen, bijvoorbeeld op welke browser. Verder mis je ook visueel feedback. Je probeert dan uit te leggen hoe ze dit kunnen achterhalen, maar dit is verre van ideaal en kost alleen maar tijd. Hoe test u zelf het gemaakte product? Dit doen we aan de hand van bepaalde user scenario s. We schrijven een aantal handelingen uit die een gebruiker moet kunnen uitvoeren en proberen dit uit te voeren. Onderweg proberen wij ons product zo veel mogelijk te slopen zoals we dat noemen. Hier proberen we er achter te komen of alles echt werkt zoals het zou moeten en of er geen fouten op treden. Zijn dit soort tests ideaal? Haal je alle fouten eruit? Eigenlijk zou je je product moeten laten testen door gebruikers die het product nog helemaal niet kennen. Als developer zit je een x aantal maanden in een project en weet je precies wat de website moet doen. Zo weet je al waar je alles kan vinden en kan je dus niet goed testen op usabillity. 66

69 Gebruiken jullie een soort van issue tracking systeem om alle feedback te archiveren en heeft de klant hier ook inzicht in? Ja wij gebruiken BamBam als issue tracking systeem. Het ligt per project eraan of de klant hier inzicht in heeft. Bij kleinere projecten zeker niet. Dan communiceren we meestal gewoon face to face. Bij grote projecten heeft de klant eigenlijk altijd toegang tot de openstaande issues. Als Studio Stomp een applicatie ontwikkelt waarin het gemakkelijk is een product te bekijken en daar feedback op te leveren, zou je dit dan overwegen om te gebruiken? Dat zou ik dan eerst een keer willen uit proberen. Een soort beta test ermee houden en als het me bevalt waarom niet? Interview Bas van Brokhorst (GreenBerry) Bedankt dat je tijd wilt vrij nemen om een interview met mij te houden. Zou je jezelf kunnen voorstellen? Ik ben Bas van Bokhorst. Ik heb sinds 2008 een online communicatie bureau genaamd GreenBerry. We maken veel online producten voor diverse klanten. Het geen wat we maken is gericht op inzichten en feiten. We maken geen werk wat er alleen leuk uitziet, maar niet gebaseerd is op valide data en dergelijke. Ons bedrijf bestaat nu uit ongeveer 14 mensen en zijn gelegen in Utrecht. Verder werken we veel samen met partijen als Studio Stomp voor digitale realisatie. Hoe zijn jullie in aanraking gekomen met Studio Stomp? Ik ben benaderd door Benjamin. Hij had ons ontdekt via een reclame prijs die wij hadden gewonnen en niet zo heel lang geleden hebben wij ons eerste project gedaan. Welke projecten heeft Studio Stomp voor jullie gedaan? Wij hebben nu twee projecten gedaan en we zijn nu aan het oriënteren voor een derde project. Het eerste project dat we hebben gedaan was voor Teva. Een campagne waar een aantal retailers worden aangesloten en via een win systeem een reis naar de Grand Canyon kunnen winnen. Verder hebben wij onze eigen website bij Studio Stomp ondergebracht en die hopen wij eerdaags live te kunnen zetten. Hoe test u het product dat Studio Stomp oplevert? Dit gaat via drie stappen. Ik ga als eerst er naar kijken, ik ben eind verantwoordelijke 67

70 voor de kwaliteit. Dan kijk ik naar de kwaliteit en of alle functionaliteiten erin zitten. Ik stel dan een lijst op met verschillende categorieën. Bugs, features, etc. en aan deze lijst hang ik dan prioriteiten. Deze lijst zet ik in onze project managementtool genaamd Basecamp. Vervolgens stuur ik dit door naar de project manager aan de kant van Studio Stomp. We orgineseren wekelijks meetings om deze lijsten door te nemen en een planning te maken om deze punten op te pakken. Vervolgens gaan we elke issue weer los testen of het is opgelost zodra Studio Stomp dat aangeeft. Naast dat ik er als technicus naar kijk, kijkt er voor de rest een designer naar. Die kijkt echt of alles eruit ziet zo als het is bedoeld. Ook kijkt er nog een interaction designer na om te kijken of de flow van de website klopt. Een design is vaak statisch en je kan nog aangeven hoe je iets wilt hebben, je merkt pas dat het werkt als je het echt interactief voor je ziet. Daarom is het ook belangrijk om te testen. Wij willen graag een product op de markt zetten die aansluit bij de doelgroep en veel wordt gebruikt. Zodra er niet goed wordt getest kunnen wij de plank mis slaan. Doen jullie dit op dezelfde manier voor projecten die je niet bij Studio Stomp laat doen? Ja andere projecten verwerken wij eigenlijk op dezelfde manier. Het verschil is wel dat elk bedrijf andere tools hebben om issues te noteren. Wij werken met Basecamp en andere bijvoorbeeld met Jira of iets anders. Is het voor u altijd duidelijk wat er met uw feedback wordt gedaan? Niet altijd. Dit hangt er van af wie er bij betrokken is. Sommige developers zijn er goed in het bijhouden van hun takenlijst en het aangeven van bepaalde keuzes en sommige doen dat eigenlijk niet. Daarom is het belangrijk om veelvuldig contact te houden om zo te achterhalen of alles opgelost is of wordt. Maar over het algemeen geeft Studio Stomp goed aan wat er met de feedback is gedaan en wanneer het is opgelost. Studio Stomp geeft meestal een deadline voor het leveren van feedback. Is dit voor u altijd duidelijk wanneer dit is? Dit is voor mij wel duidelijk. Er wordt helder gecommuniceerd wanneer er een deadline is. Er is wel een aspect wat deadlines moeilijk maakt. 68

71 Verborgen feedback noem ik dat. Stel Studio Stomp meld aan ons dat ze nog een ontwerp missen voor een pagina, wij leveren dat aan en al heel snel daarna is een deadline om te testen. Dan is de pagina die is aangeleverd nog niet voldoende getest door Studio Stomp en komen er zo nog een paar kleine puntjes naar voren. Deze overlappen dan als ware de deadlines. Dit wisselt wel eens. Sommige klanten zijn niet gewend om met online tools te werken. Die schakelen dan over op Word of Excel. Dit is behoorlijk tijdrovend. Je moet elke issue één voor één uit het document halen en in ons systeem zetten. Daarom geven wij vaak de klant toegang tot onze Basecamp en leggen wij ze uit hoe ze daar hun feedback kunnen plaatsen. Als jullie zelf een product maken voor een klant, hoe leveren jullie dan jullie product op en op welke manier krijgen jullie feedback? Wij gebruiken altijd stagingservers en proberen onze producten in versies op te leveren. We willen niet onze klant toegang geven tot onze ontwikkelomgeving. Dit leidt namelijk vaak voor verwarring want dan kan het zomaar zijn dat wij bezig zijn met het ontwikkelen van een functie waardoor de website het even niet doet. Als de klant dan gaat kijken raakt die in paniek, dit tegenover het op een stagingserver zetten waarbij wij een versie uploaden. Daar geven wij duidelijk aan welke zaken wel werken en welke niet. Zo komt de klant niet voor verrassingen te staan. Gaat het feedback dat jullie krijgen van de klant ook via Basecamp, of gebruiken jullie hier bijvoorbeeld Excel sheets voor? 69

72 B. Testresultaten Paper prototype testresultaten Uitlijning is niet helemaal lekker op test overview pagina Tooltip zou je opnieuw op willen kunnen vragen Ik zou graag recente projecten willen zien op het dashboard Is recente activiteiten wel het belangrijkste om te zien op het dashboard? Duidelijk indeling Projecten bij Studio Stomp zijn eigenlijk nooit afgesloten Oranje kleur niet nodig, test is of open of afgesloten Voelt al aan als een webapplicatie Testresultaten Studio Stomp Je zou een preloader willen zien op het moment dat de applicatie data aan het ophalen is, maar de applicatie werkt nu snel dus misschien niet nodig Iconen van ical, Outlook en Gmail zijn hetzelfde? Recente activiteiten wordt afgekapt op één regel bij kleinere schermformaten Mooi modern design, geeft je het gevoel dat je een echte applicatie gebruikt. Feedback overlay sluit niet lekker Handige tooltips Testresultaten Avinash Changa (DSRPT, We Make VR) Overzichtelijke pagina met de belangrijkste informatie direct tot je beschikking Goed dat alle informatie relevant is voor de gebruiker die is ingelogd Duidelijk onderscheid tussen verschillende elementen en navigatie Aangeven van klant naam bij elk project misschien een beetje overbodig aangezien dat ook al groot er boven staat, maar kan me voorstellen dat als je meer projecten hebt dat het wel handig is. Elke versie dezelfde afbeelding? Waarom staat er bovenaan development fase? Ik snapte niet direct dat je een selectie moest maken om feedback te plaatsen De statistieken zijn handig om een snel beeld te krijgen. Kunnen twee feedback bolletjes elkaar overlappen? 70

73 Testresultaten Dennis Maij (We Are Bold) Ik zou graag een logboek willen zien van de punten die zijn opgepakt bij de nieuwe versies Een searchbox op de projecten pagina zou handig kunnen zijn Mooi strak design Misschien is het een idee om een soort van IOS achte notificatie bolletjes te plaatsen bij projecten waar nieuwe feedback is geplaatst De tablet en mobile view zouden meer context kunnen hebben als er een afbeelding van een tablet of telefoon om de iframe wordt geplaatst Deze applicatie heeft wel toekomst Waarom gebeurt er niks als ik op nieuwe feedback druk? Dropdown zou ook weg geklikt moeten worden als je er naast klikt Feedback zou afgevinkt moeten kunnen worden als het is opgepakt 71

74 C. Testplan TESTPLAN OMDENKEN URL INLOG WW stomp dvstdstmp Omdenken is de website voor het bedrijf Ja Maar, waarop verschillende verhalen staan om hun theorie Omdenken aan te toetsen. Op de volgende bladzijdes moet alle functionaliteit getest worden op alle pagina s van de website. HOMEPAGINA Functie Opmerkingen In het menu zijn de volgende items opgenomen: Start, Meedenken, Nieuws en Theorie. Klopt? Ga je vanaf daar naar deze betreffende pagina s toe? Omdenken logo is clickable en gaat naar homepagina? Deel een verhaal knop gaat naar deze pagina? Zoekbalk werkt en gaat naar de zoek resultaten pagina? Laatste Tweet van Omdenken wordt getoond onder de zwarte lijn? Bij filter recent (default aan) worden de posts op datum gesorteerd. Klopt dit? Bij filter Populair worden de posts op basis van aantal stemmen gesorteerd. Klopt dit? Bij filter Uitgelicht worden de posts op basis van uitgelicht (kan ik backend worden aangegeven) getoond. Klopt dit? Er zijn drie soorten posts: video posts, Meedenkers en normale. Deze onderscheiden zich qua design. Klopt dit? Elke post bestaat uit een afbeelding, titel, auteur, datum, stukje tekst, tags en mogelijkheid 72

75 tot stemmen en link naar comments. Klopt dit? (stemmen kan 1 keer per verhaal) (mobiel geen tekst en auteur) Linken alle posts naar een verdiepende pagina? Linken de tags door naar een overzichtspagina waarin die tag staat uitgelicht? Werkt de Laad meer link onderaan? Footer: werkt knop Deel een verhaal? Footer: werkt de link e- mail? Footer: werken de links naar de overige websites? Footer: klik op knop toevoegen (nieuwsbrief) zonder je e- mailadres in te voeren. Krijg je validatie te zien? Footer: schrijf je in voor de nieuwsbrief. Werkt dit? (nu nog niet functioneel) Footer: werken de links naar Facebook en Twitter? Algemeen: schaalt de pagina goed mee? Overige opmerkingen? PAGINA VERHAAL (klik hiervoor op een van de verhalen op de homepagina) Functie Opmerkingen Een post kan uit meerdere elementen bestaan. In ieder geval een titel en tekst. Klopt dit? Zijn de tags onder een verhaal clickable? Kun je op een verhaal stemmen? (1 keer per ip adres) Kun je een comment schrijven bij het verhaal? Zie je de validatie verschijnen als je geen verhaal hebt getypt? (rest is niet verplicht) Mochten er reacties van andere mensen zijn, 73

76 kun je op die specifieke reactie een comment schrijven? Kun je op comments stemmen? (1 keer per ip) De comments van Admin (Omdenken) zijn rood. Zie je die terug? Kun je naar het vorige/volgende verhaal? Zie je de gerelateerde artikelen en kun je hierop klikken? Overige opmerkingen? PAGINA MEEDENKEN Functie Opmerkingen Er zijn twee soorten meedenkers: Lopend en Afgesloten. Klopt dit? (titel geeft aan of een meedenker is afgelopen) De overige functionaliteit werkt hetzelfde als op de homepagina. Mochten hier nog opmerkingen over zijn dan kun je die hier noteren PAGINA NIEUWS Functie Opmerkingen Nieuws zijn posts die als dusdanig aangegeven zijn in de backend. De overige functionaliteit werkt hetzelfde als op de homepagina. Mochten hier nog opmerkingen over zijn dan kun je die hier noteren PAGINA THEORIE Functie Opmerkingen 74

77 Deze pagina bestaat uit enkel tekst. Overige opmerkingen kunnen hier genoteerd worden: PAGINA DEEL EEN VERHAAL Functie Opmerkingen Voor het invullen van een verhaal zijn alle velden verplicht. Zie je validatie op het moment dat je de velden niet voorziet van informatie? Krijg je een succesmelding te zien op het moment dat je een verhaal verzonden hebt? Overige opmerkingen: ZOEKRESULTATEN PAGINA Vul voor de test in de zoekbalk het woord: mee in. Wordt je doorverwezen naar een pagina waarin posts staan met daarin het woord Mee? Nog geen post is gekoppeld aan een strategie. Kun je wel zien dat het werkt? Filter de berichten bijvoorbeeld op de tag Pesten. Werkt dit? Kun je geselecteerde tags ook weer deselecteren? Kun je de geselecteerde berichten sorteren op periode? De overige functionaliteit werkt hetzelfde als op de homepagina. Mochten hier nog opmerkingen over zijn dan kun je die hier noteren Overige opmerkingen: 75

78 D. Wireflow Wireflow test- en feedbackapplicatie PASSWORD RESET LOGIN 1 TEST OVERVIEW BY PROJECT 4 AGENDA 5 MENU DASHBOARD 2 TESTS 4.1 DASHBOARD 6 PROJECTEN TESTS PROFIEL PROJECT OVERVIEW 3 CHECKLIST TEST USER SCENARIO TEST WEBSITE PLACEHOLDER WEBSITE PLACEHOLDER PROJECT DETAIL TEST RESULTS v4 v3 v2 6 v2 v1 HEADER VERSIE LIVE VERSIE FEEDBACK Project Titel Live Feedback WEBSITE PLACEHOLDER SIDEPANEL FEEDBACK BOX Opties Toon feedback Aan Plaats feedback Verander weergave Tim Goosens Versie april

79 E. Scherm ontwerpen Dashboard Project pagina 77

80 Project detail pagina Bekijk project 78

81 Plaats feedback Verander weergaven 79

82 Project feedback pagina blokken 80

83 Project feedback pagina lijst Feedback overlay 81

84 Test pagina Test overzicht pagina 82

85 Checklist test User scenario test 83

86 Checklist uitslag User scenario uitslag 84

87 Checklist overzicht User scenario overzicht 85

88 Agenda Profiel 86