UX-‐research en Scrum: een huwelijk of latrelatie?
Een empirisch onderzoek naar de integratie van UX-‐research en Scrum ontwikkeltrajecten bij Sanoma 20 januari, 2015 Universiteit Utrecht Master Communicatie en Organisatie TMLV13013 Interventieonderzoek Student: Lenneke van der Meijden Studentnummer: 3912663 E-‐mail: [email protected] 06 509 23 501 Sanoma Digital Stagebegeleider: Nicol Nijland E-‐mail: [email protected] Universiteit Utrecht Stagedocent: prof. Dr. L.R. Lentz E-‐mail: [email protected] 030 253 8115
2
Inhoudsopgave Samenvatting ......................................................................................................... 4
1. Inleiding .............................................................................................................. 6 1.1 Context ............................................................................................................................... 6 1.2 Probleemstelling ................................................................................................................. 6 1.3 Doelstelling en werkwijze onderzoek ................................................................................. 7
2. User experience research versus Scrum .............................................................. 8 2.1 Kenmerken User experience research ................................................................................ 8 2.2 Agile software ontwikkeling ............................................................................................... 9 2.2.1 Kenmerken Scrum ............................................................................................................ 9 2.3 UX-‐research in combinatie met Scrum ............................................................................. 10
2.3.1 Belang van integratie tussen UX-‐research en Scrum ................................................. 10 2.3.2 Kloven en uitdagingen bij de integratie van UX-‐research en Scrum .......................... 11
2.4 Onderzoeksvragen ............................................................................................................ 12
3. Methode ........................................................................................................... 13 3.1 Participerende observatie ................................................................................................ 13
3.1.1 Onderzoekscasus: Kieskeurig.nl ................................................................................. 13 3.1.2 Focus van de observatie: procesoptimalisatie ........................................................... 14
3.2 Dataverzameling ............................................................................................................... 14 3.2.1 Operationaliseringsschema ....................................................................................... 14
3.3 De rol van de onderzoeker ............................................................................................... 16 3.4 Data-‐analyse ..................................................................................................................... 16
4. Resultaten ........................................................................................................ 18 4.1 Werkprocessen ................................................................................................................. 18
4.1.1 Het werkproces van het UX-‐research team bij Kieskeurig ......................................... 18 4.1.2 Het Scrumproces van Kieskeurig ................................................................................ 19 4.1.3 Verwerking van resultaten in de sprints van Kieskeurig ............................................ 19
4.2 De rolverdeling ................................................................................................................. 20 4.2.1 De rol van de UX-‐researcher binnen het Scrumteam van Kieskeurig ......................... 20 4.2.2 Moment waarop de UX-‐researcher is aangehaakt door Kieskeurig .......................... 20 4.2.3 Mate van betrokkenheid tussen de UX-‐researcher en het Scrumteam van Kieskeurig ........................................................................................................................... 20
4.3 Inzet van UX-‐methoden/tools binnen Kieskeurig ............................................................. 21 4.3.1 Zijn de beschikbare UX-‐methoden/tools van Sanoma agile? .................................... 21 4.3.2 UX-‐methoden/tools bij Kieskeurig ............................................................................. 23 4.3.3 Toegevoegde waarde van de UX-‐methoden/tools bij Kieskeurig .............................. 24
3
5. Conclusie en discussie ....................................................................................... 27 5.1 Werkprocessen ................................................................................................................. 27
5.1.1 Integratie werkprocessen door iteratief testen ......................................................... 27 5.1.2 Integratie werkprocessen vereist geen parallelle (1-‐op-‐1) iteraties .......................... 28
5.2 De rolverdeling ................................................................................................................. 29 5.2.1 Een dedicated UX-‐researcher binnen het Scrumteam is niet nodig ........................... 29 5.2.2 UX-‐researcher gedurende het gehele ontwikkeltraject aanhaken ............................ 29 5.2.3 Hoge betrokkenheid van het Scrumteam bij UX-‐research is belangrijk ..................... 30
5.3 UX-‐methoden/tools .......................................................................................................... 30 5.3.1 Agile UX-‐methoden/tools geen vereiste, kwaliteit wel .............................................. 30 5.3.2 Alternatieve UX-‐methoden/tools die agile en kwaliteit verenigen ............................ 31
5.4 UX-‐research integreren binnen Scrum ............................................................................. 32 5.5 Terugblik uitvoering onderzoek ........................................................................................ 34 5.6 Vervolgonderzoek ............................................................................................................. 34
Literatuurlijst ........................................................................................................ 35 BIJLAGEN
4
Samenvatting Binnen het mediabedrijf Sanoma is er een team aangesteld met User experience researchers (UX-‐researchers) die met behulp van verschillende tools usability onderzoek uitvoeren om de gebruikerservaring van producten (websites, games, apps) te meten. Het UX-‐research team voert onderzoek uit voor alle websites uit het portfolio van Sanoma en heeft steeds vaker te maken met de werkmethode Scrum. Dit is een vorm van agile (‘vlug’) werken waarbij een multidisciplinair team in korte sprints (iteraties) naar een werkende website werkt. De werkmethode van het UX-‐research team komt niet overeen met de werkmethode Scrum die door veel teams achter de websites gehanteerd wordt. Het UX-‐research team heeft daarom de wens om UX-‐research te integreren binnen de Scrum ontwikkeltrajecten. Om te onderzoeken hoe en of dit mogelijk is, is de volgende hoofdvraag opgesteld: Wat zijn de belemmerende en bevorderende factoren voor de integratie van UX-‐research en Scrum binnen Sanoma? Met behulp van de onderzoeksmethode participerende observatie is gezocht naar een antwoord op dit vraagstuk, waarbij is ingezoomd op de casus van de vergelijkingssite Kieskeurig.nl. Andere casussen uit het portfolio van Sanoma zijn geobserveerd ter vergelijking. Voor het observeren en analyseren van de data is een onderscheid gemaakt tussen drie thema’s die zijn opgesteld op basis van de belangrijkste verschillen tussen UX-‐research en Scrum (Rannikko, 2011): werkprocessen, rolverdeling en werkzaamheden/UX-‐methoden. Binnen Sanoma kan UX-‐research het beste geïntegreerd worden binnen een Scrum ontwikkeltraject. Dit betekent dat Scrumteams hun huidige werkmethode minimaal hoeven te veranderen (Blomkvist, 2005). Om UX-‐research en Scrum succesvol te integreren zijn op basis van het onderzoek een richtlijn en adviezen opgesteld om van de belemmerende factoren, bevorderende factoren te maken. Deze richtlijn en adviezen zijn onderverdeeld in de drie eerder genoemde thema’s.
• Werkproces: De werkprocessen van het UX-‐research team en het Scrumteam komen niet met elkaar overeen. Om de werkprocessen met elkaar te integreren moet er iteratief getest worden. Hierbij is het belangrijk dat het proces van het ontwerpen van de website, of de functionaliteiten ervan, door UX-‐designers en het testen van het ontwerp door UX-‐researchers een sprint voorloopt op het proces van de technisch developers. Verder is het belangrijk dat het Scrumteam tijd vrijmaakt in de planning om de resultaten te verwerken.
• Rol UX-‐researcher: Het dedicated aanstellen van een UX-‐researcher blijkt niet noodzakelijk, maar het is wel belangrijk dat de UX-‐researcher geïnformeerd wordt over het proces en de stand van zaken met betrekking tot de ontwikkeling van het product. Door de rol van de UX-‐researcher gedeeltelijk dedicated te maken, wordt hieraan tegemoet gekomen. Verder zal het UX-‐research team tegemoet moeten komen aan de tijdsplanning van het agile ontwikkelproces en daarom al in een zo vroeg mogelijk productstadium betrokken moeten worden in het ontwikkelproces. Om ervoor te zorgen dat resultaten uit de onderzoeken prioriteit krijgen en daardoor sneller opgepakt worden, moet de betrokkenheid van het Scrumteam en
5
management hoog zijn. Tijdens elk usability interview zou er naast de conversiemanager en product-‐eigenaar, minimaal één persoon uit het development team, een UX-‐designer en iemand uit het management aanwezig moeten zijn, zodat ze zich eigenaar gaan voelen van de usability interviews en een hogere prioriteit geven aan de gevonden knelputen.
• UX-‐methoden/tools: Agile UX-‐methoden/tools zijn geen vereiste, maar de kwaliteit van de onderzoeken wel. Voor het uitvoeren van UX-‐research binnen een Scrumproces krijgt kwaliteit de voorkeur boven snelheid. Is snelheid vanuit de stakeholder gewenst, dan kan een UX-‐researcher alternatieve UX-‐methoden/tools die agile en kwaliteit verenigingen inzetten zoals RITE + Krug methode, discount usability engineering en guerilly usability testing.
De adviezen zijn generaliseerbaar voor vergelijkbare websites zoals Kieskeurig.nl. Dit zijn websites die net als Kieskeurig onderhevig zijn aan veel veranderingen, waarbij dagelijks nieuwe content wordt toegevoegd en na elke sprint nieuwe features worden gelanceerd.
6
1. Inleiding
1.1 Context Het doel van de vergelijkingswebsite Kieskeurig is om gebruikers verschillende producten en prijzen met elkaar te laten vergelijken. De website moet daarom in ieder geval voldoende producten bevatten, die ook vindbaar zijn, en de site moet een functie bevatten waarmee de producten met elkaar vergeleken kunnen worden. Kieskeurig heeft zo’n vergelijkingsfunctie. Deze functie werkt ook, maar wordt niet door gebruikers gebruikt omdat de functie niet opgemerkt wordt. Het gevolg is een verhoogde kans dat gebruikers afhaken. Het voorbeeld van Kieskeurig laat een kloof zien in de interactie tussen het ontwerp van de website en de gebruikers. Een ontwerper kent en begrijpt de website, app, intranet of game (hierna te noemen ‘product’), maar een gebruiker heeft deze kennis niet. Bij het (door)ontwikkelen van een product is het daarom belangrijk om te onderzoeken hoe de usability scoort. Usability overbrugt de gap tussen de ontwerpers en de gebruikers (Nielsen, 2008a). Hoe groter de kloof tussen de doelen van de ontwerper en de gebruikers en de context waarin de ontwerper en de gebruiker het product moeten gebruiken, hoe belangrijker usability onderzoek om de informatie en het ontwerp van het product te optimaliseren zodat het aansluit bij de gebruiker (Nielsen, 2008a). Usability is nuttig voor de ontwikkeling of optimalisatie van een product. Het belang van usability zit in een aantal aspecten. Allereerst zorgt usability onderzoek ervoor dat een product zo goed mogelijk inspeelt op de gebruikersbehoeften (Nielsen, 2008a). Als men vindt wat men zoekt, haakt men minder snel af en creëert men een hogere conversie. Ten tweede keert een gebruiker sneller terug naar een website als deze voldoet aan de gebruikersbehoeften. Het wekt loyaliteit, maar ook vertrouwen. Een website die werkt naar verwachting van een gebruiker geeft een veilig gevoel en daarmee vertrouwen (Nielsen, 1994). Een derde aspect dat het belang van usability aanduidt, is dat het kosten bespaart in de ontwerpfase van het product (Kujala, 2002). Het uitvoeren van een usability onderzoek in de ontwerpfase zorgt ervoor dat er in een vroeg stadium al nagedacht wordt over de gebruikersbehoeften, zodat het product aansluit op deze behoeften. Onderzoek in een later stadium kan leiden tot grote aanpassingen van het product met als gevolg een stijging van de kosten. Aanpassingen verwerken in een product dat al zo goed als af is, kost meer tijd en capaciteit dan in een prototype van een product. In een later stadium is usability onderzoek nuttig om het product te optimaliseren (Kujala, 2002).
1.2 Probleemstelling Binnen het mediabedrijf Sanoma is er een team aangesteld met User experience researchers (UX-‐researchers) die met behulp van verschillende tools usability onderzoek uitvoeren om de gebruikerservaring van producten te meten. Het initiatief voor het uitvoeren van een usability onderzoek komt zowel vanuit de eigenaren van websites (product-‐eigenaren) of conversiemanagers, als vanuit het UX-‐research team. Het UX-‐research team voert onderzoek uit voor alle websites uit het portfolio van Sanoma en heeft daardoor te maken met de werkmethoden die door de teams achter de websites gehanteerd worden. Die methoden kunnen verschillen met de werkmethode van het UX-‐research team. Een werkmethode die binnen de wereld van software-‐ontwikkeling aan populariteit gewonnen heeft en die binnen Sanoma ook veel gehanteerd wordt, is Scrum. Scrum is een vorm van
7
agile (‘vlug’) werken waarbij een multidisciplinair team in korte sprints (iteraties) naar een werkende website werkt. Deze methode vergroot de flexibiliteit en snelheid gedurende de (door)ontwikkeling van een product (Van Solingen en Rustenburg, 2010). De UX-‐researchers uit het UX-‐research team van Sanoma hebben echter geen vaste rol (dedicated) binnen de Scrumteams waardoor er een kloof tussen de werkmethode van het UX-‐research team en de Scrumteams van verschillende websites is. Het uitvoeren van gedegen usability onderzoek in het algemeen, en in de huidige werkwijze van het UX-‐research team, vergt relatief veel tijd en onderzoek moet (meestal) tijdig ingepland worden. Het Scrumteam werkt daarentegen in verhouding ‘sneller’ en heeft meer ruimte voor flexibiliteit in haar planning. Ondanks de welwillendheid van het UX-‐research team is het daarom niet altijd mogelijk om ad hoc opdrachten aan te nemen. Dit heeft als gevolg dat een product-‐eigenaar regelmatig usability onderzoek buiten beschouwing laat. Vanuit de business is snelheid en tegelijkertijd kwaliteit vaak belangrijk en dat lijkt voor het uitvoeren van usability onderzoek een uitdagende combinatie.
1.3 Doelstelling en werkwijze onderzoek Vanuit het UX-‐research team ligt het verzoek om na te gaan of het mogelijk is om binnen de korte ontwikkelprocessen van Scrum, usability onderzoek in te zetten op een manier die enerzijds snel resultaat en kwaliteit opleveren voor product-‐eigenaren en anderzijds zinvol en praktisch uitvoerbaar zijn voor het UX-‐research team. Oftewel: het dichten van de kloof tussen de snelheid van Scrum en de ‘traagheid’ waarmee usability onderzoek door het UX-‐research team wordt uitgevoerd. Gezien de kwalitatieve aard van het vraagstuk wordt er met behulp van de onderzoeksmethode participerende observatie gezocht naar een antwoord op dit vraagstuk. Om een goed beeld te krijgen van de huidige werkprocessen, de rol van de UX-‐researcher en de UX-‐methoden/tools, wordt er vanuit de participerende observatie ingezoomd op de casus van de vergelijkingssite Kieskeurig. Andere casussen worden geobserveerd ter vergelijking.
8
2. User experience research versus Scrum Om een helder kader te schetsen van dit onderzoek, wordt er in dit hoofdstuk dieper ingegaan op wat kenmerkend is voor User experience research (UX-‐research), agile software ontwikkeling en Scrum. Hieruit volgen de belangrijkste verschillen tussen UX-‐research en het Scrumproces en de uitdagingen om beide met elkaar te integreren.
2.1 Kenmerken User experience research Usability, User-‐Centered Design (UCD) en User experience (UX) zijn verschillende termen die allemaal de gebruiker centraal stellen tijdens de ontwikkeling of evaluatie van een product. Deze termen samen vormen de term User experience research (UX-‐research).
• De term usability is ontstaan als vervanger voor de term ‘gebruiksvriendelijk’, omdat deze te vaag en teveel subjectiviteit zou bevatten (Bevan et al., 1991). Volgens Nielsen (2012) moet usability als een kwaliteitseigenschap gezien worden die de ease of use en usefulness van een product meet. De term is gedefinieerd in vijf componenten, namelijk het gemak om het product te gebruiken, efficiëntie, foutmeldingen, de mate waarin een gebruiker bij terugkeer bij het product nog steeds weet hoe het werkt en tevredenheid over het gebruik (Nielsen, 2012). Usability richt zich op één onderdeel binnen het ontwikkeltraject van een product, namelijk de ontwerpfase (Van Gemert-‐Pijnen et al., 2011).
• Met de term User-‐centered Design wordt het creëren, of eigenlijk het proces, van een effectieve user experience aangeduid waarbij de focus op de gebruiker is gericht. Het concept van UCD is simpel: betrek de gebruiker bij het gehele ontwikkelproces van het product (Garrett, 2011).
• User experience (UX) is een breder concept dan usability en UCD (Nielsen en Norman, 2012). Het draait bij UX om voldoen aan de wensen en verwachtingen van de gebruiker en de totale gebruikerservaring waarbij de service bestaande uit verschillende disciplines zoals marketing, engineering, grafische en industriële design en het interface design op elkaar ingespeeld moeten zijn (Nielsen en Norman, 2012). Net zoals bij UCD, is de focus ook bij UX gericht op de gebruiker tijdens het hele ontwikkeltraject, maar is er meer betrokkenheid tussen de ontwerpers en de onderzoekers.
Het werkproces van UX-‐research UX-‐research staat bekend om een methode die relatief veel tijd kost. De reden hiervoor is dat er gedurende het gehele ontwikkeltraject van een product meerdere onderzoeken met eindgebruikers moeten worden uitgevoerd (Rannikko, 2011; Salah et al., 2014). Rol UX-‐researcher Een UX-‐researcher houdt zich in het algemeen bezig met het uitvoeren van observaties, surveys (kwalitatief en kwantitatief), usability interviews en andere explorerende en evaluerende onderzoekstechnieken. Het doel van een UX-‐researcher is het observeren, analyseren, categoriseren en documenteren van werkmethoden en –processen en van het gedrag, de voorkeuren en de attitude van eindgebruikers van een product (Garrett, 2011).
9
UX-‐methoden/tools Welke UX-‐methoden/tool geschikt is, hangt af van het ontwikkeltraject van een product en het productstadium. Het ontwikkeltraject van een product bestaat uit vijf fasen (Van Gemert-‐Pijnen et al., 2011, p.9).
1. Contextual inquiry: verzamelen van informatie over de omgeving van het product en een analyse van de stakeholders;
2. Value specification: wat is er nodig om aan de behoeften van de stakeholder te voldoen om kwaliteit van het product te creëren?
3. Design: ontwerpen van het product; 4. Operationalization: implementeren van het product; 5. Summative evaluation: evaluatie van het gebruik van het product.
Daarnaast worden er vijf stadia onderscheiden waarin het product zich kan bevinden (Treder, 2012; Martin en Hanington, 2012):
• Wireframe (afbeelding van geraamte product) • Mockup (screenshot van pagina van product) • Prototype (klikbaar product) • Werkende website in testomgeving • Werkende website in liveomgeving
2.2 Agile software ontwikkeling Agile software ontwikkeling is een methode om software te ontwikkelen die zich, in vergelijking met programmeren, richt op onderwerpen als projectmanagement en samenwerking (uxpamagazine, 2014). De term agile verwijst naar het aantal verschillende iteratieve en incrementele software-‐ontwikkelmethoden die dezelfde principes delen (Shore en Warden, 2008 in Rannikko, 2011). De meest belangrijke en bekende agile methoden zijn Scrum en Extreme Programming (XP). Andere methoden zijn Adaptive Software Development (ASD), Agile Unified Process, Crystal Clear, Dynamic Solutions Delivery Model (DSDM), Feature Driven Development (FDD) en Lean Software Development (Sliger en Broderick, 2008 in Rannikko, 2011). In dit onderzoek ligt de focus op Scrum, omdat deze methode het meest wordt toegepast binnen Sanoma. De andere methoden worden niet verder besproken.
2.2.1 Kenmerken Scrum Scrum, bedacht door Jeff Sutherland en Ken Schwaber, is een projectmanagementmethode die vijf belangrijke aspecten onderscheid, namelijk: commitment, focus, openheid, respect en moed (Larman, 2003). Het werkproces Scrum Kenmerkend voor een Scrumproces zijn de iteratieve en incrementele ontwikkeling en de adaptieve planning (Larman, 2003). De cyclus van een Scrumproject bestaat uit iteraties die sprints genoemd worden (zie figuur 1). Voor elke sprint wordt een document opgesteld waarin staat waaraan het product moet voldoen, ook wel requirements genoemd, wat de projectplanning is en er is een plan voor de infrastructuur van het product in opgenomen. Binnen de sprint wordt er dagelijks gewerkt aan de requirements, de planning en wordt een
10
product ontwikkeld en getest. Het doel van Scrum is om na elke sprint een kwalitatief goed werkend onderdeel van het product op te leveren (Beedle et al., 1999). De methode zorgt voor een doelgerichte, snelle, effectieve, beheersbare en tegelijkertijd flexibele ontwikkeling. Op deze manier is het mogelijk om snel nieuwe functionaliteiten van een product te ontwikkelen (Van Solingen en Rustenburg, 2010).
Figuur 1: Scrum ontwikkeltraject (bron: Rannikko, 2011). Het Scrumteam Het Scrumteam is multidisciplinair, werkt zelfstandig en kan bestaan uit UX-‐designers, UX-‐researchers, maar bestaat met uit name technische ontwikkelaars. Verder zijn er vier rollen te verdelen binnen een scrumproject (Van Solingen en Rustenburg, 2010). Eén van die rollen is de product-‐eigenaar, de contactpersoon van de stakeholder en daarmee ook vaak contactpersoon voor het uitvoeren van bijvoorbeeld UX-‐research. De werkzaamheden van het Scrumteam De dag begint met een stand-‐up waarbij iedereen drie vragen beantwoord over de persoonlijke werkzaamheden. Op deze manier worden mogelijke belemmeringen bij het uitvoeren van werkzaamheden gedeeld en/of opgelost en is het Scrumteam dagelijks op de hoogte van wat er speelt en van het ontwikkelproces. Elk lid van het Scrumteam is verantwoordelijk voor werkzaamheden die binnen zijn of haar discipline vallen (Van Solingen en Rustenburg, 2010).
2.3 UX-‐research in combinatie met Scrum
2.3.1 Belang van integratie tussen UX-‐research en Scrum Er is een toenemende interesse voor de integratie van UX-‐research en agile software ontwikkeling, zoals Scrum (Salah et al., 2014). Hiervoor zijn drie redenen. Allereerst zijn agile methoden ontwikkeld om in een korte periode software te ontwikkelen. Hoewel de software dan succesvol is, in de zin dat het werkt, is de software vaak niet gebruiksvriendelijk (Butt et al., 2014). Kennis over het nut en de principes van usability, user requirements en evaluaties ontbreekt (Salah et al., 2014). Volgens het onderzoek van Butt et al. (2014) is het belangrijk dat voor het ontwikkelen van gebruiksvriendelijke software, UX-‐research opgenomen moet worden binnen de agile methode. Een tweede reden voor de
11
toenemende interesse is dat ontwikkelaars met behulp van UX-‐research op de hoogte zijn van de wensen, behoeften en de doelen van de potentiële gebruikers. Dit leidt tot een verbeterde gebruiksgemak en gebruikerstevredenheid (Salah et al., 2014). Ten derde lijkt er een filosofisch en principieel verschil te zijn tussen agile methoden en UX-‐research in hun focus, evaluatiemethoden, cultuur en documentatie (zie paragraaf 2.3.2). Dit suggereert volgens Salah et al. (2014) dat een integratie leidt tot een fundamentele uitdaging. Volgens Rannikko (2011) creëert het integreren van UX-‐research en agile software ontwikkeling een uitgebreid ontwikkelproces voor producten.
2.3.2 Kloven en uitdagingen bij de integratie van UX-‐research en Scrum Er zijn volgens Rannikko (2011) een aantal fundamentele kloven tussen UX-‐research en agile (scrum) ontwikkelprocessen die integratie van beide kunnen belemmeren:
• Werkproces: Agile softwareontwikkeling is incrementeel, omdat het product per onderdeel (product feature) wordt ontwikkeld en gelanceerd. UX-‐research neigt naar een iteratief proces (herhaaldelijk testen), maar is vaak niet incrementeel, omdat het hele product eerst volledig wordt ontworpen en daarna wordt geoptimaliseerd in iteraties.
• Rolverdeling: Uit de praktijk blijkt dat binnen agile ontwikkeltrajecten niet duidelijk is welke competenties het team in zijn geheel nodig heeft, waardoor er meestal geen UX-‐researcher betrokken wordt. Vaak wordt volstaan met de inzet van één of meerdere UX-‐designers; dit zijn interaction designers die zich bezig houden met het bouwen van prototypes, maar niet met het gebruikersonderzoek.
• Werkzaamheden/methoden: Bij beide disciplines, UX-‐research en agile software ontwikkeling, wordt uitvoerig getest om te achterhalen of de software werkt en aan gestelde eisen voldoet. Bij UX-‐research wordt uitvoerig getest met daadwerkelijke (potentiële) eindgebruikers van het product. Dit is erg tijdsintensief; traditionele usability interviews met eindgebruikers (UX) kosten veel tijd en dit komt vaak niet overeen met de tijd die hiervoor beschikbaar is binnen een agile (scrum) proces. Binnen agile softwareontwikkeling wordt getest door experts of product-‐eigenaren. Wat feitelijk neerkomt op het nakijken van je eigen huiswerk. Met als gevolg een snellere goedkeuring, waardoor er user requirements en bugs over het hoofd gezien kunnen worden. Hierin ligt voor de integratie van beide disciplines de grootste uitdaging.
Deze genoemde verschillen hoeven geen struikelblok te veroorzaken bij de integratie tussen UX-‐research en Scrum (Rannikko, 2011). Wel is het belangrijk, gezien het feit dat er verschillende agile methoden zijn, om eerst te onderzoeken of UX-‐research geïntegreerd kan worden binnen de specifieke agile methode en welke consequenties daarmee gepaard gaan. De grootste uitdaging bevindt zich in het werkproces: de afstemming van de planning en de tijd (Rannikko, 2011). Salah et al. (2014) noemen een aantal uitdagingen als het gaat om het uitvoeren van UX-‐research binnen een agile software methode.
• Plannen van UX-‐research: door onduidelijkheid over hoeveel tijd vrijgemaakt moet worden voor evaluaties binnen de incrementele structuur van agile methoden, leidt het plannen van UX-‐research tot een uitdaging.
12
• Verwerken van resultaten: door de strakke tijdlijn van agile methoden is er weinig tijd om resultaten uit usability onderzoek te verwerken in de huidige of eerst volgende sprint.
• UX-‐methoden/tools: er ligt een uitdaging om UX-‐research uit te voeren, omdat het moeilijk is voor Scrumteams om tijd vrij te maken om te evalueren en prototypes te herzien. Voor het UX-‐research team is het lastig om snel eindgebruikers te werven. Werving van eindgebruikers kost tijd en kan niet ad hoc geregeld worden.
2.4 Onderzoeksvragen Het UX-‐research team heeft de wens om UX-‐research te integreren binnen de Scrum ontwikkeltrajecten van Sanoma. Om te onderzoeken hoe en of dit mogelijk is, is de volgende hoofdvraag met bijbehorende onderzoeksvragen opgesteld: Wat zijn de belemmerende en bevorderende factoren voor de integratie van UX-‐research en Scrum binnen Sanoma?
1. Hoe verloopt het UX werkproces binnen de vergelijkingssite Kieskeurig en in hoeverre komt dit overeen met het Scrumwerkproces van Kieskeurig?
2. Wat is de rol van de UX-‐researcher binnen het Scrumteam van Kieskeurig? 3. Welke UX-‐methoden/tools worden ingezet voor Kieskeurig en zijn deze toepasbaar
binnen een Scrumwerkproces?
13
3. Methode Het vraagstuk van Sanoma is kwalitatief van aard, omdat de vraag over het verkennen en inzichtelijk maken van werkprocessen gaat. Ook wel participerende observatie genoemd. Dit is een vorm van empirisch onderzoek waarbij gebruik wordt gemaakt van kwalitatieve gegevens en dat als doel heeft om onderzoeksproblemen te beschrijven en te interpreteren (Baarda et al., 2005). Een aantal kenmerken van kwalitatief onderzoek die van toepassing zijn op dit onderzoek:
• Onderzoek wordt uitgevoerd in alledaagse omstandigheden. • Onderzoekssituatie is een geheel binnen de context (holistisch). • Theorie wordt toegepast om verschijnselen te interpreteren en/of te verklaren.
3.1 Participerende observatie De data in dit onderzoek is verzameld met behulp van de methode participerende observatie. Met deze methode worden gegevens verzameld door ter plaatste aanwezig te zijn, te participeren in dagelijkse activiteiten, te observeren en waar te nemen in het algemeen. Participerende observatie omvat zowel observeren, als het voeren van gesprekken, als het verzamelen van documenten (Baarda et al., 2005) Het onderzoek is gedurende de periode september tot halverwege december 2014 uitgevoerd bij Sanoma, te Hoofddorp. Per week zijn er drie tot vier dagen besteed aan onderzoek en één tot twee dagen aan de vastlegging van de bevindingen ervan. Met de participerende observatie is een helikopterview gecreëerd waarmee de belemmerende en bevorderende factoren voor de integratie van UX-‐research en Scrum binnen Sanoma in kaart zijn gebracht.
3.1.1 Onderzoekscasus: Kieskeurig.nl Binnen de participerende observatie is er ingezoomd op de casus van de vergelijkingssite Kieskeurig. Hierdoor is er meer diepgang bereikt in de bestudering van de werkprocessen van het UX-‐research team en het Scrumteam van Kieskeurig, de relatie tussen het UX-‐research team en het Scrumteam van Kieskeurig en de UX-‐methoden/tools die zijn ingezet. Kieskeurig leek hiervoor een geschikte casus, omdat Kieskeurig de eerste stakeholder was waarbij UX-‐research met Scrum moest samengaan. Een pilot voor de integratie tussen UX-‐research en het Scrumteam. De focus ligt op de casus van Kieskeurig, maar er zijn ook andere casussen bestudeerd die in dit rapport ter vergelijking mogelijk aan de orde komen. Dit kunnen casussen zijn van de Duckworld Adventure game, de webwinkel VTwonen, nieuwssite NU.nl, vergelijkingssite Energieprijzen, online tv-‐gidsen Totaal TV en Veronica Magazine en het blog WTF. Voor deze producten zijn er gedurende het onderzoek één of meerdere keren een usability onderzoek uitgevoerd of zijn er een aantal contactmomenten geweest tussen de stakeholder en het UX-‐research team. Deze casussen zijn echter niet zo uitgebreid onderzocht als de casus van Kieskeurig.
14
3.1.2 Focus van de observatie: procesoptimalisatie De participerende observatie vond plaats op twee niveaus (zie figuur 2):
A. Het eerste niveau is overstijgend en betreft de optimalisatie van het algehele werkproces (integratie UX-‐research en scrum) van Kieskeurig: hierbij wordt het totale werkproces in kaart gebracht, waaronder de afstemming van planning van UX-‐research binnen het scrumontwikkelproces, de rol van UX-‐research binnen het ontwikkeltraject, en de efficiëntie van UX-‐methoden/tools binnen het Scrumontwikkelproces.
B. Het tweede niveau betreft de optimalisatie van het product Kieskeurig.nl: hierbij worden de resultaten van UX-‐methoden/tools afzonderlijk in kaart gebracht (o.a. rapportage usability interviews (paragrafen 4.3.2 en 4.3.3) en de invloed ervan op het gebruik, de gebruiksvriendelijkheid en de conversie van Kieskeurig.nl);
Binnen het huidige onderzoek wordt een antwoord gezocht op de factoren die integratie van de werkprocessen UX-‐research en het scrumontwikkeling belemmeren en/of bevorderen. Daardoor is de beschrijving van de resultaten in dit onderzoeksrapport primair gericht op de optimalisatie van het werkproces. De uitwerking van alle ingezette UX-‐methoden/tools is van secundair belang gezien de onderzoeksvraag en zijn daarom uitsluitend weergegeven in bijlage 6 tot en met 11 van dit rapport.
Figuur 2: Procesoptimalisatie vs. productoptimalisatie.
3.2 Dataverzameling
3.2.1 Operationaliseringsschema De data van dit onderzoek is een verzameling van gegevens afkomstig uit verschillende onderzoekstechnieken die zijn toegepast binnen de participerende observatie:
• Observaties van de onderzoeker: alle resultaten zijn observaties tenzij anders aangegeven. Indien anders, dan wordt vermeld dat het gaat om:
o Gesprekken met stakeholders: aangegeven door citaten van stakeholders. o Documentatie: powerpointpresentaties, portfolio’s en overige
bedrijfsdocumenten. In tabel 1 staat een overzicht met daarin per onderzoeksvraag de uitgevoerde activiteiten waarmee uiteindelijk de hoofdvraag beantwoord kan worden: Wat zijn de belemmerende en bevorderende factoren voor integratie van UX-‐research en Scrum binnen Sanoma? Het operationaliseringsschema laat per onderzoeksvraag en per onderzoekstechniek zien welke onderzoeksactiviteiten er verricht zijn.
15
Tabel 1: Operationaliseringsschema. Onderzoeksactiviteiten binnen de participerende observatie
1. Hoe verloopt het UX werkproces binnen de vergelijkingssite Kieskeurig en in hoeverre matcht dit met
het Scrumwerkproces van Kieskeurig? (zie paragraaf 4.1) Gesprekken
• Gesprekken (één keer per maand) gehad met Nicol Nijland en Paula Deisz (UX-‐researchers) over het UX-‐werkproces binnen Sanoma.
• Gesprekken (één keer per maand) gehad met Guido Jansen (conversiemanager) over het scrumproces van Kieskeurig, algemene werkproces, planning en conversieoptimalisatie bij Kieskeurig.
• Gesprek gehad met Marloes Hilckmann (product-‐eigenaar) over integratie UX-‐research binnen het scrumproces van Veronica magazine en Totaaltv.
• Gesprek gehad met Roy Abbink (manager van Lean UX team, Sanoma Innovation Llab) over het werkproces UX-‐research en Scrumwerkprocessen bij Sanoma.
• Gesprek gehad met Serge van Steensel (Scrummaster bij nieuwssite NU.nl) over Scrumproces bij NU.nl en Kieskeurig.
• Gesprek gehad met Marie Louise Kok (intrapeneur Sanoma Innovation Lab) over het scrumontwikkelproces van diverse innovaties binnen het Innovation Lab, waaronder Shop & Swipe.
• Gesprek gehad met Wouter van Dun (product-‐eigenaar) over het scrumontwikkelproces van de Duck World Adventure games.
Documentatieonderzoek
• Evaluatie van de ‘Menukaart’ van het UX-‐research team met daarin een overzicht van de hoeveelheid beschikbaar gestelde onderzoekstijd per stakeholder en per tool de benodigde tijd voor de uitvoering van UX-‐research.
• Informatieverzameling over scrumwerkprocessen binnen Sanoma: Powerpoint presentatie gemaakt door Serge van Steensel over Scrumprocessen bij NU.nl en Kieskeurig.
Observaties
• Proces van UX-‐research vanaf intake tot uitvoering bij Kieskeurig, Totaal TV, Duckworld Adventure game, NU.nl, Energieprijzen, Veronica magazine, VTwonen en WTF.
• Proces van UX-‐research en Scrumproces (product release, eindsessie van sprint bijgewoond) samen bij Kieskeurig en Duckworld Adventure game.
• Planning met tijdsindicaties van zowel UX-‐research team als van het Scrumteam van Kieskeurig. • Intake gesprekken voor UX-‐research gevoerd voor Kieskeurig en Fashionchick. • Intake gesprekken voor UX-‐research bijgewoond voor de webwinkel VTwonen, Veronica
Magazine.nl, Energieprijzen.nl, NU.nl, Geboortekaartje.nl. 2 Wat is de rol van de UX-‐researcher binnen het Scrumteam van Kieskeurig? (zie paragraaf 4.2) Gesprekken
• Gesprek gehad met Michiel de Nijs (manager UX-‐team, stafafdeling Lead Generation) over Scrumprocessen binnen Sanoma en de rol van UX-‐research daarin en de samenwerking tussen het UX-‐research team en het UX-‐design team.
• Gesprek gehad met Roy Abbink (manager van Lean UX team, Sanoma innovation lab) over de rol van UX-‐research binnen Scrum bij Sanoma.
• Gesprek gehad met Guido Jansen (conversiemanager Kieskeurig) over de rol van UX-‐research bij het Scrumteam van Kieskeurig.
Observaties
• Samenwerking met UX-‐researchers en Scrumteam en uitvoering van UX-‐tools en methoden bij Kieskeurig, Duckworld Adventure game, Veronica magazine, Energieprijzen en NU.nl.
• Input geleverd voor presentatie (en ook bijgewoond) over conversieoptimalisatie bij Kieskeurig en hoe UX-‐research daaraan bijgedragen heeft.
16
3 Welke UX-‐methoden/tools worden ingezet voor Kieskeurig en zijn deze toepasbaar binnen een Scrumwerkproces? (zie paragraaf 4.3)
Gesprekken • Gesprek gehad met Guido Jansen (conversiemanager Kieskeurig) over de UX-‐methoden/tools
die worden ingezet bij Kieskeurig. • Gesprek gehad met Nicol Nijland en Paula Deisz (UX-‐researchers) over de eigenschappen van de
UX-‐methoden/tools uit het portfolio van het UX-‐Lab. Documentatieonderzoek
• Evaluatie van het portfolio van UX-‐research met daarin een overzicht van alle methoden/tools die inzetbaar zijn.
Observaties
• UX-‐methoden/tools die zijn ingezet en in welke ontwikkelfasen. • Opstellen van testscript voor usability interview voor Kieskeurig (vier keer). • Usability interview uitvoeren en observeren voor Kieskeurig inclusief het schrijven van de
rapportage met daarin de belangrijkste bevindingen en conclusies (drie keer). • Usability interview uitvoeren en observeren voor Duckworld adventure game inclusief het
schrijven van een korte rapportage met daarin de belangrijkste bevindingen en conclusies (drie keer).
• Usability interview voor Energieprijzen observeren. • Meewerken aan een guerilla usability test voor de app Swipe&shop. • Een survey (survey monkey) inzetten voor Totaal TV. • Feedbacktool inzetten voor de website WTF. • Expert reviews uitvoeren voor de website van Libelle, de blog Your little black book en
Fashionchick. • Resultaten van de tool Inspectlet analyseren voor de website Het Testpanel. • Mogelijkheden van de tools Usabilla, Verify, Loop 11 bestuderen.
3.3 De rol van de onderzoeker Voor dit onderzoek was het erg belangrijk om onderscheid te maken tussen de rol van de UX-‐researcher en de rol van de onderzoeker (dubbelrol) die beide vanuit dezelfde positie, het UX-‐research team, plaatsvonden. Er is met het UX-‐research team afgesproken dat de onderzoeker de casus van Kieskeurig leidt. Bij deze casus vond er daarom vanuit de rol van de onderzoeker een intensieve participatie plaats waarbij er een gehele onderdompeling heeft plaatsgevonden waarin actief en intensief is omgegaan met alle betrokkenen van Kieskeurig (Baarda et al., 2005). Keuzes met betrekking tot het werkproces, de rol van UX-‐researcher en de UX-‐methoden/tools die ingezet worden, zijn in overleg met het UX-‐research team gemaakt. Hiermee is geprobeerd te voorkomen dat de onderzoeker beïnvloed wordt en er daardoor geen objectieve observatie kan plaatsvinden. Op deze manier is er niet of nauwelijks afgeweken van de ‘normale’ processen. Voor de observatie van andere casussen naast Kieskeurig is de afspraak gemaakt dat de onderzoeker ter ondersteuning meewerkt aan de UX-‐activiteiten en het UX-‐research team hierin de leiding neemt.
3.4 Data-‐analyse Gezien de commerciële en snelle aard van de organisatie is het belangrijk om rekening te houden met de spanningsvelden die binnen de organisatie spelen en van (negatieve) invloed kunnen zijn op het onderzoek en vastlegging van de data (Patton, 2002). Er is daarom gestreefd om alle data vast te leggen in notulen, maar het is om de genoemde reden
17
mogelijk dat dit niet voor alle data op een gestructureerde wijze lukt. Voor het observeren en analyseren van de data is een onderscheid gemaakt tussen drie thema’s die zijn opgesteld op basis van de belangrijkste verschillen tussen UX-‐research en Scrum zoals beschreven in paragraaf 2.3.2:.
• Het werkproces van het UX-‐research team en het Scrumteam. • De rol van de UX-‐researcher binnen het Scrum ontwikkeltraject. • De inzet van UX-‐methoden/tools binnen het Scrum ontwikkeltraject.
In tabel 2 staat een overzicht van de thema’s met bijbehorende beschrijving. Aan de hand van deze thema’s is de data verzameld en geanalyseerd en zijn de belemmerende en bevorderende factoren voor de integratie van UX-‐research en Scrum in kaart gebracht (zie hoofdstuk 4). Tabel 2: Overzicht onderzochte thema’s met bijbehorende beschrijving. Thema Inhoud Werkproces van UX-‐research en scrum
Is het werkproces agile? • Loopt het werkproces van het UX-‐research team gelijk met de sprints
van het Scrumteam? • Is het inpasbaar of nodig dat de werkprocessen gelijk gaan? • Verwerking van resultaten naar aanleiding van UX-‐research in de sprints.
Rol van de UX-‐researcher
Is de rol agile? • Is er een dedicated UX-‐researcher binnen het Scrumteam en is dit nodig? • Op welk moment in het ontwikkelproces wordt de UX-‐researcher
aangehaakt door het Scrumteam? • De relatie tussen de UX-‐researcher en het Scrumteam. • De mate van betrokkenheid tussen de UX-‐researcher en het Scrumteam.
Inzet van UX-‐methoden/tools
Zijn de UX-‐methoden/tools agile? • Overzicht van UX-‐methoden/tools die beschikbaar zijn binnen Sanoma. • Mate waarin deze UX-‐methoden/tools snel, iteratief en incrementeel
zijn, maar wel gedegen kwaliteit leveren. • Is het haalbaar en/of nodig dat de UX-‐methoden/tools agile zijn? • Wat leveren de UX-‐methoden/tools op en wat is de toegevoegde
waarde daarvan?
18
4. Resultaten De resultaten uit het onderzoek hebben betrekking op de casus van Kieskeurig en zijn onderverdeeld in:
• Het werkproces van het UX-‐research team en het Scrumteam van Kieskeurig • De rol van de UX-‐researcher • UX-‐methoden/tools
Ter vergelijking worden tevens voorbeelden uit andere casussen aangehaald.
4.1 Werkprocessen
4.1.1 Het werkproces van het UX-‐research team bij Kieskeurig Het werkproces van het UX-‐research team bestaat niet zoals bij Scrum uit sprints. Wel zijn er stappen die elkaar opvolgen (UX-‐researchers NN en PD en eigen observatie). In figuur 3 staat een schematische weergave van de stappen van het werkproces van het UX-‐research team bij Kieskeurig. Afhankelijk van het ontwikkeltraject en het productstadium kan het UX-‐research team een plan maken voor de inzet van UX-‐tools/methoden. De wit gemarkeerde stappen gelden voor alle UX-‐methoden/tools. In geel zijn de concrete stappen voor usabiltiy interviews weergegeven. Bijlage 1 bevat een overzicht van de beschikbare en UX-‐methoden/tools en in paragraaf 4.3.2 staat beschreven welke UX-‐methoden/tools zijn ingezet bij Kieskeurig.
Figuur 3: Werkproces UX-‐research team in casus Kieskeurig. De conversiemanager van Kieskeurig heeft het UX-‐research team gevraagd om met behulp van een UX-‐research inzicht te krijgen in de gebruikerservaring. Tijdens de intake met de UX-‐researchers en de conversiemanager van Kieskeurig werd de planning en het portfolio met de inzetbare methoden/tools besproken (zie Portfolio in bijlage 2). Het UX-‐research team heeft een menukaart (zie bijlage 3) om prioriteiten aan stakeholders toe te kennen en een portfolio van beschikbare UX-‐tools, maar het team beschikt niet over een
Verzoek voor UX-‐research
Intake met stakeholder (1 uur)
Inrichten UX-‐methoden/tool (halve dag)
Opstellen testscript en start werving proefpersonen
(twee weken)
Ingerichte UX-‐methoden/tool of testscript bespreken met stakeholder en aanpassen
(halve dag)
Uitzetten UX-‐methoden/tool (2 weken)
Uitvoeren usability interviews (1 dag)
Rapportage maken van de resultaten (halve dag)
(usability interviews 1 dag)
Rapportage bespreken met stakeholder (2 uur)
19
gestandaardiseerde planning of richtlijn waarin staat aangegeven wanneer, dat wil zeggen in welke fase van ontwikkeling en in welk productstadium, welke UX-‐methoden/tools ingezet kunnen worden. In overleg met de conversiemanager van Kieskeurig wordt geadviseerd om maandelijks een usability interview in te zetten waardoor er iteratief, herhaaldelijk, getest wordt. De usability interviews voor de maanden september tot en met december zijn in september ingepland. Het doel van het interview wordt bepaald door de conversiemanager die hiervoor een plan heeft opgesteld dat onder andere gebaseerd is op de uitkomsten van voorgaande usability interviews. Twee weken voorafgaand aan het interview wordt het doel met de UX-‐researchers besproken. Als het doel besproken was, werd de werving voor de respondenten gestart en het testscript met daarin de taken voor de respondenten opgesteld. Een paar dagen voor het usability interview, werd het testscript samen met de conversiemanager besproken. In bijlage 4 staan de testscripten van de usability interviews. Voor elk usability interview werden zes respondenten verworven, omdat uitval van respondenten niet te vermijden is en er minimaal met vijf personen getest moet worden. Tijdens de interviews in oktober en november viel beide keren één respondent uit. Dit leverde voor de dataverzameling geen problemen op. Er is voldoende input verkregen met vijf respondenten. Er trad verzadiging van problemen op na vier respondenten. Na elk interview zijn de belangrijkste resultaten besproken en heeft de UX-‐researcher een rapportage opgesteld met de resultaten. De rapportage werd voor de intake van het daaropvolgende usability interview besproken met de conversiemanager van Kieskeurig.
4.1.2 Het Scrumproces van Kieskeurig De cyclus van het Scrumproces van Kieskeurig bestaat uit sprints van twee weken. In elke sprint worden een aantal items opgenomen waaraan gedurende twee weken gewerkt wordt (conversiemanager GJ en product-‐eigenaar SS en powerpoint uit bijlage 5). In de backlog, de lijst met alle items die in een sprint opgepakt moeten worden, staat per item aangegeven om wat voor item het gaat (een nieuwe taak, een verbetering van een taak of een bug), hoeveel prioriteit het heeft, de geschatte tijd die het in beslag neemt en een checklist of het item is opgepakt. Met name de product-‐eigenaar, conversiemanagers, content specialisten en technisch developers voegen afzonderlijk van elkaar nieuwe items toe aan de backlog. De product-‐eigenaar maakt de planning en bepaalt welke items in een sprint worden aangepakt (conversiemanager GJ). Het komt echter regelmatig voor dat er vanuit het managementteam ad hoc items aan de planning toegevoegd moeten worden naast de items die op de bestaande planning staan. Dit zorgt voor veel afleiding bij het development team, waardoor de focus van de planning kwijt raakt. Er is geen consensus tussen het management en de product-‐eigenaar. Naast de planning met items voor de sprints, maken disciplines binnen het team afzonderlijk een eigen planning voor midden tot lange termijn. Hierdoor raakt het overzicht kwijt van wat iedereen aan het doen is. Er ontbreekt een eenduidige flow binnen het Scrumproces (conversiemanager GJ en product-‐eigenaar SS en powerpoint uit bijlage 5). Het product dat aan het einde van de sprint is gecreëerd, wordt direct gelanceerd op de website (conversiemanager GJ).
4.1.3 Verwerking van resultaten in de sprints van Kieskeurig Tijdens elke nieuwe intake voor een usability interview, is met de conversiemanager van Kieskeurig besproken of de gevonden knelpunten uit het voorgaande interview zijn opgepakt. Deze uitkomsten zijn in de analyseschema’s bijgehouden (meer over de
20
analyseschema’s in paragraaf 4.3.3). Het blijkt dat knelpunten vaak niet in dezelfde of eerstvolgende sprint van het Scrumteam zijn opgepakt. De voornaamste redenen hiervoor zijn dat er te weinig capaciteit is in het development team om eraan te werken of omdat het niet voldoende prioriteit heeft (conversiemanager GJ). De mate van prioriteit wordt voor elk van de knelpunten bepaald door de conversiemanager met het PIE framework (Goward, 2013). Van de knelpunten die een hoge prioriteit kregen, is de zoekmachine die tijdens het interview in september niet optimaal werkte, in de sprint erna opgepakt. De vergelijkingsfunctie en een aantal bugs met betrekking tot de filter die in september gevonden zijn, zijn in een sprint in november opgepakt. Knelpunten die in de interviews van september en oktober zijn gevonden met een lage prioriteit zijn in de sprint van november opgepakt (conversiemanager GJ). In de casus van de Duckworld Adventure game werden er in elke tweewekelijkse sprint nieuwe functionaliteiten toegevoegd of aangepast die vervolgens met behulp van tweewekelijks uitgevoerde usability interviews werden onderzocht. Er was voldoende tijd ingepland om de belangrijkste gevonden belemmeringen door proefpersonen op te pakken in de eerst volgende sprint.
4.2 De rolverdeling
4.2.1 De rol van de UX-‐researcher binnen het Scrumteam van Kieskeurig De UX-‐researcher heeft geen geïntegreerde (dedicated) rol binnen het Scrumteam van Kieskeurig. Dit betekent dat de UX-‐research niet dagelijks op de werkplek van Kieskeurig te vinden is, en wekelijks slechts één of twee contactmomenten heeft met het development team van Kieskeurig. Al het contact vanuit Kieskeurig verliep via één persoon, te weten de conversiemanager. De conversiemanager heeft het UX-‐research team benaderd voor het uitvoeren van usability onderzoek. De vraag kwam daarmee vanuit de stakeholder zelf. Er was daarmee een intrinsieke motivatie om usability onderzoek te verrichten. Naast de conversiemanager waren er geen andere personen direct betrokken bij UX-‐research.
4.2.2 Moment waarop de UX-‐researcher is aangehaakt door Kieskeurig Het moment waarop UX-‐researchers zijn aangehaakt door Kieskeurig is tijdens de summative evaluation, dat wil zeggen, na de lancering van een nieuwe functionaliteit op de website. Alle onderzoeken zijn uitgevoerd op een werkende website die live stond en features die in doorontwikkeling waren, werden pas getest wanneer ze gereed waren. In de laatste ronde trad er een wijziging op doordat de UX-‐designer ook aanwezig was en er afspraken gemaakt werden om in het vervolg al het prototype van nieuwe features voor te leggen aan het UX-‐research team middels een expert review. In de casussen van de Duckworld Adventures game en de nieuwssite NU.nl, werd de UX-‐researcher daarentegen in een eerdere ontwikkelfase, de designfase, aangehaakt.
4.2.3 Mate van betrokkenheid tussen de UX-‐researcher en het Scrumteam van Kieskeurig De conversiemanager van Kieskeurig was bij elke test de hele dag aanwezig om mee te observeren en aantekeningen te maken. Het Scrumteam en de product-‐eigenaar van Kieskeurig werden voor elk usability interview met gebruikers uitgenodigd door de conversiemanager om de live mee te kijken tijdens de usability interviews. Vaak keken de productmanager, een andere conversiemanager, de UX-‐designer en af en toe een
21
contentspecialist en technisch developers een aantal sessies mee. De collega’s van Kieskeurig die meekeken gaven aan dat de interviews van toegevoegde waarde waren, maar de betrokkenheid was in het algemeen niet erg hoog vanuit het Scrumteam van Kieskeurig (conversiemanager GJ en eigen observatie). De betrokkenheid vanuit het Scrumteam van de Duckworld Adventures game was daarentegen een stuk hoger. Het gehele Scrumteam keek meerdere sessies live mee, maakten zelf actief aantekeningen en dachten mee met vragen die de interviewer aan de proefpersonen konden stellen.
4.3 Inzet van UX-‐methoden/tools binnen Kieskeurig
4.3.1 Zijn de beschikbare UX-‐methoden/tools van Sanoma agile? In bijlage 1 staat een overzicht met de UX-‐methoden/tools met een omschrijving die het UX-‐research team tot haar beschikking heeft (Portfolio uit bijlage 2). In tabel 3 is een overzicht opgesteld waarin per tool wordt aangegeven waarom deze al dan niet geschikt is binnen een agile werkomgeving (documentatie). Per tool is gekeken naar de fase waarin de tool ingezet kan worden in het scrumontwikkelproces (hoe eerder en vaker, des te meer geschikt is de tool voor Scrum), en naar hoeveel tijd het kost om de tool uit te voeren en te analyseren (hoe minder tijd, des te meer geschikt voor Scrum). In deze paragraaf wordt het portfolio van het UX-‐research team geëvalueerd. Een expert review lijkt een erg geschikte tool om in te zetten binnen een agile werkomgeving. De uitvoering en rapportage zijn snel, de tool kan in elke ontwikkelfase ingezet worden en geeft een helder beeld van de belangrijkste knelpunten van een product. De uitkomsten van een expert review zijn nuttig om als input te gebruiken voor een vervolgonderzoek, zoals een usability interview. Een usability interview is een zeer nuttige en nauwkeurige methode om de usability van een product te meten. In verhouding met de andere tools levert een usability interview de meeste en meest relevante informatie op, omdat het antwoord geeft op hoe het gebruik van een website of app gestimuleerd kan worden. Meer concreet geeft de methode antwoord op vragen als: “Hoe gebruikt een eindgebruiker het product en waarom worden bepaalde delen van het product bijvoorbeeld niet gebruikt?” Een gebruiker voert live taken uit, wat inzichten geeft in zowel het daadwerkelijke gedrag als in het denkpatroon van gebruikers. Bovendien kunnen stakeholders in een andere ruimte mee observeren wat de betrokkenheid verhoogt. De uitvoering van een traditioneel usability interview is echter erg tijdrovend. Ondanks de tijd die het kost is het toch een belangrijke methode die niet mag ontbreken binnen een agile werkmethode door de relevante resultaten (kwaliteit) die het oplevert. Om tegemoet te komen aan de agile werkwijze kan de methode aangepast worden door efficiënter te werken. De rapportage die wordt geschreven in de traditionele variant duurt relatief lang en is erg uitgebreid. Indien er geen tijd is voor een uitgebreide rapportage, dan kan in onderling overleg met stakeholders gekozen worden voor een snellere ‘discount’ variant van een usability interview die meer geschikt is binnen een agile werkmethode, waarbij de rapportage achterwege gelaten wordt en waarbij live meekijken door stakeholders vereist is.
22
Tabel 3: Overzicht van UX-‐tools en de mogelijkheden voor inzet binnen een scrumproces.
* Dit is de gemiddelde periode waarin een tool live moet staan. De periode kan, afhankelijk van de snelheid van de respons, variëren.
Tools Wel agile Niet agile Websort • Kan in bijna elke ontwikkelfase
ingezet worden. • Uitvoering en analyse kosten relatief
weinig tijd.
• Tool moet 2 weken tot een maand live staan om voldoende reacties te genereren.*
Usabilla • Eenvoudig uitvoerbaar voor gebruikers.
• Uitvoering en analyse kosten relatief weinig tijd.
• Tool moet 2 weken tot een maand live staan om voldoende reacties te genereren.*
Loop 11 • Eindgebruikers hoeven niet naar het lab te komen.
• Tool moet 2 weken tot een maand live staan om voldoende reacties te genereren.*
• Data voor analyses werkt minder prettig en dat kost extra tijd.
Verify • Aan het begin van de ontwikkelfase de mening van gebruikers meten.
• Tool moet 2 weken tot een maand live staan om voldoende reacties te genereren.*
• Data voor analyses werkt minder prettig en dat kost extra tijd.
• Alleen mockups kunnen getest worden. Inspectlet • Gedrag van gebruikers in een
natuurlijke omgeving meten. • Tool moet 2 weken tot een maand live
staan om voldoende reacties te genereren.*
• Data voor analyses werkt minder prettig en dat kost extra tijd.
Expert review • Kan in elke ontwikkelfase
uitgevoerd worden. • Snel in een dag uitvoerbaar. • Uitgebreide analyse.
Usability interview
• Veel relevante informatie m.b.t. gedrag eindgebruiker.
• Inzichten in denkpatroon gebruikers.
• Voorbereiding en rapportage van resultaten kost totaal +/-‐ een maand.
• Maximaal zes proefpersonen per sessie.
Feedbacktool • Eenvoudig uitvoerbaar voor gebruikers.
• Tool moet 2 weken tot een maand live staan om voldoende reacties te genereren.*
• Data voor analyses werkt minder prettig en dat kost extra tijd.
Survey monkey • Uitvoering en rapportage is eenvoudig en kost relatief weinig tijd.
• Mening en wensen van gebruikers m.b.t. product meten.
• Tool moet (vaak) 2 weken tot een maand live staan om voldoende reacties te genereren.*
23
Voor de ‘remote’ usability tools: Usabilla, Verify, Loop 11, Websort en Inspectlet geldt dat deze een langere periode, gemiddeld twee weken tot een maand, live moet staan om voldoende reacties te verzamelen. Ondanks dat de voorbereiding weinig tijd kost, is het lastig om met deze tools snel, als in één werkweek, een rapportage af te leveren bij de stakeholder. Het snelle wat een agile werkmethode kenmerkt, lijkt niet samen te gaan met deze tools. Als een stakeholder echter een aanvullende gebruikersevaluatie wil op een usability interview en uitkomsten ook in een latere sprint verwerkt kunnen worden, dan zijn deze tools uiteraard wel geschikt. Voor Surveymonkey geldt ook dat deze een doorlooptijd van gemiddeld twee weken tot een maand heeft om gegevens te verzamelen. Ondanks dat deze tool daarom niet ad hoc inzetbaar is, is hij wel heel relevant om op een kwantitatieve manier de mening en wensen van gebruikers met betrekking tot een product te meten. Met behulp van deze tool kan achteraf gemeten worden of doelstellingen bereikt zijn.
4.3.2 UX-‐methoden/tools bij Kieskeurig In de periode september tot en met december 2014 is er maandelijks een usability interview uitgevoerd voor Kieskeurig. In september lag de focus van het interview met name op de zoekmachine, de filter en de vergelijkfunctie. Het usability interview in oktober had als doel om te achterhalen hoe gebruikers de specifieke productpagina van GSM ervaren en of ze begrijpen hoe ze door in te loggen een product kunnen bestellen. Het interview in november was een benchmarking, waarbij gebruikers naast Kieskeurig.nl, vergelijkbare taken uitvoerden op andere vergelijksites. Het doel van dit interview was niet zozeer om naar nieuwe belemmeringen bij functionaliteiten te zoeken, maar om inspiratie en ideeën op te doen voor oplossingen voor de belemmeringen die in september en oktober zoal zijn gevonden. Gebruikers raadpleegden op verschillende vergelijkingssites naast Kieskeurig.nl de filter, de vergelijkfunctie en de productdetailpagina. Het interview in december was een herhaling van het interview van september om na te gaan of de aanpassingen van functionaliteiten die eerder belemmeringen veroorzaakten, dat nog steeds doen. Daarnaast werd er wederom een benchmarking uitgevoerd om te achterhalen wat gebruikers belangrijk vinden bij het gebruik van een filter. Er is met de usability interviews iteratief en incrementeel getest. Aan het einde van elk usability interview werden de belangrijkste uitkomsten met de conversiemanager besproken. Voor elk interview is er vervolgens door de UX-‐researcher een uitgebreide rapportage opgesteld (zie bijlage 6 -‐9). De conversiemanager had de rapportages nodig om de uitkomsten van de interviews te delen met het Scrumteam en het management van Kieskeurig en koos daarom voor kwaliteit in plaats van snelheid. Naast de maandelijkse usability interviews, is er op verzoek van de conversiemanager een feedbacktool geplaatst op de website van Kieskeurig.nl en websort uitgevoerd. De resultaten die verkregen waren uit de feedbacktool kwamen overeen met de resultaten uit de reeks usability testen (september en oktober). Ook dat onderzoek was erg nuttig, omdat het een bevestiging was van eerdere uitkomsten. De uitkomsten van de websort en de feedbacktool zijn in een verkorte rapportage verwerkt (zie bijlage 10 en 11).
24
4.3.3 Toegevoegde waarde van de UX-‐methoden/tools bij Kieskeurig Om na te gaan wat de maandelijkse usability interviews en daarnaast het inzetten van websort en de feedbacktool hebben opgeleverd, is door de UX-‐researcher voor elk onderzoek een analyseschema ingevuld. Dit schema is op basis van verschillende bronnen opgesteld en bestaat uit zeven onderdelen (zie bijlage 12). Om te beginnen moet helder zijn in welke fase het product zich bevindt (Van Gemert-‐Pijnen et al., 2011). Vervolgens moet in het schema aangegeven worden welke functionaliteit(en) van het product getest worden en daarna of het gebruik van deze functionaliteiten positief (+) of negatief (-‐) ervaren worden door de eindgebruikers. De volgende stap is om belemmerende factoren voor het gebruik van het product in kaart te brengen. Om dit te meten, worden de kwaliteitsvariabelen uit het Information System success model (IS success model) van Delone en McLean (2003) gebruikt, namelijk system quality, information quality en service quality (zie bijlage 13 waarin het gehele IS success model wordt toegelicht). Deze belemmerende factoren worden vervolgens toegepast op de case waar onderzoek voor verricht wordt. Als deze knelpunten helder zijn, is het belangrijk om de prioriteit te bepalen van elke factor met behulp van het PIE framework (Goward, 2013). Is het een probleem dat direct van invloed is op de conversie, dan heeft het een hoge prioriteit. Het laatste onderdeel van het analyseschema is een checklist, waarin aangegeven wordt of de gevonden belemmerende factoren zijn opgepakt. Is dit niet het geval, dan is het belangrijk om te onderzoeken wat hier de reden voor is. Dergelijke inzichten kunnen het werkproces optimaliseren. De analyseschema’s die voor elk interview en de feedbacktool door de UX-‐researcher zijn ingevuld staan in bijlage 14. Het analyseschema kan niet worden toegepast voor de websort, omdat hier uitsluitend een optimale menustructuur volgens de gebruikers uit voortvloeit. In tabel 4 staat een overzicht van het aantal ervaren belemmeringen door de gebruiker per functionaliteit en per usability onderzoek opgesplitst per maand. Tabel 4: Overzicht van gevonden belemmeringen bij functionaliteiten door gebruikers (N= 22) opgesplitst per maand en per UX-‐onderzoek. September Oktober November December System quality
Usability interview: ý Zoekmachine ý Navigatie ý Filter ý Vergelijkfunctie ý Gridview/ listview ý Uitklapmenu
Usability interview: ý Zoekmachine ý Navigatie ý Filter ý Vergelijkfunctie ý Gridview/ listview ý Uitklapmenu
Usability interview: ý Filter ý Vergelijkfunctie
Usability interview: ý Navigatie ý Filter ý Vergelijkfunctie
Information quality
ý Productdetail-‐pagina ý Filter
ý Productover-‐zichtpagina ý Productgroep GSM ý Inloggen
ý Productover-‐zichtpagina ý Productdetail-‐ pagina
ý Homepage ý Vergelijk-‐overzicht
Service quality
-‐ -‐ -‐ -‐
-‐ Feedbacktool: ý Zoekmachine ý Navigatie ý Filter ý Vergelijkfunctie
-‐ -‐
25
Uit deze resultaten blijkt dat er bij elk nieuw usability interview nieuwe knelpunten van de website van Kieskeurig boven water komen. Tijdens het usability interview in september werden er zes specifieke functionaliteiten onderzocht. Uit het analyseschema van het usability interview van september blijkt dat gebruikers bij elke functionaliteit belemmerende factoren ervaren. De belemmerende factoren die zijn ervaren bij de zoekmachine zijn naar aanleiding van het interview aangepast, de andere vijf niet. Uit het usability interview van oktober blijkt dat het aanpassen van de zoekmachine zijn vruchten afwerpt, want de gebruikers ervaren zowel in oktober als november hier geen problemen meer mee. Voor de overige functionaliteiten geldt dat de belemmeringen in oktober blijven en er zelfs vier extra functionaliteiten gevonden zijn die problemen bij gebruikers opleveren. Uit de resultaten van de feedbacktool blijken gebruikers wederom belemmeringen te ervaren bij de zoekmachine, navigatie, de filter en de vergelijkfunctie. Er zijn met deze tool geen nieuwe belemmeringen bij functionaliteiten naar boven gekomen. Op basis van het usability interview van november, de benchmarking, is nuttige informatie opgedaan ter inspiratie voor het verbeteren van de filter, de vergelijkfunctie en de productdetailpagina. Gedurende het interview leverden deze functionaliteiten nog steeds problemen op bij de respondenten. De informatie die met behulp van het interview in november is opgedaan ter inspiratie voor het verbeteren van een aantal functionaliteiten was tijdens het interview in december nog niet verwerkt. De ervaren belemmeringen door gebruikers hadden net zoals in voorgaande usability interviews betrekking op de navigatie, filter en de vergelijkfunctie. Er zijn wel een aantal nieuwe belemmeringen gevonden. Gebruikers ervoeren problemen op de homepage, omdat daar teveel informatie staat waardoor bepaalde informatie niet vindbaar is. Verder was meer informatie op de vergelijkpagina gewenst. Opvallend is dat geen enkele methode informatie heeft opgeleverd over hoe service quality door gebruikers ervaren wordt, terwijl Kieskeurig wel service in de vorm van een chat of telefonische klantenservice aanbiedt. Dit zou kunnen aanduiden dat deze feature geen problemen oplevert bij gebruikers, maar het blijkt een feature waar nog nauwelijks gebruik van wordt gemaakt. Op basis van de gevonden issues en inspiratie die is opgedaan, zijn nieuwe A/B-‐testen opgezet (conversiemanager GJ). A/B-‐test is een marktonderzoekmethode die wordt gebruikt om te onderzoeken welke van de twee of meer ontwerpen de beste variant is (Beerthuyzen, M., 2014). Verder staat het uitvoeren van een survey om de klanttevredenheid te meten op de planning van Kieskeurig. De wensen van klanten vormen weer input voor een A/B-‐test (conversiemanager GJ). De resultaten uit de usability interviews hebben bovendien tot een verhoogde conversie geleid (zie figuur 4). De rode streep duidt het moment aan dat een aantal gevonden issues tijdens usability testen zijn opgepakt in een sprint. Na de rode streep is een piek in de conversie zichtbaar. Welke aanpassing exact heeft geleidt tot deze verhoging is niet te achterhalen, omdat er meerdere issues zijn verholpen. De grafiek bevat vertrouwelijke bedrijfsinformatie en is daarom niet in detail en met cijfers weergegeven.
26
Figuur 4: Conversie Kieskeurig.nl (Bron: presentatie conversieoptimalisatie bij Kieskeurig).
27
5. Conclusie en discussie De resultaten uit dit onderzoek geven inzicht in hoe UX-‐research samengaat met het Scrumproces van Kieskeurig, waarbij de focus lag op de werkprocessen van het UX-‐research team en het Scrumteam van Kieskeurig, de rol van de UX-‐researcher binnen het Scrumteam en de UX-‐methoden/tools. Aan de hand van dit onderzoek is een antwoord gezocht op de onderzoeksvraag: Wat zijn de belemmerende en bevorderende factoren voor integratie van UX-‐research en Scrum binnen Sanoma? Op basis van de bevindingen is getracht een advies te formuleren in de vorm van een richtlijn voor de inzet van UX-‐research in Scrum ontwikkeltrajecten binnen Sanoma.
5.1 Werkprocessen De grootste uitdaging voor het integreren van UX-‐research en Scrum ligt met name bij het werkproces (Rannikko, 2011; Salah et al., 2014). Het werkproces van UX-‐research is relatief langzaam. Scrum is daarentegen relatief snel en kenmerkt zich verder door openheid en betrokkenheid, focus, een adaptieve planning en een incrementeel en iteratief proces (Larman, 2003).
5.1.1 Integratie werkprocessen door iteratief testen Eén van de kloven tussen UX-‐research en het Scrumproces is dat UX-‐research meer naar een incrementeel proces neigt, maar niet iteratief is, en het Scrumproces iteratief en incrementeel van aard is (Rannikko, 2011). Voor een geslaagde integratie tussen UX-‐research en Scrum zou deze kloof ‘gedicht’ moeten worden. In de praktijk blijkt dit haalbaar. De onderzoeken die door het UX-‐research team zijn uitgevoerd voor Kieskeurig en voor de Duckworld Adventure game, waren namelijk iteratief van aard. Voor Kieskeurig is er maandelijks een usability interview uitgevoerd en voor de Duckworld Adventure game tweewekelijks. Uit de resultaten van de usability interviews van Kieskeurig blijkt dat iteratief testen van toegevoegde waarde is. Uit elk interview kwamen nieuwe ervaren knelpunten en aangedragen ideeën voor doorontwikkeling van eindgebruikers naar voren. Vanuit deze bevindingen werd nagegaan welke feature doorontwikkeld moest worden en welke specifieke aandacht moest krijgen in een nieuwe usability testronde. De verkregen informatie uit de interviews fungeerden daarmee ter inspiratie voor het ontwikkelen van nieuwe functionaliteiten en om A/B-‐testen uit te zetten. Vooral het benchmarking onderzoek bleek daarin van grote toegevoegde waarde. Het vergelijken van Kieskeurig.nl met concurrerende websites leverden veel inspiratie op. Deze resultaten onderstrepen de conclusie van Hornbæk (2009): usability interviews zouden niet alleen ingezet moeten worden om knelpunten (bugs) op te sporen, maar juist ook om inspiratie op te doen en input te verkrijgen voor verder kwantitatief onderzoek zoals A/B-‐testen. In welke sprint de resultaten verwerkt worden, hangt af van de ontwikkelfase waarin het product zich bevindt en het productstadium (zie paragraaf 5.1.2) en de mate van betrokkenheid vanuit het Scrumteam (zie paragraaf 5.2.3). Hieruit valt een patroon op te maken waarmee de werkprocessen van het UX-‐research team en het Scrumteam met elkaar geïntegreerd kunnen worden (zie figuur 5).
28
Figuur 5: Iteratief UX-‐research uitvoeren binnen Scrumproces. De sprints binnen het Scrumproces bestaan uit twee weken. Iteratief testen kan door tweewekelijks te testen, maar ook door maandelijks te testen. Tweewekelijks testen is geschikt voor producten die zich in de ontwerpfase bevinden, omdat er dan veel nieuwe features ontwikkeld en getest moeten worden. De resultaten uit de usability interviews kunnen dan nog in dezelfde sprint verwerkt worden. Dit was het geval bij de Duckworld Adventure game. Na de lancering van het product, als het product zich in de laatste ontwikkelfase bevindt, is maandelijks testen geschikt om het product verder te optimaliseren. Dit was het geval bij Kieskeurig. Er zit dan steeds een extra sprint tussen de interviews waarin de resultaten verwerkt kunnen worden. Het is hierbij wel belangrijk dat het betreffende Scrumteam ruimte in de planning maakt voor het verwerken van de resultaten in de sprints. Iteratief testen is overigens vooral geschikt voor producten die dagelijks of wekelijks nieuwe content plaatsen en tweewekelijks of maandelijks nieuwe of doorontwikkelde features lanceren. Hierbij valt te denken aan webshops, nieuwssites en vergelijkingssites. Voor producten die in een mindere mate verandering ondergaan, is iteratief testen minder relevant.
5.1.2 Integratie werkprocessen vereist geen parallelle (1-‐op-‐1) iteraties Het UX-‐research team werkt niet zoals het Scrumteam met sprints. De tijd die nodig is voor de voorbereiding, de uitvoering en een (uitgebreide) rapportage van een usability interview voor Kieskeurig is gemiddeld een maand en voor de overige UX-‐methoden/tools is gemiddeld drie weken nodig. Het scrumproces van Kieskeurig bestaat daarentegen uit sprints van twee weken. Het uitvoeren van een usability interview binnen elke sprint blijkt niet werkbaar bij Kieskeurig. Vanuit de literatuur kan dit als een belemmerende factor gezien worden voor de integratie van UX-‐research en Scrum. Vanuit de praktijk bij Kieskeurig blijkt echter dat het niet overeenkomen van de werkprocessen geen belemmerende factor was. Allereerst, omdat er tijd was ingepland door de conversiemanager voor het opstellen
29
van een uitgebreide rapportage naar aanleiding van de usability interviews. De conversiemanager had hier ook tijd op kunnen besparen door te kiezen voor een rapportage die sneller gaat, waarbij de kwaliteit geborgen blijft (McGinn en Chang, 2013). Daarnaast zijn alle onderzoeken uitgevoerd in de laatste ontwikkelfase op een werkende website die live staat. De verkregen resultaten waren nuttig voor productoptimalisatie, maar de voortgang van de ontwikkeling van de website was er niet van afhankelijk. De resultaten werden vaak pas twee tot vier sprints na het onderzoek opgepakt, mits er voldoende capaciteit binnen het development team was en het voldoende prioriteit had. Om de werkprocessen beter op elkaar af te laten stemmen, zou het proces van het ontwerpen van de website, of functionaliteiten ervan, door UX-‐designers en het testen van het ontwerp (prototype) door UX-‐researchers met behulp van een expert review, een sprint voor moeten lopen op het proces van de technisch developers. Op deze manier kan een nieuw ontwerp (prototype) door het UX-‐research team getest worden en deze bevindingen kunnen dan meegenomen worden in de sprint van de technisch developers (Nielsen, 2008b). Het voorbeeld van de usability interviews die elke twee weken zijn uitgevoerd voor de Duckworld Adventure game, is hier een goed voorbeeld van. Om het werkproces van het UX-‐research team te verkorten, werden in deze casus vooraf de interviews ingepland. Hierdoor kon de werving van proefpersonen aansluitend door kon gaan en werd voor de rapportages een snellere methode toegepast (meer hierover in paragraaf 5.3.2).
5.2 De rolverdeling
5.2.1 Een dedicated UX-‐researcher binnen het Scrumteam is niet nodig Het Scrumteam van Kieskeurig is multidisciplinair, maar de UX-‐researcher vormde geen onderdeel van dit team. Volgens Salah et al. (2014) is een van de succesfactoren voor een succesvolle integratie tussen UX-‐research en Scrum dat de UX-‐researcher dedicated is. Oftewel, dat de rol van de UX-‐researcher geïntegreerd is binnen het Scrumteam. Uit de case van Kieskeurig blijkt dat het dedicated aanstellen van een UX-‐researcher niet noodzakelijk is, omdat er gedurende een sprint niet voor elke dag werk is voor een UX-‐researcher. Om te voorkomen dat het niet dedicated aanstellen van een UX-‐researcher wel voor een belemmering zorgt, is het belangrijk dat de UX-‐researcher geïnformeerd wordt over het proces en de stand van zaken met betrekking tot de ontwikkeling van het product. Dit kan door de rol van de UX-‐researcher gedeeltelijk dedicated te maken waarbij de UX-‐researcher twee tot drie keer per week aanwezig is bij de stand-‐up van het Scrumteam en fysiek in dezelfde ruimte als het Scrumteam te werkt. Een andere mogelijkheid is door het contact tussen de UX-‐researcher en het Scrumteam via een contactpersoon van het Scrumteam te laten verlopen. Dit was het geval bij Kieskeurig, waarbij het contact verliep via de conversiemanager van Kieskeurig. De conversiemanager deelde informatie over het Scrumproces, de conversie en overige stand van zaken van de website van Kieskeurig. Dit was erg belangrijk om focus te houden in de onderzoeken.
5.2.2 UX-‐researcher gedurende het gehele ontwikkeltraject aanhaken Uit de resultaten blijkt dat de UX-‐researcher pas in de laatste ontwikkelfase door de conversiemanager van Kieskeurig is aangehaakt voor onderzoek. Om ervoor te zorgen dat het eindproduct zo goed mogelijk voldoet aan de verwachtingen en wensen van een
30
gebruiker, moet de gebruiker echter gedurende het gehele ontwikkeltraject betrokken worden (Maguire, 2001). Het betrekken van de gebruiker tijdens het gehele traject bespaart bovendien kosten. Aanpassingen verwerken in een product dat al zo goed als af is, kost ten slotte meer tijd en capaciteit dan in een prototype van een product (Kujala, 2002). De UX-‐researcher zou in plaats van tijdens de laatste ontwikkelfase, die eigenlijk ter evaluatie en optimalisatie van het product is bedoeld, al eerder in het ontwikkeltraject aangehaakt moeten worden door het Scrumteam. De casussen van Duckworld Adventures game en de nieuwssite NU.nl zijn voorbeelden waarbij de UX-‐researcher in een eerdere ontwikkelfase werd aangehaakt, waardoor aanpassingen makkelijk en snel in dezelfde of eerstvolgende sprint opgepakt konden worden.
5.2.3 Hoge betrokkenheid van het Scrumteam bij UX-‐research is belangrijk De mate van betrokkenheid vanuit het Scrumteam heeft effect op de kans dat de resultaten uit de onderzoeken opgepakt worden. Hoe hoger de betrokkenheid, des te meer het Scrumteam zich eigenaar voelt van de resultaten en het oppakken van de resultaten meer prioriteit krijgen. Bovendien is de betrokkenheid van het scrumteam belangrijk om te laten zien waarom een usability onderzoek cruciaal is en hoe de stakeholder een nóg beter product kan maken (Ruigrok | Netpanel, 2014). De betrokkenheid vanuit het Scrumteam van Kieskeurig was niet erg hoog. Mogelijk is dit een reden waarom resultaten die voortkwamen uit de usability interviews weinig prioriteit kregen van het Scrumteam. Bij de casus van Duckworld Adventures game was de betrokkenheid vanuit het Scrumteam wel hoog en werden resultaten wel snel opgepakt in de sprint. Het creëren van een hoge betrokkenheid vanuit het Scrumteam is daarom belangrijk. Om de betrokkenheid te verhogen zou er tijdens elk usability interview naast de conversiemanager en product-‐eigenaar minimaal één persoon uit het development team aanwezig moeten zijn en het liefst nog meer en een UX-‐designer. Verder is het belangrijk dat er iemand vanuit het management aanwezig is, omdat het management eindverantwoordelijk voor het product is en alle beslissingen neemt. Op deze manier worden het development team en het management eigenaren van de usability interviews en krijgen de resultaten meer prioriteit met als gevolg dat resultaten sneller in een sprint worden opgepakt.
5.3 UX-‐methoden/tools Er moet een balans zijn tussen enerzijds de nauwkeurigheid waarmee de usability van een product onderzocht kan worden en anderzijds de tijd en kosten die daarvoor nodig zijn. Snelle methoden, zoals discount usability, ontstaan vaak door alles wat niet nodig lijkt of sneller kan, eruit te laten (Nielsen, 1994). Een uitdaging voor het samengaan van UX-‐research met Scrum is het beperken van de hoeveelheid tijd die nodig is zonder dat dit ten koste gaat van de kwaliteit van het onderzoek (Rannikko, 2011).
5.3.1 Agile UX-‐methoden/tools geen vereiste, kwaliteit wel De tijd die voor de UX-‐methoden/tools uit het portfolio van Sanoma nodig is voor het voorbereiden, uitvoeren en analyseren is, op de expert review na, twee weken tot een maand (zie bijlage 1). Vanuit de gedachte dat Scrumprocessen snel zijn en bestaan uit sprints van twee weken, zou dit een belemmerende factor kunnen zijn. Uit de praktijk blijkt dat dit geen belemmerende factor hoeft te zijn. Bij Kieskeurig werd er gekozen voor kwaliteit, bijvoorbeeld door het opstellen van een uitgebreide rapportage, in plaats van snelheid.
31
De kwaliteit van de onderzoeken voor Kieskeurig is af te leiden uit de toegevoegde waarde van de onderzoeken (paragraaf 4.3.3) en de verhoogde conversie. Bij elk nieuw usability interview kwamen nieuwe knelpunten van de website van Kieskeurig boven water. De resultaten die verkregen waren uit de feedbacktool kwamen overeen met de resultaten uit de reeks usability interviews en waren daarmee een bevestiging van eerdere uitkomsten. Hornbæck (2009) benadrukt tevens in zijn artikel, waarin hij een kritische blik geeft op de kwaliteit van usability evaluatie methoden, dat het inzetten van meerdere UX-‐methoden/tools tegelijk (ook wel triangulatie genoemd) meerwaarde heeft om bevindingen te staven en meer prioriteit te kunnen geven. Een opvallende bevinding uit de usability interviews was dat er geen knelpunten waren gevonden met betrekking tot de service quality van Kieskeurig. Uit de interviews bleek dat gebruikers de service van Kieskeurig niet gebruiken; mensen bellen liever direct met de webshop. Het interview heeft hiermee inzicht gegeven in de prioriteit van deze feature. In een nieuwe testronde zou er daarom nagedacht moeten worden over het doel van de service quality, zodat deze gemeten kan worden. Het zou interessant zijn om exact te kunnen achterhalen welke aanpassing tot een verhoging in de conversie heeft geleid, maar dat is erg moeilijk omdat ook externe factoren hier invloed op kunnen hebben. Een A/B-‐test is de enige methode om enig inzicht te krijgen in wat een aanpassing van een feature met de conversie doet. Usability interviews zijn vooral gericht op het verhelpen van bugs en om input aan te leveren voor bijvoorbeeld een A/B-‐test.
5.3.2 Alternatieve UX-‐methoden/tools die agile en kwaliteit verenigen Er zijn alternatieve UX-‐methoden/tools die de hoeveelheid tijd die nodig is voor UX-‐research inkorten, zodat ze meer geschikt lijken binnen een Scrumproces maar wel kwaliteit leveren. Voor de casus van de Duckworld Adventures game is bijvoorbeeld gebruik gemaakt van de RITE + Krug methode. Deze methode is een variant op een usability interview waarbij de tijd die nodig is voor de rapportage flink ingekort wordt (McGinn en Chang, 2013). RITE + Krug is bedoelt voor het onderzoeken van prototypen, maar kan ook toegepast worden op werkende websites. Bij deze methode worden zes respondenten geworven die in een lab-‐omgeving een uur taken uitvoeren op een werkende website terwijl ze hardop denken. Stakeholders zijn verplicht om aanwezig te zijn op de testdag. In de observatieruimten kijken zij mee en na de laatste respondent worden de belangrijkste bevindingen samen met de UX-‐researchers besproken. Als er prototypen getest worden, dan wordt het prototype tussen de sessies door aangepast naar aanleiding van gevonden belemmeringen door de gebruikers. Als er op een werkende website wordt getest is dit niet werkbaar. Afhankelijk van de tijd die beschikbaar is vanuit de stakeholder wordt er na het onderzoek een korte of uitgebreide rapportage opgeleverd door de onderzoeker (McGinn en Chang, 2013). RITE + Krug is naar tevredenheid toegepast bij Duckworld Adventure game. Het Scrumteam had direct na het testen alle bevindingen en verbeterpunten op papier en konden er de dag erna direct mee aan de slag. Hieruit blijkt dat het uitvoeren van een versnelde usability test haalbaar is en tijd scheelt.
32
Nielsen (1994) is voorstander van discount usability engineering. Een methode om snel, goedkoop en kleinere usability onderzoeken uit te voeren. Discount usability engineering is gebaseerd op het gebruik van de volgende drie technieken (Nielsen, 1994):
• Prototypen (Nielsen, 1994 noemt dit scenarios): het testen van een simpele versie van een product, ook wel papieren mockups.
• Vereenvoudigde hardopdenkmethode: gebruikers denken hardop terwijl ze een taak uitvoeren. De onderzoeker observeert en rapporteert de inzichten in de gedachten van de gebruiker bij het gebruik van het product.
• Heuristische evaluatie: een expert evalueert een product met behulp van opgestelde usability richtlijnen of heuristieken.
Voor discount usability engineering worden vier gebruikers ingezet en geen statistische analyses uitgevoerd. UX-‐research is hierbij niet bedoeld om onderzoeksresultaten en conclusies te verkrijgen die generaliseerbaar zijn (Verhoeven en Van Gemert-‐Pijnen, 2010). Uit de resultaten uit de usability interviews voor Kieskeurig blijkt dat er na vier gebruikers verzadiging in de gevonden problemen ontstond. Dat zou betekenen dat met discount usability de belangrijkste problemen in kaart gebracht kunnen worden. Nielsen (1994) houdt echter geen rekening met respondenten die uitvallen en daarom is het verstandiger om voor elk usability interview zes proefpersonen uit te nodigen zoals bij de interviews voor Kieskeurig is gedaan. Een andere snelle UX-‐methode is guerilla usability testing (UX booth, 2013). In feite komt deze methode erop neer dat je met het product naar buiten gaat en willekeurig mensen benaderd met de vraag of ze willen meewerken met een usability test. Het doel van guerilla usability testing is dat je binnen een dag gebruikerservaringen hebt gemeten en geanalyseerd (UX booth, 2013). Het uitvoeren van guerilla usability testing kan met behulp van de productstadia wireframes, mockups en prototypen, maar ook met werkende websites. Dit is een snelle methode om gebruikersonderzoek uit te voeren en daarom geschikt binnen een agile werkmethode (Nielsen, 1994; Loranger, 2014). In bijlage 15 staat een uitgebreide omschrijving van wireframes, mockups en prototypen. Guerilla usability testing met mockups is toegepast voor de app Swipe & Shop. Binnen twee uur was er voldoende feedback van gebruikers verzameld die dezelfde dag nog meegenomen kon worden in de huidige sprint waar de app zich in bevond. Het is bij deze methode wel belangrijk dat er vooraf goed wordt nagedacht over de locatie waar het onderzoek wordt afgenomen. Deze moet rustig zijn en een plek zijn waar potentiële gebruikers van het product zich hoogstwaarschijnlijk verblijven.
5.4 UX-‐research integreren binnen Scrum Volgens Blomkvist (2005), UX-‐designer en wetenschappelijk onderzoeker binnen human-‐computer interaction, zijn er drie verschillende manieren om UX-‐research met agile te integreren:
• User experience research toepassen binnen een agile software ontwikkelproces. Organisaties die al met een agile methode werken hoeven hun huidige werkmethode minimaal te veranderen, maar zorgen er wel voor dat het product gebruiksvriendelijk is. Het nadeel is dat de rol van een UX-‐researcher mogelijk niet
33
optimaal uit de verf komt, omdat onderzoeken onafhankelijk van het Scrumteam uitgevoerd worden.
• Agile software ontwikkeling toepassen binnen het proces van UX-‐research. Hiermee wordt het proces van UX-‐research meer agile, maar wordt er niet zozeer een veelomvattend software ontwikkelproces gecreëerd.
• Het combineren van UX-‐research en agile software ontwikkeling op een gebalanceerde manier door een nieuw hybride software ontwikkelproces te creëren waarbij beide benaderingen geïntegreerd worden.
De integratie van UX-‐research en het Scrumproces van Kieskeurig verloopt op dit moment op de eerste manier die Blomksvist (2005) noemt. In een ideale situatie werkt het UX-‐research team en een Scrumteam volgens de derde manier, zodat de integratie in balans is. Gezien de commerciële en snelle aard van de organisatie, waarbij grote veranderingen lastig zijn door te voeren, lijkt de eerste manier het beste om mee te beginnen: UX-‐research integreren binnen Scrum. De volgende stap is om te werken volgens de derde manier. Om UX-‐research en Scrum succesvol te integreren zijn op basis van het onderzoek een richtlijn en adviezen opgesteld om van de belemmerende factoren, bevorderende factoren te maken. Deze richtlijn en adviezen zijn onderverdeeld in de drie eerder genoemde thema’s.
• Werkproces: De werkprocessen van het UX-‐research team en het Scrumteam komen niet met elkaar overeen. Om de werkprocessen met elkaar te integreren moet er iteratief getest worden. Hierbij is het belangrijk dat het proces van het ontwerpen van de website, of de functionaliteiten ervan, door UX-‐designers en het testen van het ontwerp door UX-‐researchers een sprint voorloopt op het proces van de technisch developers. Verder is het belangrijk dat het Scrumteam tijd vrijmaakt in de planning om de resultaten te verwerken.
• Rol UX-‐researcher: Het dedicated aanstellen van een UX-‐researcher blijkt niet noodzakelijk, maar het is wel belangrijk dat de UX-‐researcher geïnformeerd wordt over het proces en de stand van zaken met betrekking tot de ontwikkeling van het product. Door de rol van de UX-‐researcher gedeeltelijk dedicated te maken, wordt hieraan tegemoet gekomen. Verder zal het UX-‐research team tegemoet moeten komen aan de tijdsplanning van het agile ontwikkelproces en daarom al in een zo vroeg mogelijk productstadium betrokken moeten worden in het ontwikkelproces. Om ervoor te zorgen dat resultaten uit de onderzoeken prioriteit krijgen en daardoor sneller opgepakt worden, moet de betrokkenheid van het Scrumteam en management hoog zijn. Tijdens elk usability interview zou er naast de conversiemanager en product-‐eigenaar, minimaal één persoon uit het development team, een UX-‐designer en iemand uit het management aanwezig moeten zijn, zodat ze zich eigenaar gaan voelen van de usability interviews en een hogere prioriteit geven aan de gevonden knelputen.
• UX-‐methoden/tools: Agile UX-‐methoden/tools zijn geen vereiste, maar de kwaliteit van de onderzoeken wel. Voor het uitvoeren van UX-‐research binnen een Scrumproces krijgt kwaliteit de voorkeur boven snelheid. Is snelheid vanuit de stakeholder gewenst, dan kan een UX-‐researcher alternatieve UX-‐methoden/tools
34
die agile en kwaliteit verenigingen inzetten zoals RITE + Krug methode, discount usability engineering en guerilly usability testing.
De bovengenoemde richtlijn en adviezen zijn gevormd naar aanleiding van de resultaten uit de participerende observatie, waarbij de focus van de observatie op Kieskeurig lag. De adviezen zijn generaliseerbaar voor vergelijkbare websites zoals Kieskeurig.nl. Dit zijn websites die net als Kieskeurig onderhevig zijn aan veel veranderingen, waarbij dagelijks nieuwe content wordt toegevoegd en na elke sprint nieuwe features worden gelanceerd.
5.5 Terugblik uitvoering onderzoek Niet alle data die verkregen is uit de participerende observatie is gestructureerd vastgelegd en geanalyseerd. De omgeving waarin het onderzoek is uitgevoerd was erg complex en snel van aard, waardoor er niet altijd tijd was voor een verslaglegging van de observaties. Patton (2002) stelde de spanningsvelden die binnen organisaties spelen en van (negatieve) invloed kunnen zijn op het onderzoek en de vastlegging van de data al eerder in zijn artikel aan de orde. Ondanks dat er rekening is gehouden met de mogelijke spanningsvelden, heeft het toch invloed gehad op de vastlegging van de data. De onderzoeker heeft niet alles tot in detail nauwkeurig kunnen analyseren en notuleren. Het onderzoek vraagt echter om het schetsen van de grote lijnen van het werkveld en is kwalitatief van aard. De participerende observatie bleek de meest valide en enige werkbare methode om het onderzoek uit te voeren. Toch is het een vorm van een expert review, waarbij de kans bestaat dat het veld vanuit één perspectief bekeken wordt. Om hieraan tegemoet te komen, is getracht om andere stakeholders en cases binnen Sanoma dan Kieskeurig als referentiekader te gebruiken in de beschrijving van de case Kieskeurig.
5.6 Vervolgonderzoek Het is van belang dat de richtlijn en adviezen voor UX-‐research binnen een agile werkmethode zorgen voor een gestandaardiseerd werkmodel dat in grote lijnen voor de ontwikkeling van elk product toepasbaar is. De richtlijn en adviezen zijn opgesteld op basis van hoofdzakelijk de case van Kieskeurig. Het zou interessant zijn om in een vervolgonderzoek deze richtlijn en adviezen toe te passen bij de ontwikkeling van een product dat zich in een andere ontwikkelfase bevindt dan waarin Kieskeurig zich bevond. De agile UX-‐methoden/tools zoals RITE + Krug, discount usability engineering en guerilla usability testing zouden in een vervolgonderzoek kunnen worden ingezet. Met behulp van een evaluatie kunnen vervolgens de opgestelde richtlijn en adviezen geoptimaliseerd worden en mogelijk nog praktischer ingezet worden. Ten slotte is het nuttig om op de hoogte te blijven van nieuwe ontwikkelingen en methoden. Het gebruik van smartphones, tablets en notebooks neemt bijvoorbeeld erg toe en daar gelden mogelijk weer aangepaste richtlijnen voor UX-‐research binnen een Scrum ontwikkeltraject voor.
35
Literatuurlijst Baarda D.B., de Goede M.P.M., Teunissen J. (2005). Basisboek Kwalitatief Onderzoek (2e druk). Groningen: Noordhoff Uitgevers B.V. Beedle, M., Devos, M., Sharon, Y., Schwaber, K., Sutherland, J. (1999). SCRUM: An extension pattern language for hyperproductive software development. In Harrison, N., Foote, B. en Rohnert, H. Pattern language of Program design 4 (1-‐18). Boston: Addison Wesley. Verkregen op 19 oktober, 2014, via: http://hillside.net/plop/plop98/final_submissions/P49.pdf Beerthuyzen, M. (2014). Waarom communicatie rondom je A/B-‐test net zo belangrijk is als significantie. Verkregen op 5 december, 2014, via: http://www.marketingfacts.nl/berichten/waarom-‐communicatie-‐rondom-‐je-‐a-‐b-‐testen-‐net-‐zo-‐belangrijk-‐is-‐als-‐significa Bevan, N., Kirakowski, J. en Maissel, J. (1991). What is usability? Proceedings of the 4th International conference on HCI in Stuttgart. Blomkvist, S. (2005). Towards a model for bridging agile development and user-‐centred design. In A. Seffah, J. Gulliksen en M.C. Desmarais (Eds.), Human-‐centred software engineering – Integrating usability in the development process (p. 217-‐244). Dordrecht, The Netherlands: Springer. Brown, D. (2014). Agile UX is Collaboration: Mastering the Method. User Experience Magazine, 14(1). Verkregen op 31 oktober, 2014, via: http://uxpamagazine.org/agile-‐ux-‐is-‐collaboration/ Butt, S.M., Onn, A., Butt, M.M. en Tabassam, N. (2014). Towards a Model-‐based framework for integrating Usability techniques in Agile software model. Advances in intelligent systems and computing. Vol. 287, p. 561-‐570. Garrett, J.J. (2011). The elements of User Experience: User-‐centered Design for the Web and Beyond (second edition). Berkeley: New Riders division of Pearson Education. Gemert-‐Pijnen van, J.E.W.C., Nijland, N., Limburg, van, M, Ossebaar, H.C., Kelders, S.M., Eysenbach, G. en Seydel, E.R. (2011). A holistic framework to improve the uptake and impact of eHealth technologies. Journal of Medical internet research, vol. 13, p.1. Goward, C. (2013). How to prioritize conversation rate optimization tests using PIE. Verkregen op 27 november, 2014, via: http://www.widerfunnel.com/conversion-‐rate-‐optimization/how-‐to-‐prioritize-‐conversion-‐rate-‐optimization-‐tests-‐using-‐pie
36
ISO 9241, Ergonomic Requirements for Office Work with visuel display terminals: part 11: Guidance on Usability, 1998. Kujala, S. (2002). User involvement: a review of the benefits and challenges. Behaviour & information technology, vol. 22, nr. 1, 1.-‐16. Larman, C. (2003). Agile and iterative development: A manager’s guide. Addisson-‐Wesley Professional. Loranger, H. (2014). Doing UX in an agile world: case study findings. Verkregen op 2 december, 2014 via: http://www.nngroup.com/articles/doing-‐ux-‐agile-‐world/ Maguire, M. (2001). Methods to support human-‐centred design. Int. J. Human-‐Computer Studies 55, 587-‐634 Martin, B. En Hanington, B. (2012). Universele ontwerpmethoden. Amsterdam: BIS Publishers. McGinn, J. en Chang, A. (2013). RITE + Krug: A combination of Usability test methods for agile design. Journal of Usability studies. Vol. 8-‐3, p. 61-‐68. Nielsen, J. (1994). Guerilla HCI: Using discount usability engineering to penetrate the intimidation barrier. Verkregen op 31 oktober, 2014, via: http://www.nngroup.com/articles/guerrilla-‐hci/ Nielsen, J. (1994). Usability Engineering. San Francisco: Morgan Kaufmann Publishers Nielsen, J. (1997). Discount usability for the web. Verkregen op 2 december, 2014, via: http://www.nngroup.com/articles/web-‐discount-‐usability/ Nielsen, J. (2008a). Bridging the Designer-‐user gap. Verkregen op 28 september, 2014, via: http://www.nngroup.com/articles/bridging-‐the-‐designer-‐user-‐gap/ Nielsen, J. (2008b). Agile development projects and usability. Verkregen op 5 december, 2014, via: http://www.nngroup.com/articles/agile-‐development-‐and-‐usability/ Nielsen, J. (2012). Usability 101: introduction to usability. Verkregen op 28 september, 2014, via: http://www.nngroup.com/articles/usability-‐101-‐introduction-‐to-‐usability/ Nielsen, J. en Norman, D. (2012). The definition of user experience. Verkregen op 24 oktober, 2014, via: http://www.nngroup.com/articles/definition-‐user-‐experience/
37
Patton, M. Q. (2002). Utilization-‐focused evaluation. Evaluation models (pp. 425-‐438) Springer. Rannikko, P. (2011). User-‐Centred Design in Agile Software Development. Verkregen op 31 oktober, 2014 via: http://www.pirkkarannikko.com/agile-‐ucd.html Ruigrok | Netpanel (2014). Stakeholders enthousiasmeren voor UX/usability onderzoek. Verkregen op 5 december, 2014, via: http://www.ruigroknetpanel.nl/usabilityonderzoek/ Salah, D., Paige, R. en Cairns, P. (2014). A systematic literature review on agile development processes and user centered design integration. Proceedings of the 18th Internation Conference on Assessment in Software Engineering. Article No. 5. Salvador, C., Nakasone, A., Pow-‐Sang, J.A. (2014). A systematic review of usability techniques in Agile Methodologies. Proceedings of the 7th Euro American Conference on Telematics and Information Systems. Article nr. 17 Schipani, D.S. (2012). Case study method. In Miller-‐McLemore, B. J. The Wiley-‐Blackwell Companion to Practical Theology (p. 91). Oxford: Blackwell Publishing Ltd. Simon, P.D. (2013). The art of guerilla usability testing. Verkregen op 14 november, 2014, via: http://www.uxbooth.com/articles/the-‐art-‐of-‐guerrilla-‐usability-‐testing/ Solingen, van, R. en Rustenburg, E. (2010). De kracht van Scrum. Amsterdam: Pearson Education Benelyx. Treder, M. (2012). Wireframing, prototyping, mockuping – What’s the difference? Verkregen op 3 december, 2014, via: http://designmodo.com/wireframing-‐prototyping-‐mockuping/ Verhoeven, F. en Van Gemert-‐Pijnen, J. (2010). Discount User-‐Centered e-‐Health Design: A quick but not dirty method. LNCS, 6389, pp. 101-‐123.
Top Related