{ SCRUMUCD} Adviesrapport voor E-ID internet strategies. Don R. Munter 14 juni, 2011

{SCRUMUCD } Adviesrapport voor E-ID internet strategies Don R. Munter 14 juni, 2011

Inleiding

Dit rapport beredeneert vanuit het huidige proces en brengt advies uit over hoe dit proces beter kan. Het tweede gedeelte gaat uit van het ideaalbeeld.

Inleiding E-ID is een organisatie van 50 man groot. Het is van oorsprong een IT-bedrijf, maar heeft er later voor gekozen om een designafdeling op te richten binnen het bedrijf. De ambitie is om binnen 5 jaar uit te breiden naar 150 man, waar 15 man de designafdeling zullen vertegenwoordigen. Uit interviews met designers van E-ID heb ik een paar belangrijke conclusies kunnen trekken aangaande het design- en ontwikkelproces. Deze conclusies, de opvattingen van designers, zijn te vergelijken met conclusies uit mijn literatuuronderzoek . Zo kwam er uit dat designers, ten eerste, moeite hebben met werken in een agile omgeving vanwege de snelheid. Ten tweede is het belangrijk om gebruikers te betrekken in het design- en ontwikkelproces, maar hoe, waar, wanneer en hoeveel is nog de vraag.

Probleemstelling

Onderzoeksmethode

Hoe kunnen UCD methoden worden ingezet in een agile werkomgeving, en vooral welke? Wat is de rol van de designer in agile Scrum? Wat als er, in plaats van 2, over vijf jaar 15 designers zijn, hoe gaat het dan? En hoe kunnen zij UCD methoden effectief inzetten om bruikbare producten op te leveren? Mijn scriptie concludeerde dat het Scrumproces een belangrijke rol speelt, wil de gebruiker betrokken kunnen worden. Sommige Scrumactiviteiten zijn dan noodzakelijk en zullen worden meegenomen in de adviezen.

Nu E-ID aan het groeien is, en zij steeds meer overtuigd raken van de krachten van gebruikersgericht en bruikbaar ontwerpen, vindt E-ID het tijd om het roer om te gooien. Nu hebben zij echter geen ervaring in het ontwikkelen en ontwerpen waarbij (eind)gebruikers centraal staan. Ook het meten van de softwarekwaliteit is nog een lastige opgaaf.

Voor het adviesrapport zijn er verscheidene doelgroepen onderzocht. Dit is gedaan middels interviews binnen E-ID en bij externe bedrijven.

Er zijn een aantal variabelen waar rekening mee gehouden moet worden. Zo worden er andere UCD methoden gebruikt voor kleine projecten met weinig designers dan bij grotere projecten. Ook het feit of er een parttime UCD’er in het team zit, of dat een team 2 fulltime UCD’ers beschikt, kan de keuze voor het gebruiken van een UCD methode beïnvloeden.

Met dit adviesrapport zal E-ID inzicht krijgen in het ontwerpen en ontwikkelen van software waar gebruikers centraal staan. Ook het inzicht in het ontwikkelen van kwalitatieve software zal een grote meerwaarde bieden aan E-ID.

E-id wilt kwalitatieve en gebruikersgerichte software ontwikkelen door middel van de Scrum ontwikkelmethode.

Doelstelling

E-id de mogelijkheid bieden om kwalita¬tieve software, volgens de Scrum methode, te ontwikkelen door eindgebruikers in het proces te betrekken

Het is belangrijk om te weten wat de huidige ervaringen zijn met agile, Scrum, usability en user-centered design. Naast interviews is er dan ook veel aan literatuurstudie gedaan. Er is volop over geschreven, en deze bevindingen zijn verwerkt in de scriptie en het adviesrapport.

Designer vs. Developer De kloof tussen ontwerpers en ontwikkelaars bestaat al een tijdje. F. Haak, een ontwerper bij E-ID, heeft hier ook ervaring mee: “als ik wat ontwerp en ik lever het op aan de ontwikkelaars, waar ik vervolgens een tijd niets van hoor, moet ik maar zien wat er van het ontwerp is overgebleven”. Nu agile verwacht dat de teams zelfsturend zijn en een hoog communicatieniveau bevatten, is ook de sociologie en psychologie van beide disciplines belangrijk.

Algemeen advies

Eén struikelblok is het kennisgehalte en de manier waarop ontwerpers en ontwikkelaars denken. Om het gat te dichten moeten ontwikkelaars in staat zijn ook holistisch na te denken. Zij moeten de volgende instelling hebben:

Het adviesrapport is geschreven naar aanleiding van twee situaties: de huidige en de ideale. Dit neemt echter niet weg dat er sommige activiteiten en rollen zijn die overal toepasbaar zijn. Zo zijn er enkele adviezen die bij elke situatie passen.

Het belang van UCD en Usability Het onderzoek heeft uitgewezen dat een continue focus op gebruikers hebben resulteert in een bruikbaar product. Een product dat effectief, efficiënt en naar tevredenheid gebruikt kan worden. Ik raad dan ook sterk aan om gebruikers daadwerkelijk te betrekken in het proces. Nogmaals de redenen: UCD zorgt ervoor dat de tijd die aan ontwikkeling wordt besteedt reduceert. Door vroeg feedback te krijgen hoeven er later geen of weinig veranderingen in het product te komen. Door de bruikbaarheid van het product te gebruiken als unique selling point (USP) zorgen E-ID en de klanten van E-ID ervoor dat ze competitief sterker in de markt staan. Daarnaast zijn gebruikers tevreden en zullen zij regelmatig terugkeren. Dit resulteert in een gedenkwaardig imago, waarbij zowel mond-tot-mond als online communicatie kunnen bijdragen aan meer verkoop of websiteverkeer.

Stel dat de klant een product voor hun eigen werknemers wil - een nieuw systeem om gegvens te beheren bijvoorbeeld - dan kunnen gebruikers beter en sneller met het product aande slag en dit zorgt ervoor dat zij productiever zijn. Het kost minder geld voor trainingen en opleidingen. Het scheelt ook in de tijd voor werknemers die andere collega’s moeten helpen als ze iets niet snappen: dit is nu verleden tijd. Voor klanten met een website of online applicatie zorgt UCD ervoor dat er minder tijd en geld in de supportafdelingen gestoken hoeft te worden. Een bruikbaar product geeft het leven gewoon meer kwaliteit! Gebruikers zijn minder gefrustreert en veel tevredener.

