Interaction Design als hulp bij steeds wisselende requirements

Iedereen kent het wel: De requirements zijn klaar, je kan beginnen aan een nieuw project. Maar tegen het einde van het project ken je de lijst met requirements haast niet meer terug. Er zijn onderdelen afgevallen, bijgekomen, aangescherpt, veranderd etc. Dit proces is erg lastig te managen. Maar hoe komt het nu, en hoe kunnen we dit beperken?

 Het probleem met requirements is vaak dat ze opgesteld worden door iedereen behalve de persoon die met de software gaat werken. Het zijn vaak IT-afdelingen, leidinggevenden en directieleden die requirements opstellen voor een nieuw traject. Dit zijn vaak al half technische oplossingen. Hier zit ook precies het probleem. Techniek is zwaar onderhevig aan veranderingen. In een tijdsbestek van een paar maanden kan een techniek die toen helemaal hot was, compleet vervangen zijn door een andere techniek. Daarnaast mis je vaak een stuk context… Waarom heeft de klant deze requirement nu juist nodig? Gebruikt hij die feature vaak? Welk doel probeert de gebruiker te bereiken? Doordat je deze context mist, ga je vaak (onbewust) aannames doen die leidden tot implementaties die later aangepast moeten worden.

 Hoe kan Interaction Design (IxD) hier nu bij helpen? IxD is een manier waarbij je het gedrag gaat definieren van een applicatie, bekeken vanuit de doelen van de eindgebruiker. Het idee is van Bill Moggridge, maar Alan Cooper (About face, The inmates are running the asylum) heeft dit verder uitgewerkt. In zijn laatste boek (about face 3) staan alle details van IxD, maar ik zal hier kort toelichten waar het om gaat.

 De eerste stap binnen IxD is het definieren van je eindgebruikers. Wie zijn je eindgebruikers precies? wat zijn ze gewend en hoeveel ervaring met techniek hebben ze? Een handige manier om dit in kaart te brengen is gebruik maken van Personas. Dit is een virtuele persoon die de gemeenschappelijke kenmerken van een gebruikersgroep in zich heeft. Deze virtuele persoon wordt concreet gemaakt met een foto en een verhaal over deze persoon en zijn kenmerken.

 Nu we een beeld hebben bij deze persoon, moeten we te weten komen wat het doel is van die Persona of Personas met betrekking tot het project dat we gaan uitvoeren. En hier wil ik even rustig bij stil staan… het doel… Als we goed nadenken hierover kan je tot de conclusie komen dat een doel van een eindgebruiker vaak min of meer tijdsloos is, en niets met techniek te maken heeft. Bijvoorbeeld: Het doel van een urenregistratie-applicatie kan zijn: Inzicht krijgen in de hoeveelheid uren die er in een bepaald project zijn gestoken. Om dit doel te bereiken kan je techniek in gaan zetten. Of dit nu een webapplicatie is, of een apart stukje hardware in de vorm van een stopwatch laten we nu nog even buiten beschouwing. Om het doel scherp te krijgen, moet je je afvragen of de eindgebruiker inderdaad “gelukkiger” wordt van jouw gestelde doel. Bijvoorbeeld: Het invoeren van adresgegevens kan nooit een doel opzich zijn.

 Na deze stap ga je user scenario’s maken. Dit is een beetje verwarrende term, want het woord “scenario’s” wordt in andere contexten anders gebruikt. Binnen IxD is een scenario een beschrijving van een persona die zijn doel wil bereiken. Je verteld eigenlijk een verhaaltje vanuit de persona gezien. Het leuke hiervan is, dat de hele applicatie gaat leven voor je ogen tijdens het schrijven van deze verhaaltjes. Er komen vaak allemaal vragen boven borrelen over hoe de applicatie moet gaan werken. Dit zijn de gaten die er nog zijn in je huidige beeld van de applicatie. Deze vragen kan je helder krijgen door te overleggen met de klant, of beter nog, overleggen met de eindgebruikers. De scenario’s zijn ook erg handig voor testers en developers om een goed beeld te krijgen van hoe een gebruiker om gaat met de applicatie.

Na het maken van de scenario’s ga je storyboards maken. Dit zijn schetsen van de verschillende states van de applicatie. Je zou deze bijvoorbeeld in html kunnen maken als dat je lekker ligt, of gewoon op papier. Na deze stap is voor beide partijen helder wat de applicatie moet gaan doen en hoe deze zich gaat gedragen.

Het voordeel van het definieren van deze persona’s en hun doelen is dat die in veel mindere mate onderhevig zijn aan veranderingen tijdens het project. Plus het stukje context wat je mist bij een platte lijst met requirements wordt nu duidelijker. De “tijdloosheid” van deze doelen en de focus hierop voorkomt dat je verkeerde aannames doet, en dat je features bouwt die niet nodig of niet handig zijn.