Interaction Design als hulp bij steeds wisselende requirements

 
09 mei 2008

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.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags: , , , ,


Reacties (4)

  • @Thomas : Naar mijn weten wil je die Personas ook niet veranderen.

    De mensen die het programma gaan gebruiken veranderen toch ook niet? Personas zijn er ook voor om het project “levend” te maken. Developers praten over Personas alsof het echte mensen zijn en in een ridders-rond-de-ronde-tafel gesprek spreken ze dan sneller dezelfde taal met de business-mensen. Teveel Personas met teveel taken die ze moeten uitvoeren wordt de applicatie dan alsnog veel te onduidelijk van. Te veel knoppen etcetera.

    @mezelf : Ik draaf door… Eigenlijk gaat het erom dat een gebruiker kan doen wat hij/zij wil doen met een applicatie en hoe je daar als developer of designer voor zorgt, dat zal de gebruiker een zalige rotzorg zijn :)

    Geplaatst op 30 mei 2008 om 14:10 Permalink

  • Stefan Bookholt schreef:

    Thomas,

    Goede punten. Ik ben het er helemaal mee eens dat je altijd rekening moet houden met veranderingen. Deze methode kan helpen bij het verminderen van veranderingen, niet het elimineren ervan.

    Waar ik me niet in kan vinden is het iteratief bijwerken van de personas en hun doelen. Dit is namelijk het fundament waarop je gaat bouwen. Je kan dit het beste vergelijken met de “project vision” van DSDM. Deze stel je op aan het begin van het project om duidelijk te maken wat er precies gaat gebeuren. Daarna wordt deze bevroren.

    Indien je project vision moet veranderen, heb je een nieuw project. Zo ook als de persona’s en hun doelen veranderen.

    Geplaatst op 26 mei 2008 om 11:57 Permalink

  • Thomas Zeeman schreef:

    Stefan,

    Het benoemde syndroom kom ik in praktijk ook regelmatig tegen, eigenlijk wel bij elk project. Daarbij maakt het niet uit of er alleen met de IT-afdeling gesproken wordt of ook met de daadwerkelijke eindgebruikers.

    Wat wel uitmaakt is de omarming van het feit dat er wijzigingen gaan komen. Door dat al vanaf het begin te erkennen en je werkwijze daar op in te stellen, kun je de impact van een wijziging behoorlijk minimaliseren.

    Wat ik in je verhaal over Personas herken als iets wat zeer nuttig is is de focus op het doel van de specifieke functionaliteit. Daarmee krijgen beide partijen een goed en bovenal gezamelijk beeld van wat er gemaakt moet worden.

    Waar ik echter denk dat hier nog niet alles goed uitgewerkt is is de manier waarop Personas toegepast kunnen worden. Uit je verhaal lijkt naar voren te komen dat je dit in een Big Upfront Design fase wil doen om pas daarna daadwerkelijk aan het implementeren te slaan. Dat is een manier die ik zelf als beroerd heb ervaren in vrijwel alle projecten waar dat werd toegepast.
    Zelf zou ik dan kiezen voor een aantal iteraties waarin de Personas steeds verder uitgewerkt worden qua functionaliteiten. Dan kun je eerder stoppen als bijvoorbeeld de tijd of het budget op is en lever je toch nog iets op.

    Verder vraag ik me af hoe je wijzigingen in non-functionals wilt opvangen met dit idee. Dergelijke wijzigingen zijn in mijn ervaring juist degene die (later) in een project meer tijd vreten.

    Zie ook het boek Applying UML and Patterns van Graig Larman voor meer informatie over requirements, wijzigingen, de impact en hoe je er mee kan omgaan een een software ontwikkeltraject.

    Geplaatst op 22 mei 2008 om 12:51 Permalink

  • Stefan,

    Hier boor je een heel interessant onderwerp aan. Ik ben ook een grote fan van Cooper en ben het helemaal met je eens dat je na moet denken over doelen van software, zeker in de front-end.

    Een leuk voorbeeld van doelgericht bezig zijn in bedrijfslogica is wat o.a. Rob Vens over demand-chain processen. Een interessant pattern dat hij noemt in dit licht is hier te vinden: http://www.robvens.nl/artikelen/8-computers/29-time-inversion-pattern

    Denk na over je doel, en ga vervolgens de tijd omdraaien om richting je startpunt te gaan redeneren… Erg interessant.

    Geplaatst op 12 mei 2008 om 20:35 Permalink