“Why did the chicken cross the road? Developer says: Beceause the requirements said so. The trebuchet was the most efficient method. Oh, she had to get to the other side alive? Where was that in the requirements?”. Om dit te voorkomen is samenwerking essentieel. Zo is het goed mogelijk, en raadzaam, om ontwikkelaars te laten participeren in user-centered design methoden en andere meetings die vooral voor designers zijn opgezet. Op die manier krijgen ontwikkelaars een beter beeld van de werkzaamheden van (user-centered) designers. Daarnaast krijgen ontwikkelaars ook een beter beeld van de requirements van gebruikers. In het uiterste geval kunnen, bij sommige low-fidelity methoden, ontwikkelaars de rol van de UCD’er overnemen. Om achter het mentale model van een gebruiker te komen is cardsorting een geschikte methode. Laat ontwikkelaars een keer zelf moderator zijn. Ook interviewen of fieldresearch is niet bedacht voor designers, het is een algemene methode dat door iedereen uitgevoerd kan worden. Ontwerpers, aan de andere kant, hebben een holistische blik en kunnen users needs omzetten in designs. Maar het ontwerp wil weleens te “lastig” zijn om te realiseren. Daarom is een beter begrip van de techniek noodzakelijk. Immers, als een ontwerp later niet geïmplementeerd kan worden vanwege zijn omvang of omdat de techniek het niet toelaat, kost het op den duur alleen maar meer geld en tijd. Laat ontwerpers dan ook meedoen in dagelijkse ontwikkelfasen. Laat ze meekijken of participeren in discussies en bijeen

komsten. Als ontwerpers kennis van (X)HTML, CSS en javascript hebben is men al een heel eind en vordert dit de doorloop van het project. Voor beide disciplines is het raadzaam om boeken over belangrijke onderwerpen “rond te laten slingeren”. Een goed voorbeeld is design patterns. Design patterns zijn oplossingen voor veel voorkomende problemen. Als ontwikkelaars de touwtjes ergens toch zelf in handen nemen, hebben zij kennis van deze patronen en is de feature weer dichter bij een kans van slagen. Misschien een out of the box idee, maar een kleinschalige bibliotheek opzetten kan wellicht handig zijn.

UCD Rol In agile Scrum heb je, naast het team, 2 belangrijke rollen: de product owner en de Scrummaster. Een UCD’er kan gezien worden als een rol apart, of een specialisatie in die rol, bijvoorbeeld een interaction-, visual- of user experience designer - immers, al die specialisaties kunnen gebruikersgericht te werk gaan. Hugh Beyer schreef in zijn rapport dat een user experience designer niet altijd een vast teamlid is, maar meer een persoon dat bij alle projecten betrokken is. Vooral bij kleine organisaties kan dit vaak voorkomen. Ook de visual designers bij E-ID maken dit mee. Bij een kleine organisatie van 50 man, waarvan 2 designers, is het niet mogelijk om 1 UCD’er per team aan te stellen. Het wordt zeker beperkt als deze UCD’ers alleen visual designers zijn. Het is voor E-ID dan ook raadzaam om de developers kennis te laten maken met designgerelateerde zaken zoals user experience, interaction en interface design, usability engineering en information architecture zoals voorheen besproken. Mede door design patterns en UI frameworks wordt de last die developers dan moeten dragen sterk vermindert. Want nogmaals: als ook developers het nut van UCD weten, kan dit alleen bijdragen aan een positieve sfeer met goede resultaten. Laat developers nogmaals de rol van een UCD’er overnemen zodat zij UCD activiteiten uit kunnen voeren. Standaard usability testen, zoals heuristic evaluations en feature inspections, kunnen zonder problemen door developers worden uitgevoerd. Let er echter wel op dat ze niet het hele vak overnemen, de kans

is namelijk groot dat een UCD’er zich dan gaat afvragen wat hij nog voor waarde heeft. Developers hoeven niet alles te doen, maar zoals algemeen bekend: één test is beter dan géén test. Bij grotere organisaties is het een ander verhaal. Als een UCD’er zijn werk goed wil uitvoeren, is het aan te raden om een UCD specialist aan te wijzen als tweede product owner. De eerste, oorspronkelijke, product owner richt zich op de features van het product, de marketing en verkoop. De tweede product owner richt zich op usability en user experience. Beide product owners moeten goed kunnen samenwerken en samen knopen doorhakken. De UCD’er moet niet de persoon zijn die alleen besluiten neemt, maar een volwaardig teamlid zijn/worden. Het is uiteraard handig om alle teamleden te betrekken bij het onderzoeks- en designproces. Maar de designer moet degene zijn die over usability zaken beslist. Zo moet de designer ook degene zijn die bijvoorbeeld focus groups, design studio’s of andere methoden leiden.

Adviesrapport 50 man

Voor een IT bedrijf bestaande uit 50 man, waarvan ongeveer 35 developers en 2 designers, is het niet mogelijk om een vaste UCD’er per team vast te stellen. Daarom is het ook verstandig om kritische beslissingen te maken over welke UCD en usability methoden gebruikt gaan worden. Dit hoofdstuk gaat in op de huidige situatie van E-ID, een situatie dat ontwerpt op een watervalmanier, en ontwikkelt op een agile manier.

Er zal ingegaan worden op hoe gebruikers in de huidige situatie betrokken kunnen worden en hoe het design meer “agile” kan worden. Belangrijk om op te merken is dat een verandering in het proces veel moeilijkheden met zich mee brengt: denk bijvoorbeeld aan inspanning, nieuwe manieren van werken, andere denkwijzen. Daarom is het noodzakelijk om met kleine aanpassingen te beginnen, net genoeg om gebruikers voldoende in het proces te betrekken. Een andere reden om met kleine aanpassingen te beginnen is dat Scrum niet 100% wordt geïntegreerd in het proces. Het is dan ook niet mogelijk om in het huidige proces alle UCD en usability methoden op te nemen.

Dit hoofdstuk dient als een stap naar de ideale situatie: waar er meerdere designers zijn en waar UCD methoden grootschalig ingezet kunnen worden.

De huidige werkwijze van E-ID lijkt op de zogenaamde designprint, een naam bedacht door Fabrique. Het komt erop neer dat de designfase op een watervalmanier wordt uitgevoerd, maar wel via sprints. Zo worden bijvoorbeeld de eerste twee sprints vrijgehouden voor ontwerp- en deskresearch. Als het onderzoek is verricht en de ontwerpen zijn gemaakt, wordt dit aangeleverd aan de developers, die vervolgens wel met Scrum ontwikkelen. Ondanks menig onenigheid over de manier waarop designers hun werk moeten doen, is dit wel een manier dat in de huidige situatie werkt: er zijn immers nog te weinig designers om in een vast team te zitten. In de huidige situatie laat E-ID wel een kans liggen om gebruikers te betrekken om producten bruikbaarder te maken.

Er is geen twijfel over mogelijk dat projecten moeten beginnen met onderzoek naar gebruikers, requirements, concurrentie en businessdoelen. Zeker bij projecten die interaction design en usability serieus nemen is dit een belangrijke activiteit. Projecten beginnen zonder onderzoek leidt, volgens Jakob Nielsen, tot een onsamenhangende user experience en inconsistente features [1]. De ontwikkeling kan pas beginnen als er een algemeen idee is ontstaan over wat het product moet doen en wie het product gaat gebruiken. Pas dan kunnen user stories worden gemaakt. Voordat het project begint is E-ID met de klant wezen brainstormen over de huidige problemen van een product of nieuwe innovatieve producten. Deze inzichten kunnen worden verkregen door focus groups te houden met personen die het product, of soortgelijke producten, gebruiken. Zo krijgen de klant en E-ID een algemeen idee over wat het product moet gaan worden. De eerste twee designsprints die daarna plaatsvinden kunnen we zien als een uitgebreide variant van de Sprint 0. Een Sprint 0 geeft het team de kans om zichzelf te organiseren, erachter te komen wie de gebruikers zijn en een algemeen idee van de oplossing voor het probleem te creëren. De basis voor alle iteraties wordt in deze fase gedaan, ook wel het BPUF - Big Picture Up Front proces genoemd. Ik stel voor om deze fase aan te pakken met de standaard User-Centered Design fasen – wel een aangepaste variant, want development wordt in iteraties gedaan.

Onderzoek naar gebruikers Volgens Nigel Bevan zijn 3 of 4 focusgroups genoeg om voldoende informatie te krijgen over de gebruiker [2]. Bij een focusgroup wordt er getracht subjectieve informatie te vergaren over wat de gebruiker wil van een product of idee, wat hun percepties, overtuigingen en meningen zijn. Het is daarnaast ook een goede methode om te brainstormen naar nieuwe ideeën, maar vooral ook om achter de businessdoelstellingen te komen van de klant, de algemene visie. Een focusgroup bestaat uit 3 tot 10 personen en ik

raad niet aan om deze in een afgesloten ruimte te houden, maar in een natuurlijke ruimte waar participanten zich gemakkelijk voelen. User interviews zijn een geschikte methode om achter de needs van de gebruiker te komen. Maar net als met focus groups, hebben user interviews ook tekortkomingen. De verschillen in persoonlijkheden van personen is één van deze tekortkomingen. Zo heb je verlegen personen en personen die zich ongemakkelijk voelen als er met hen wordt gepraat, zeker als zij het lastig vinden om producten of diensten af te kraken. Om hier enigszins aan te ontkomen kan er een variant op user interviews worden bedacht: paired interviews (gepaarde interviews) [3]. In plaats van een interviewer en een respondent, zijn er nu twee respondenten die elkaar interviewen, waarbij de moderator ernaast zit en aantekeningen maakt. Met deze methode wordt er veel tijd gewonnen, omdat er in 1 interviewsessie geen uitkomsten van 1 respondent komt, maar van 2. Daarnaast kunnen respondenten zich sociaal verbonden voelen met degene die zij interviewen: zij zitten in dezelfde demografische of organisatorische groep en dit nodigt hen uit om hun visie uit te roepen. Bij gepaarde interviewsessies is het alleen moeilijk om als moderator diep op de antwoorden in te gaan, maar dit sluit niet uit dat de moderator later de interessante respondenten nogmaals kan uitnodigen voor een traditionele user interview. Bij pair interviews is het raadzaam om meerdere paren tegelijkertijd te hebben. Wel moeten er dan ook meer moderators zijn die deze paren observeren en analyseren. Als er genoeg tijd en mogelijk budget beschikbaar is, raad ik aan een simpele variant van contextual inquiry te houden. Designers verplaatsen zich naar de werkomgeving van de (potentiële) gebruiker en kijkt hoe hij zijn werk uitvoert. Tijdens het uitvoeren is het verstandig hem vragen te stellen over wat en hoe hij iets uitvoert. Zo krijgt de designer een idee hoe het product deze taken kan ondersteunen. Een andere methode om achter de needs en doelstellingen van de gebruiker te komen is het uitvoeren van enquêtes en surveys. Het mooie van deze twee methoden is dat ze niet alleen in de designsprints uitgevoerd kunnen worden, maar in alle sprints. Enquêtes en surveys kunnen online worden uitgevoerd - bijvoorbeeld door e-mail, en dat maakt deze twee methoden goedkoop en snel. Ook Skype is een aanrader. Het nadeel is dat gebruikers nog-

1  Nielsen, J. (2008). ‘Agile Development Projects and Usability

2 

3  Ramsay, A. (2011). ‘Paired Interviews’

1. ONDERZOEKSFASE

Om uit te groeien naar een bedrijf waarbij design en development elkaar perfect complimenteren, is het verstandig om UCD methoden onder de knie te krijgen. Het UCD proces bestaat uit de volgende stappen: • Begrijpen en specificeren van de gebruikerscontext; • Requirements specificatie van de gebruiker en organisatie vaststellen; • Produceer ontwerp(oplossingen); • Evalueer ontwerpen ten opzichte van de requirements De fasen in zijn algemeenheid: Onderzoek, Concept, Design, Test.

1.1 Onderzoek Om gebruikersgericht te werken zijn is er een legio aan methoden beschikbaar om hierbij te helpen. Een goede opstap naar de ideale situatie – deel 2 van het rapport – is om deze methoden alvast te gebruiken. Om E-ID niet meteen in het diepe te gooien, maar geleidelijk naar het ideale Scrum UCD proces te begeleiden, is Jakob Nielsen gekomen met discount usability (goedkoop en snel). Dan roep ik zelf de term discount research het leven in, omdat ook onderzoeken snel en goedkoop kan. E-ID begint zijn huidige werkproces met een gesprek met de klant om te brainstormen en een algemene visie te vormen van het product. Ik raad aan dit zeker te behouden. Het is echter ook belangrijk om erachter te komen welke gebruikers het product (gaan) gebruiken, wat hun karakteristieken zijn en wat hun visie van een product is. Focusgroups, surveys, etnografie en interviews zijn hier goede methodes voor.

Bevan, N. (2002). ‘First Steps to User Centred Design’

maals niet goed kunnen articuleren wat zij willen en makkelijk kunnen liegen. Wel geeft het in ieder geval een houvast en een algemeen idee over de needs en karakteristieken van gebruikers. Afhankelijk van de scope van het project is de log analyse een goedkope, doch niet zozeer snelle, methode als het project een redesign bevat. Deze methode legt onder andere de gebruikers’ activiteiten vast en kan natrekken welke feature het meest bezocht wordt. Google Analytics is een goede voorbeeld. Al deze informatie kan worden meegenomen in de taakanalyse. Een taakanalyse analyseert de taken die een gebruiker uitvoert om tot hun doelen te komen. Bij contextual inquiry wordt er direct gekeken naar hoe de gebruiker werkt op dat moment en hoe hij zijn taken uitvoert. Requirements specificeren Alle data die is verkregen uit het onderzoek wordt gedocumenteerd. Deze documenten zijn vaak lang en ongestructureerd. Houdt daarom interpretatiesessies met teamleden. Het team analyseert de data voor elke interview. De interviewer vertelt in chronologische volgorde wat er allemaal is gezegd tijdens de interview, en het team noteert alle belangrijke informatie dat designgerelateerd is. De observaties, belangrijke data, worden in een lijst verwerkt om vervolgens geprint te worden op post-its. E-ID kan deze informatie ook verwerken in Jira, zodat iedereen hier online toegang toe heeft. Veel data verzamelen over de gebruiker kan waardevol zijn, maar soms kan de daadwerkelijke gebruiker uit het oog worden verloren. Om data van gebruikers meer “realistisch” te maken kunnen ze worden omgevormd naar persona’s, een methode dat is voorgesteld door A. Cooper eind jaren ’90. Een persona is geen specifieke gebruiker of een lijst met taken, maar een fictief karakter dat de needs en wants van een grote groep gebruikers representeert. Door hen een gezicht en een naam te geven helpt het de designers en ontwikkelaars deze gebruikers in gedachte te houden. Deze methode verzameld gegevens over de needs, wants, gedragingen, beroep, gezinsverdeling, inkomen, ervaringen, hobby’s en voorkeuren van de gebruiker.

Door tijdens sprints te refereren naar persona’s, helpt dit: • Met het vormen van user stories: “Als Jeroen, projectmanager, wil ik … “; • Het team bij het maken van beslissingen; • Met het prioriteren van user stories Nadat het nodige onderzoek is gedaan, wordt er een dag uitgetrokken om met het hele team naar patronen te zoeken. Deze patronen worden gecategoriseerd en leidt vervolgens tot typische kenmerken van de doelgroep. Nadat de persona’s zijn gemaakt worden er scenario’s opgesteld. Scenario’s zijn korte verhalen over een specifieke gebruiker (de persona) die een specifiek doel met het product heeft. Tien tot 13 scenario’s zijn genoeg. Scenario’s hebben als resultaat een goed begrip over wat voor informatie het product moet beschikken en welke informatie het belangrijkst is. Scenario’s hebben een level van detail, maar het is aan de designers van E-ID om te bepalen welke zij gebruiken – afhankelijk van hun zelfverzekerdheid, maar ook de tijd die beschikbaar is. Een visie over het systeem, product of dienst hebben is essentieel voor het maken van user stories. Zo’n visie geeft vooral antwoorden op de vragen wat het product is en wat het product moet doen. En het is vooral belangrijk dat iedereen op één lijn zit. Een contextual design manier om hierachter te komen is de product vision box. Nadat alle data van de CI is geanalyseerd en de persona’s en scenario’s zijn gemaakt, bouwt het hele team een product vision box. De visie wordt gecreëerd door het hele team: product owner, Scrummaster, designers en developers. Het team ontwerpt/ schetst tezamen een box met een voor- en achterkant. De voorkant bestaat uit een naam, afbeelding, slogan en 4 USP’s (unique selling points). De achterkant beschrijft gedetailleerdere functionaliteiten. Zo’n workshop met participanten is een speelse activiteit. Het bevordert discussies en samenwerking en zorgt ervoor dat participanten recht op hun doel afgaan. Een variant hierop is de product box. Bij de product box draait het vooral om de gebruikers, de klanten van klanten. Het doel is om maximale feedback van gebruikers te krijgen over bestaande producten. Zij ontwerpen zo’n box dat zij zelf zouden kopen. Het team moet zolang mogelijk doorgaan tot er

enkele benaderingen zijn voorgesteld om problemen te verhelpen. Pas dan kan er geëvalueerd worden. Na het maken van de boxen worden deze gepresenteerd aan elkaar. De minder essentiële aspecten worden verwijderd en de belangrijke aspecten worden bij elkaar toegevoegd zodat het 1 geheel wordt. Het komen tot een visie duurt zo’n 1 tot 3 dagen, afhankelijk van de scope van het product en het aantal visies dat gemaakt moet worden. De documentatie, waar agile vanaf wilt, bestaat hier uit de gecreëerde boxen en mede omdat het geschetst is, wordt er niet snel op details in gegaan. Deze onderzoeksfase laat zich ook goed combineren met een conceptfase. Een andere methode om de visie van het product te bepalen en om op nieuwe ideeën te komen is het houden van een brainstormsessie met alle betrokkenen, dus nogmaals de designers, developers, product owner, Scrummaster en stakeholders. Maar hier is het belangrijker dat de eindgebruiker wordt betrokken. Een goede brainstormsessie wordt gehouden met 5 tot 15 man en zij worden van tevoren ingelicht wat het probleem is, zoals hierboven al beschreven. Brainstormen kan op allerlei manieren, maar de meest toegankelijke en gebruikte manier is convergeren en divergeren. Participanten opperen hun ideeën. Deze ideeën worden later geclusterd tot samenhangende blokken, waarna ze in de evaluatiefase worden geëvalueerd en de beste ideeën eruit worden gehaald. E-ID moet hierna vooral zijn user stories op zijn eigen manier maken en documenteren. Het heeft altijd gewerkt, dus is er geen reden om dit te veranderen. Design en concept Nu de requirements van de business en gebruikers zijn verzamelt en een algemeen concept voor het product is neergezet, is het niet alleen belangrijk om een algemene visie te hebben, maar ook een designrichting. Het is voor designers net zo onverstandig om vanuit het niets te gaan ontwerpen als voor developers vanuit het niets te gaan ontwikkelen. Daarom is de zogenaamde Design Studio een goede oplossing. Bij een Design Studio participeert het hele team in het designproces. Voor het huidige werkproces van E-ID raad ik aan om simpel te beginnen. Een Design Studio begint met het

overdragen van informatie dat is voortgekomen uit het onderzoek, zodat alle teamleden hun designs hierop kunnen toespitsen. Hoewel agile niet gek is op documentatie, moet het team toch een lijst ontvangen met stakeholders requirements, data verkregen uit interviews en usability testen (mocht het een redesign van een website zijn) en user stories. Belangrijke informatie, user stories en persona’s worden geplaatst op een white board, zodat iedereen hier op kan terugvallen. Een goed team bestaat uit personen met verschillende achtergronden, zo kan een team van 5 tot 7 man (om orde te kunnen handhaven) bestaan uit een designer, developer, stakeholder en klant, productowner en Scrummaster, en eventueel een eindgebruiker. Het is overigens niet zo dat UCD met de eindgebruiker werken is, maar voor de eindgebruiker. Daarna is het zaak om 3 tot 5 ideeën te schetsen, het liefst niet tijdens een Design Studio, maar buiten werktijd om, en niet meer dan 2 uur lang. Bij aankomst van de Design Studio krijgen alle participanten 2 minuten om hun schetsen uit te leggen, waarna er 8 minuten tijd is om vragen te stellen en opbouwende kritiek te leveren. Nadat alle designs zijn voorgedragen worden zij gegroepeerd op gerelateerde ideeën. Het team kiest de designs uit dat de user en business needs het best opvangt. Onder andere UXD- en IAD’ers houden zich daarna 2 dagen bezig met het maken van prototypes. Een effectieve manier om alle voorgaande deliverables te evalueren is dus prototyping, en dan met name low-fidelity. Een veelgebruikte low-fi prototype is in de vorm van papier: paper prototyping. Gebruikers kunnen door een paperprototype heen navigeren en snel eventuele problemen opsporen. Het mooie van deze prototype is dat, als designers (of developers) erbij zitten, er meteen aanpassingen op dezelfde prototype gemaakt kunnen worden – RITE (rapid iterative testing en evaluation). Daarnaast kost het weinig geld en tijd en is de drempel om zo’n prototype weg te gooien niet zo groot. Een andere vorm van prototyping is het maken van HTML/CSS mockups. Het is vaak beter en sneller om hiervoor de tool Axure voor te gebruiken. Ik raad aan om hier developers bij te betrekken, omdat zij dan meteen aanpassingen kunnen doen in een werkende HTML/CSS mockup; tenzij de designer ook front-end kennis heeft (wat raadzaam is).

2. DEVELOPMENT Een Sprint 0 wil niet zeggen dat developers niets te doen hebben. Deze fase stelt de developers in staat om het grondwerk op orde te krijgen. Zo kunnen developers vast de technische infrastructuur, de back-end en de database neerzetten. Tijdens de development hoeven designers ook niet stil te zitten. Agile draait om een goede sfeer, goed teamverband en een nauwe samenwerking. Designers moeten developers bij staan tijdens het developen, ook zij moeten in een gezamelijke Scrumroom zitten. Het maakt niet uit of het designteam of de UCD’er op dat moment bij een ander project is betrokken, de UCD’er moet als communicatielink worden beschouwd en over usability zaken kunnen beslissen. Gebruikers betrekken tijdens developmentsprints Een kans dat E-ID moet aangrijpen is het betrekken van gebruikers tijdens de development sprints. Discount usability testmethoden zijn een geschikte manier om snel en goedkoop producten te testen. Omdat E-ID een IT bedrijf is, zijn ze vooral bezig met ontwikkeling van websites. Pas sinds kort is er een designafdeling ontstaan. Van de 6 á 7 projecten, zijn de 2 designers maar bij 3 projecten betrokken. Op dit moment is het voor de 2 designers nog mogelijk om meerdere projecten bij te staan. Ik raad dan ook aan om één designer per project aan te stellen als communicatielink tussen de product owner, Scrummaster en het developmentteam. Daarnaast moeten developers voldoende informatie krijgen over UCD en usability methoden, zodat zij ook een steentje bij kunnen dragen. De usability van websites en applicaties kan worden getest door gebruikers, maar ook door developers en designers zelf. Nu al het voorwerk gedaan is, de designs opgeleverd zijn en wellicht UI frameworks zijn gemaakt is het tijd om het product te ontwikkelen. User stories zijn gecreëerd om de sprints in te delen. Ik raad aan om de sprints in te delen in vaste componenten van de website, bijvoorbeeld per pagina of feature. Aan het eind van de sprint moeten deze componenten worden getest. Omdat in dit huidige werkproces geen zorgen hoeft worden gemaakt over de holistische blik, stel ik voor de usabilitytesten de eerste week van de volgende sprint uit te voeren. Dus: de features worden in

sprint n gemaakt en de usabilitytest voor die features wordt in de eerste week van sprint n+1 uitgevoerd. Deze usabilitytesten kan op veel manieren en nu is het wel handig om meteen de goede methoden te gebruiken. De eerste methode die eigenlijk door de hele sprint heen moet worden gehanteerd is de heuristic evaluation. Heuristic evaluations zijn lijsten met usability richtlijnen waar een product aan moet voldoen. De developers kunnen deze lijst tijdens het ontwikkelen bij zich houden. Ook de expert review is een handige methode om door de hele sprint te houden. Omdat samenwerking een principe is van Scrum is dit goed te doen. Developers en designers moeten immers nauw met elkaar samenwerken. Maar zelfs snelle testjes kunnen veel opleveren. Zo kan de Kellytest en de Hallwaytest een uitkomst bieden. Spreek de eerste de beste persoon aan die je tegenkomt en laat hem/haar de website evalueren. Eén test is altijd beter dan geen test. Mocht de klant van E-ID een groot budget hebben vastgesteld en veel tijd heeft gegeven voor het project, kunnen usabilitytesten uiteraard groter worden aangepakt. Zo kunnen gebruikers worden uitgenodigd om usabilitytesten uit te voeren. Dit kan gebeuren in een speciaal lab, maar ook gewoon bij E-ID of bij personen thuis zelf. Wat E-ID zeker moet doen is producten en features online testen, dus met remote usability testing. Silverback is een perfecte tool, maar Usabilla wordt ook steeds interessanter. Met Usabilla kunnen bijvoorbeeld afbeeldingen van pagina’s worden geupload, waarna gebruikers via hun eigen pc de “screenshots” kan beoordelen door hun meningen te geven. Het is een goedkope en snelle methode.

3. USABILITY SPRINT Omdat E-ID met 2 designsprints werkt, is het misschien ook verstandig om een usability sprint toe te passen. Deze sprints kunnen bijvoorbeeld om de twee development sprints gehouden worden. De sprints duren dan 1 tot 2 weken. Omdat Scrum snel gaat, en design moet worden geïntegreerd, kan het goed mogelijk zijn dat de visie vervaagd of de team weet niet meer waar die aan toe is. Deze fase leent zich dan ook goed om weer even naar de visie te kijken en alle voorgaande usability issues te verwerken in het product. In plaats van om de 2 a 3 sprints, kan een usabil-

ity sprint ook aan het eind worden ingezet. Dan wordt het hele product getest en gevalideerd. Daarna zal er nog een developmentsprint ingezet moeten worden om alles te verbeteren en alle bevindingen toe te passen in het product.

3. CONCLUSIE Vooral als gebruikers nog nooit betrokken zijn in het ontwerpproces is het zaak om niet meteen te hard van stapel te lopen. Discount usability en snelle onderzoeksmethoden bieden hier een oplossing voor.

Adviesrapport 150 man, ideaal

De onderzoeksfase is belangrijk om erin te houden, omdat dit als opstap biedt naar een snellere manier van onderzoeken, concepten en designen. UCD werkt nu eenmaal op een watervalmethode, en dit proces moet E-ID eerst onder de knie hebben. Ook het testen kan op een snelle en goedkope manier. Discount usability methoden zorgen ervoor dat er met weinig budget toch snel feedback van gebruikers gekregen kan worden. Als E-ID nog onzeker is wat betreft de activiteiten van designers in Scrum, kan er worden bepaald of usability sprints een oplossing bieden. Dit geeft het hele team de ruimte en de tijd om goed na te denken of ze nog wel op het goede spoor zitten.

Het adviesrapport voor 50 man heeft gediend als aanloop naar de ideale situatie, vooral om E-ID niet meteen in het diepe te gooien. E-ID heeft de ambitie om binnen 5 jaar uit te breiden naar 150 man. Deze 150 man zal 15 designers betrekken. E-ID is dus langzamerhand op weg naar een full-service bureau met een eigen development- en designafdeling. E-ID werkt niet 100% via de Scrum ontwikkelmethode. En dat hoeft ook niet, want Scrum hoeft niet volgens het boekje te gaan en E-ID redt zich uitstekend. Maar nu E-ID meer designprojecten aanneemt is het verstandig enkele Scrumelementen te hanteren.

1. SCRUMELEMENTEN Bij agile en Scrum is teamverband erg belangrijk. Een positief teamgevoel en “gelukkige uitstralingen en gedragingen” wordt bij Scrum door veel activiteiten bewerkstelligt. Zo is de Scrummaster een belangrijke rol in Scrum, en vervangt deze de projectmanager- / leider (een term dat E-ID nog hanteert). In tegenstelling tot een projectleider, is de Scrummaster als het ware de motivatie achter het team en zorgt hij ervoor dat het team scherp blijft. Hij heeft geen autoriteit en teamleden kunnen zich zo even belangrijk voelen als de Scrummaster. Schrap dus de projectleider en begin met het benoemen van Scrummasters. De daily meetings of standups zijn ook belangrijk wil het team een goed gevoel over elkaar hebben en beter met elkaar kunnen samenwerken. Door elke dag een kwartiertje bij elkaar te komen krijgen teamleden een gevoel voor waar ze staan en wat ze op dat moment aan elkaar hebben. Problemen worden samen opgelost.

Tijdens een sprint review meeting worden de complete user stories aan het eind van een sprint gepresenteerd aan de product owner. Vooral designgerelateerde problemen kunnen vaak terugkomen. Hetzelfde geldt voor de retrospective. Wat net zo belangrijk is, is de werkwijze van Scrumteams. Het is aan te raden om actief met de product backlog bezig te blijven. Zo moeten de product owner en de Scrummaster ervoor zorgen dat de product backlog gedurende alle sprints voldoende gevuld blijft en dat user stories snel genoeg concreet worden. Een story is namelijk alleen klaar als iedereen het erover eens is, er genoeg input voor aanwezig is en als er een inschatting gemaakt kan worden voor design- en ontwikkelinspanning. Ik stel voor om elke dag 10 minuten in te plannen om met het team de user stories te concretiseren. De user stories moeten voor aanvang van elke sprint in taken worden opgesplitst (taken zijn bijvoor-

beeld wireframe schetsen, bellen met X, paper protypen en testen). Ook moeten er echte Scrumboards worden gebruikt in plaats van elektronische. Agile stelt communicatie en face-to-face contact hoog in het vaandel, online applicaties nodigen communicatie niet uit. Scrumboards wel. Werk ook echt met de termen ToDo, Busy en Done en gebruik post-its met de namen van de persoon die ermee bezig is. Zelf stel ik voor om een extra kolom “Approval” (goedkeuring) toe te voegen, voor taken die door de product owner en/of klant moeten worden goedgekeurd. Een andere kolom dat kan worden toegevoegd is “Uplanned Items”. Het komt wel eens voor dat teamleden erachter komen dat er nog taken zijn die eigenlijk uitgevoerd moesten worden, maar niet ter sprake kwamen tijdens meetingen. Op een post-it schrijf je dan de taak en plak je bij Unplanned Items, de product owner zorgt er dan voor dat deze een plek krijgen in de workflow.

2. IDEALE WERKPROCES Ik heb kunnen concluderen dat parallel track de beste manier is om UCD en usability met Scrum te kunnen combineren. Het idee is dat het onderzoek en UI design één of twee sprints voorloopt op het developmenttraject, en dat de usabilitytesten één sprint na de development plaatsvindt. Zo voorkom je dat UI design en usabilitytesten niet conflicteert met de development, ofwel: niemand hoeft op elkaar te wachten. Ook parallel track vereist vooronderzoek en dat wordt gedaan in de Sprint 0. In tegenstelling tot de huidige situatie, is “just enough” en “just in time” belangrijk om in het achterhoofd te houden. Agile UCD gaat er vanuit dat er niet teveel wordt gefocust op details. Dus de Sprint 0 ziet er als het ware hetzelfde uit als bij de huidige situatie, maar dan in mindere mate en “just enough” onderzoek en concepting, maar uitgebreidere methoden om beter en sneller achter de user needs te komen. De parallel track ziet er als volgt uit:

• Gebruikers onderzoek voor sprint X wordt gedaan in sprint X-2; • UI design voor sprint X wordt gedaan in sprint X-1; • Ontwikkeling wordt gedaan in sprint X; • De UI van sprint X wordt getest en geëvalueerd in sprint X+1 Ik stel voor om projectteams te maken van 6 tot 12 man, waarvan 2 UCD’ers fulltime in het project zitten. Sprint 0 De activiteiten en methoden in de Sprint 0 zijn te vergelijken met de onderzoeksfase van het huidige proces. Waar de onderzoeksfase in het huidige proces discount methoden en onderzoek gebruikt, worden de methoden hier iets uitgebreider en nog gebruikersgerichter. Maar vergeet niet dat agile een snelle manier van werken heeft en dat UCD methoden hier op aan moeten passen. Een snelle en goedkope UCD methode heeft altijd de voorkeur, maar dat neemt niet weg dat uitgebreidere methoden met meer diepgang niet snel en goedkoop kunnen. Het is verstandig om te beginnen met Contextual Design, een welgerespecteerde UCD methode bedacht door Beyer, H., Holtzblatt, K. & Baker, L. Contextual Design bevat de volgende activiteiten in de Sprint 0: • Contextual Inquiry; • Affinitieit Diagram; • Werkmodellen; • Persona’s; • Visioning; • Storyboards; • Paper Prototyping

Omdat er meer designers aanwezig zijn en elk project twee UCD’ers tot zijn beschikking heeft, kunnen er nu betere methoden worden ingezet. Zo begint het team met het achterhalen van de huidige werkprocessen van eindgebruikers – hoe zij hun werk structureren en uitvoeren. De beste methode hiervoor is contextual inquiry (CI). In een CI worden eindgebruikers geïnterviewd in hun werkomgeving, worden hun werkactiviteiten geobserveerd en wordt er met hen een gesprek aangegaan over hoe, waarom en wat zij doen. Het eerste wat E-ID in een CI zou moeten uitvoeren is de contextual interview. De interviewer observeert de gebruiker in zijn huidige werksituatie. Bij traditioneel kantoorwerk gaat de interviewer bijvoorbeeld naast de gebruiker zitten en observeert hij hoe de gebruiker een (online) systeem gebruikt of hoe hij formulieren ordent. De gebruiker onderbreken met vragen zorgt ervoor dat er essentiële aspecten van het werk aan het licht komen die anders niet worden herkent (door de interviewer) en erkent (door de gebruiker). Als de gebruiker van hot naar her moet reizen om zijn taken uit te voeren, dan gaat de interviewer met hem mee. De interviewer is overal aanwezig waar het toekomstige en/of huidige product zal worden gebruikt. Alle data die is verkregen uit de interviews wordt gedocumenteerd. Deze documenten zijn vaak lang en ongestructureerd. Interpretatie sessies worden gehouden om deze documentatie op een andere wijze te analyseren. Het team analyseert de data voor elke interview. De interviewer vertelt op chronologische volgorde wat er allemaal is gezegd tijdens de interview, en het team noteert alle belangrijke informatie dat designgerelateerd is. De observaties, belangrijke data, worden in een lijst verwerkt om vervolgens geprint te worden op post-its. Deze post-its worden gebruikt in een affinity diagram. Een affinity diagram geeft alle data weer die is verkregen van observaties en interviews. Zo legt het belangrijke elementen van de manier waarop gebruikers werken vast, hun doelen en manier waarop ze die bereiken, net als obstakels, tools die worden gebruikt en workarounds. Deze worden gegroepeerd van kleine categorieën naar steeds grotere categorieën en dit proces duurt zo’n twee dagen.

De data die is verzameld wordt gebruikt om persona’s en scenario’s te maken. Door tijdens sprints te refereren naar persona’s, helpt dit: • Met het vormen van user stories: “Als Jeroen, projectmanager, wil ik … “; • Het team bij het maken van beslissingen; • Met het prioriteren van user stories Nadat het nodige onderzoek is gedaan, wordt er een dag uitgetrokken om met het hele team naar patronen te zoeken. Deze patronen worden gecategoriseerd en leidt vervolgens tot typische kenmerken van de doelgroep. Het is verstandig om deze persona’s bij te blijven werken, naar mate de onderzoeken en usabilitytesten vorderen, ook wel Extreme Persona’s genoemd. Release planning De product owner schrijft samen met het team user stories, waarbij alle designdisciplines – UX, IA, Visual – zich voordoen als de gebruiker. Dit is acceptabel omdat zij bezig zijn geweest in de Sprint 0 en daarom de werkpraktijken en persona’s door en door kennen. Een user story specificeert de feature van het product, maar niet hoe de feature werkt. Hoe zelfverzekerder het designteam is, hoe specifieker de user stories kunnen zijn. User stories kunnen altijd worden veranderd. Deze user stories worden geplaatst in de producten sprint backlogs. Er zijn een aantal methoden om tot goede user stories te komen. Ik raad niet aan om meteen user stories te maken als er alleen nog persona’s zijn. De user stories moeten ook gevalideerd worden, en gebruikers kunnen niets met één regel. Gebruikers kunnen niet abstracte ideeën niet goed valideren. Een goede manier om user stories - en dus de visie - te valideren is door deze via storyboards weer te geven. Een storyboard is een gevisualiseerde scenario, dat stap voor stap uitlegt hoe een product (of een feature daarvan) wordt gebruikt. Doordat een storyboard de stappen visualiseert kan de gebruiker beter feedback geven. Vaak zijn 6 tot 12 storyboards voldoende om te testen bij gebruikers.

Uit de storyboards en de feedback daarvan kunnen user stories worden onttrokken.

thousiast maken. Het heeft dus weinig zin om de meeste te gekke features als eerst te releasen.

Story Mapping is een goede techniek om de vertaling van user stories naar concept te maken. Een product backlog is overladen met losse user stories, en dit maakt het plat. Je kan er eigenlijk niets mee. Met Story Mapping worden deze user stories geranschikt en gegroepeerd. Een Story Map is een soort tijdslijn. De bovenste rij bestaat uit hoofdactiviteiten. Onder elke hoofdactiviteit komen taken (deze komen voort uit de user story). En onder die taken komen subtaken. Deze Story Map van hoofdactiviteiten en taken vormen een soort verhaal. Zo wordt de scope van het project beter vastgelegd en kan er goed worden nagedacht over het product en concept.

Hierna moeten de stories worden geschat op tijdsduur zodat de sprints backlog ingevuld kan worden. E-ID moet hiervoor zijn eigen methode hanteren. Wel moeten nu de kosten van designgerelateerde zaken mee worden gerekend in de geschatte tijdsduur van een story. Fabrique hanteert de poker planning, waarbij het team per story moet inschatten hoelang het zal duren. Deze schrijven zij dan op kaartjes en worden aan de product owner gegeven. Als de inschatting per story niet met elkaar overeenkomen, dan wordt er in discussie gegaan, waarna iedereen opnieuw zijn inschattingen maakt. Mijn idee hierbij is, is dat het ook nuttig kan zijn voor designgerelateerde taken. Eén van mijn adviezen is dat designers en developers van elkaar op de hoogte moeten zijn. Ze moeten elkaars werkzaamheden kennen en liever nog elkaars werkzaamheden over kunnen nemen (met mate). Door een poker planning kunnen zij zien hoelang een activiteit kan gaan duren. Als hier in discussie wordt getreden, dan proberen ze beide hun “expertise” te overtuigen. Hierdoor leert de één van de ander.

Het prioriteren van de stories kan op verschillende manieren: zo moet het team afwegen of ze na elke sprint een product afleveren dat waarde heeft voor de klant, of waarde heeft voor de gebruiker. Als ze willen prioriteren voor de gebruiker, is het handig om gebruikers te betrekken bij het prioriteren van user stories. Dit kan door gebruikers uit te nodigen en Monopoly geld te geven. Participanten kunnen dan de voor hen meest nuttige features kopen – hoe minder geld ze hebben, hoe verantwoordelijker zij er mee omgaan). De features krijgen een relatief bedrag afhankelijk van de complexiteit en de tijdsduur van het ontwikkelen ervan. Een feature dat twee maal zo complex is, moet twee maal zoveel kosten. Het is raadzaam om een afbeelding, prototype of werkend voorbeeld te gebruiken voor elke feature, zodat de gebruiker weet wat de feature doet. Nogmaals, wat gebruikers zeggen dat ze willen hoeft niet altijd hetzelfde te zijn als wat zij echt willen, maar het geeft een algemeen idee van welke features de hoogste prioriteit heeft. Dit kan ook met de cardsorting techniek, dat eigenlijk wordt gebruikt om informatiestructuren te maken. Met cardsorting krijgt elke participant (dit is de eindgebruiker) kaarten met alle features erop. Deze moeten zij dan rangschikken naar voor hen belangrijkste volgorde. Het is aan E-ID om te kijken hoever ze hierin willen gaan. De participanten weten niet welke features bij elkaar horen wil het technisch lukken. Participanten hebben marketingtechnisch waarschijnlijk ook geen idee hoe dat gaat. Een product release heeft altijd een reden, en dat is de gebruiker en-

en, omdat deze vaak niet goed worden gelezen of anders worden geïnterpreteerd. Behandel de UCD deliverables als documentatie. De prototypes en de testanalysen, dat zijn de deliverables. Ten tweede zijn UCD’ers bezig met iteratief designen voor de volgende sprint – sprint n+1. UCD’ers moeten uitzoeken wat in de product backlog staat en wat er in de volgende sprint backlog komt te staan. Deze user stories geven aanleiding tot het maken van nieuwe designs. Omdat het algemene concept in de Sprint 0 al is gedefinieerd door een Design Studio, zijn de wireframes ook gemaakt. Om UI designs te maken voor de volgende sprint is het handig om eerst concepten over te brengen naar prototypes.

Tijdens een sprint - dus niet de eerste, maar de tweede werken de developers aan de implementatie van de user stories. De designers hebben 4 taken in deze sprint.

Omdat agile een snel werktempo heeft is het verstandig om paper prototypes te maken, ook wel low-fi prototypes. Deze zijn snel, goedkoop en de drempel om concepten weg te gooien is laag. Daarnaast hoeven designers geen technische kennis te hebben en developers geen designskills, dit is voornamelijk handig als E-ID het hele team wilt laten participeren in het designproces, wat raadzaam is. Als paper prototypes zijn gemaakt, moeten ze worden geëvalueerd door eindgebruikers. Een sprint heeft doorgaans 2 tot 3 designiteraties. Bij het testen van de UI designs in papiervorm is de RITE methode van Microsoft een goede methode. Belangrijke usabilityfouten kunnen in de paper prototype meteen worden verholpen. Maar het hoeft niet bij paper prototyping te blijven. Als een designer van E-ID frontend kennis heeft, is het te overwegen echte mockups te maken. Deze zijn vooral geliefd bij websites met veel interactie en animaties. Ook hier is de RITE methode toe te passen. Zelfvertrouwen van designers is een belangrijke zaak en dit hangt ook veel af van welke fidelity de prototypes worden. Nog een reden voor een goede samenwerking.

Ten eerste staan zij development bij. De UI designs die zijn ontworpen worden overgedragen aan de developers. De designers geven tekst en uitleg over het design en de interacties. Er is namelijk geen functionele specificatie: dit wordt overgenomen door de nauwe samenwerking tussen developers en designers. Tijdens gesprekken en discussies tussen de developers en designers worden beslissingen genomen. Ik raad sowieso af veel documentatie te gebruik-

Naast het designen voor de volgende sprint, zijn de UCD’ers ook bezig met informatie verzamelen voor sprint n+2. Continu onderzoeken naar volgende user stories is verstandig, omdat men misschien tot nieuwe inzichten komt of omdat men erachter komt dat de gebruiker eigenlijk wat anders wilt. Door dit twee sprints van tevoren te doen wordt de kans op onbruikbare features kleiner. Deze onderzoeken gebeuren tevens door contextual inquiry, surveys en user

Parallel track De eerste sprint wordt even iets anders gedaan dan andere sprints. Het developmentteam moet bijvoorbeeld nog nodige systemen op zetten, databases aanleggen, automatische testen opzetten of andere technische werkzaamheden verrichten. Het designteam moet (gedetailleerdere) interaction design en visual designs maken. De eerste sprint hoeft niet zozeer waarde voor de gebruiker of de klant te leveren, maar kan dienen als basis voor het project.

interviews. Persona’s kunnen zodoende weer aangepast worden. Hierna doet het designteam usabilitytesten van het product dat gemaakt is in de vorige sprint, door middel van usabilitytesten, heuristic evaluations, expert reviews en de hallwaytest. Als de klant voldoende budget beschikbaar heeft gesteld, dan is de “5 users every friday” perfect. Met deze methode wordt het team beter in onderzoeken omdat het frequent gebeurd. Dit proces begint met het identificeren van wat er zou worden getest op dinsdag: de planning. Woensdag en donderdag worden er prototypes en andere relevante mockups gemaakt of verfijnd, en ondertussen werden er ook gebruikers en middelen bij elkaar gezocht voor de sessie: de voorbereiding. Op vrijdag wordt er per gebruiker één uur ingepland om een website te testen en een gebruiker te ondervragen. Het liefst low-fi, in een gewone kamer zonder spiegels met de aanwezigheid van designers en developers. Dezelfde vrijdag en de aankomende maandag worden deze resultaten geanalyseerd. Maandag en dinsdag worden vrijgehouden om adviezen uit te geven. Dit proces wordt uitgevoerd door één of twee designers. Naar aanleiding van de doelgroep, kan een extern bureau participanten werven. Deze methode is alleen geschikt als UCD’ers vollop toegeweid zijn aan het project en fulltime in het project bezig zijn. Het is overigens aan te raden een sprint van 1 tot 2 weken aan het eind van het project te plannen. Hier kan de usability worden getest, en in dezelfde sprint kunnen de usability issues worden opgelost.

3. CONCLUSIE Als designers en developers goed met elkaar samenwerken, dan is het heel goed mogelijk om in een parallel track te werken. Het is wel zaak dat iedereen zich aan de filosofiën van UCD en agile aanpast. Door veel gebruik te maken van low-fi prototypes kunnen designers het snelle tempo bijhouden. Designers kunnen ook tijd winnen door UI designs te maken (voor de volgende sprint) die technisch erg complex zijn. Zo wint de designer tijd om bijvoorbeeld dieper onderzoek te doen naar de context van de gebruiker - mits dit nog niet gedaan is.

NOG MEER WETEN? User-Centered Design en Scrum is een enorm groot onderwerp waar nog steeds elke dag over geschreven wordt. De methoden die gehanteerd worden hebben op hun beurt weer allemaal varianten. Mocht je geïnteresseerd zijn in meer informatie over het onderwerp en een diepe analyse in de integratie, dan heb ik mijn scriptie vrijgegeven op de Confluence pagina van E-ID. Naam: Don R. Munter E-mail: [email protected]