XP en ID lossen verschillende problemen op

Een tweetal stromingen proberen de gebruiker weer volledig het stuur in handen te geven. Bij ‘extreme programming’ (XP) wordt de klant een integraal onderdeel van het ontwikkelingsteam en neemt hij alle zakelijke beslissingen. Bij ‘interaction design’ (ID) gaat men er vanuit dat het ontwerpen van systemen aan een andere deskundigheid moet worden overgelaten dan aan de software-ontwikkelaars. XP mag zich verheugen in een grote belangstelling, blijkens de vijf nieuwe boeken die sinds het begin van dit jaar zijn verschenen. ID is veel minder bekend en hoewel het een belangrijke bijdrage aan de kwaliteit van software-ontwikkeling levert, wordt er aan deze techniek relatief weinig aandacht besteed. Uit een recente internetdiscussie (www.fawcette.com/interviews/beck_cooper/) tussen Kent Beck (de bedenker van XP) en Alan Cooper (de bedenker van ID) blijkt dat beide heren het niet erg met elkaar eens kunnen worden. Geheel ten onrechte, want beide methoden trachten een geheel ander probleem op te lossen en kunnen zelfs heel goed met elkaar worden gecombineerd. Desastreus Pak eens een willekeurig programma, bijvoorbeeld een tekstverwerker, en save het bestand na enige wijzigingen te hebben aangebracht. Als het een nieuw bestand betreft, moet er een naam worden opgegeven. Als die naam al bestaat, vraagt het programma of het bestand mag worden overschreven. Voor onervaren gebruikers levert zo’n vraag een groot probleem op. De meeste mensen zullen zich niet realiseren dat het antwoord op deze vraag een desastreus resultaat kan hebben en dat daarmee ofwel een eerder gemaakt bestand wordt vernietigd, of de zojuist gemaakte veranderingen verdwijnen. Dit soort situaties dient men te vermijden, zegt Alan Cooper in zijn boek ‘The Inmates are running the Asylum’. Als de kans bestaat dat een gebruiker onbewust schade toebrengt, dient het systeem zo te zijn ontworpen dat de actie kan worden teruggedraaid of niet kan voorkomen. In het geschetste voorbeeld is dat geen eenvoudige zaak, vooral omdat het heel lang kan duren voordat wordt ontdekt dat het eerdere bestand onbedoeld werd overschreven. Gebruikers die geen goed inzicht hebben in de opbouw van directory-structuren begrijpen niet wat er gebeurt. Toch gaan veel programmeurs bij de opzet van systemen uit van de veronderstelling dat iedereen hetzelfde denkt als een ontwikkelaar. Dat is de voornaamste reden waarom Cooper vindt dat er een nieuwe discipline moet komen: de functie van interaction designer of ontwerper. Een ontwerper zal zich goed moeten verdiepen in wie de gebruikers eigenlijk zijn en wat voor problemen zij hebben. Dit voorbeeld is maar één van de vele situaties waarin gebruikers van moderne software zich zien geplaatst. Met de opkomst van de microcontroller worden steeds meer apparaten bestuurd door software en breidt het probleem zich uit tot veel moderne apparatuur. Wie heeft er geen grote problemen met de veel te ingewikkelde menustructuren in moderne telefoons? Zij zijn zelfs voor technisch aangelegde mensen te moeilijk om te gebruiken. Persona Het eerste dat een ontwerper doet die interaction design gebruikt, is onderzoeken wat voor gebruikers een systeem zou kunnen hebben en wat hun specifieke kennis en behoefte is. Een veel gemaakte fout is dat te vaak wordt geprobeerd om zoveel mogelijk verschillende gebruikers tegelijkertijd tevreden te stellen. Het gevolg is dat er eigenlijk voor geen van de gebruikers een bevredigende oplossing wordt geboden. Veel beter is het om een nauwkeurige analyse te maken van de verschillende gebruikerstypen en dan een keuze te maken voor een benadering. Bij het voorbeeld van de tekstverwerker gaat de ontwerper eerst na, wie de gebruikers zijn. Alan Cooper stelt hier een techniek voor, waarbij voor ieder gebruikerstype een zogenaamde ‘persona’ wordt gemaakt. Dit is een gedetailleerde beschrijving van een fictieve persoon, compleet met naam, omschrijving en foto. De bedoeling van zo’n persona is om het denken over de problemen van zo’n gebruiker gemakkelijker te maken. Gewoonlijk worden er verschillende van dergelijke ‘personas’ opgezet, waarvan er voor de ontwikkeling uiteindelijk maar één of twee worden uitgekozen. Deze staan dan model voor de typische doelgroep waarop het product wordt gericht. Voor een tekstverwerker kunnen we ons voorstellen dat er verschillende gebruikers te bedenken zijn, bijvoorbeeld: Martin, een software ontwikkelaar, Lucille, een leerlinge van 14 jaar uit de tweede klas van de middelbare school, Jackie, een zeer actieve en druk bezette alleenstaande moeder van 38 en Mike, een gepensioneerde kolonel. We kunnen niet alle personas tegelijk helpen met ons te bouwen systeem en zijn op zoek naar die persona, die het meest representatief is. Als we Martin (de ontwikkelaar) als uitgangspunt nemen, zullen geen van de andere gebruikers zich thuis voelen met het systeem. Kiezen we Lucille (het schoolmeisje) dan kunnen we er vanuit gaan dat zij veel gemakkelijker met computers om zal gaan dan Jackie en Mike. Jackie en Mike zullen waarschijnlijk vergelijkbare problemen hebben, waarbij Mike (die met pensioen is) waarschijnlijk veel meer tijd in het systeem kan steken. Als we het systeem dus ontwikkelen voor Jackie, zullen vrijwel alle andere personas er ook comfortabel mee om kunnen gaan, dus staat Jackie model voor de gebruiker. Cooper stelt in zijn benadering, dat het opnemen van een ‘save’ commando iets is dat niet aan onervaren gebruikers moet worden aangeboden. In plaats daarvan kan ook een minimale faciliteit worden opgenomen, waarbij het document regelmatig automatisch wordt veilig gesteld onder een naam die uit het document wordt gedestilleerd. Hierdoor kan Jackie direct aan de slag en krijgt ze vertrouwen in het programma. Wanneer er later veel documenten zijn gemaakt en er behoefte ontstaat om alle documenten wat te ordenen kan het systeem voorstellen een categorieaanduiding bij het document op te nemen. Jackie leert daardoor geleidelijk aan de mogelijkheden van het systeem, maar alleen als duidelijk is dat deze faciliteit echt nodig is. De essentie van deze benadering is om gebruikers zo snel mogelijk productief met een systeem om te laten gaan en een gevoel te geven dat ze de materie beheersen. Veel moderne systemen doen helaas het omgekeerde. Gebruikers moeten zich eerst veel nieuwe dingen eigen maken en begrijpen soms op geen enkele manier wat ze verkeerd doen, waardoor ze zichzelf niet geschikt achten voor het omgaan met computers en al snel de moed opgeven. Het is de taak van de ontwerper om zo’n situatie te voorkomen. De beste Vooral in Amerika is de ID-benadering in opkomst, in Europa is zij vrijwel onbekend. De algemene gedachte is dat interaction design alleen maar extra geld kost. Omdat de meeste softwareproducenten ongeveer dezelfde soort kwaliteit leveren en iedereen de huidige manier van software-ontwikkeling lijkt te accepteren, lijken de extra inspanningen die ID met zich meebrengt moeilijk te rechtvaardigen. Wat echter wordt vergeten is dat juist een goed ontwerp helpt het product te verkopen. Iedereen is op zoek naar onderscheidend vermogen en toegevoegde waarde en deze wordt bij het gebruiken van de methode zeker geleverd. In de Verenigde Staten zijn verschillende grote concerns zich gaan interesseren voor de ID-benadering en sommige systemen krijgen enige bekendheid alleen al door het feit dat ze met behulp van ID zijn ontwikkeld. De grote opkomst van extreme programming heeft ervoor gezorgd dat er vragen zijn ontstaan hoe XP en ID zich tot elkaar verhouden. In het interview met Kent Beck en Alan Cooper werd dan ook geprobeerd uit te vinden welke benadering de beste was. Zo’n vergelijking is helaas niet het juiste uitgangspunt. ID en XP zijn methoden om verschillende soorten problemen op te lossen. XP is met name sterk in het betrekken van de gebruiker of opdrachtgever in projecten en levert een benadering die ontwikkelaars in staat stelt om zeer snel in te spelen op de veelvuldige veranderingen die de huidige 7x24-uursmaatschappij aan bedrijven stelt. De XP-voorstanders stellen dat in deze omstandigheden het bedenken van flexibele architecturen voor een toekomst die waarschijnlijk door de werkelijkheid wordt ingehaald, geen zin heeft. Om die reden tracht XP hulpmiddelen aan te bieden waarmee snel en betrouwbaar veranderingen in bestaande systemen kunnen worden aangebracht. ID richt zich meer op massaproducten, die geen direct aanwijsbare eindgebruiker of opdrachtgever hebben en voert een nieuwe discipline ten tonele, die de bruikbaarheid van een product moet garanderen en die bedoeld is om het juiste product te ontwikkelen. XP bezit verscheidene ontwikkelingstechnieken. Verschillende ervan, zoals pair programming, test-first-ontwikkeling en de daily build, geven zinnige adviezen over de manier waarop het ontwikkelingsproces kan worden georganiseerd. Op het gebied van het omgaan met de gebruiker worden de zogenaamde stories en gebruikersparticipatie voorgesteld. Een van de belangrijkste pijlers is echter het principe van minimalisme: ontwikkel uitsluitend datgene wat direct nodig is en niet meer en zorg dat uitbreidingen op ieder gewenst moment snel en betrouwbaar kunnen worden aangebracht. De ID-benadering geeft een geheel nieuwe oplossing voor het bepalen van de behoeften van de gebruiker, die bij voorkeur wordt opgesteld door personen die een goed inzicht hebben in het gedrag van gebruikers. Over het algemeen zijn dat niet de technisch georiënteerde ontwikkelaars. Het nieuwe vakgebied van interaction designer wordt meer beoefend door mensen met een marketing- of een psychologische achtergrond. Wensen XP is sterk in het bieden van technieken om op een goede manier een systeem te ontwikkelen. Er wordt echter niet aangegeven hoe men bepaalt wat er moet worden ontwikkeld. De oplossing om de gebruiker als lid van het ontwikkelingsteam mee te laten werken en vanuit deze positie te laten bepalen wat er moet worden gemaakt, is vooral bedoeld om voldoende invloed op het ontwikkelingsproces zelf te bieden. Het echte probleem is echter hoe we erachter kunnen komen wat gebruikers werkelijk nodig hebben. Studies tonen aan dat gebruikers zelf daarvoor geen betrouwbare bron zijn. Het blind volgen van de vragen van gebruikers transformeert zelfs een productgericht bedrijf in een servicegericht bedrijf, waarin niemand meer de ontwikkeling van het product beheert. In de meeste ontwikkelingsprojecten worden door marketing-mensen en ontwikkelaars gezamenlijk feature lists opgesteld. De features worden meestal bepaald aan de hand van vragen van gebruikers of gesprekken met vertegenwoordigers van de markt. Features worden meestal zó gekozen dat daarmee zoveel mogelijk klanten tevreden worden gesteld. Ontwikkelaars denken over het algemeen sterk in taakstructuren, vandaar de feature-lijsten. In de benadering van interaction design wordt niet uitgegaan van taken, maar van doelstellingen. Pas nadat een compleet beeld is verkregen van de doelstellingen die een bepaald soort gebruiker heeft, mag worden begonnen met het vaststellen van de middelen waarmee deze doelstellingen kunnen worden ondersteund. Dit vormt een veel betere basis voor de opzet van een systeem en indien een project wordt voorafgegaan door een ontwerpfase, waarin technieken als die van interaction design worden gebruikt, kunnen de gevaarlijke ‘programmeurinterfaces’ voorgoed worden vervangen door echte gebruiksvriendelijke systemen. Met ID kan men ervoor zorgen dat gebruiksvriendelijkheid niet langer meer gereduceerd wordt tot een label op de verpakking. Met een goed ontwerp wordt het mogelijk producten te maken die écht gemakkelijk te gebruiken zijn. Balans Als interaction design wordt voorgesteld als een alternatief voor andere ontwikkelingsmethoden zoals XP, slaat men de plank volledig mis. Een goed ontwerp van een systeem zorgt ervoor dat de gebruiker er gemakkelijk mee om kan gaan en dat de doelstellingen met het product goed kunnen worden gerealiseerd. Dat geeft echter geen garantie dat daarmee ook een technisch volwaardig product wordt afgeleverd. Het opzetten van een goede architectuur en vooral aandacht voor de betrouwbaarheid en de beheersbaarheid van een ontwikkelingstraject komen in de opzet van interaction design helemaal niet voor. Door beide benaderingen te combineren, ontstaat een betere balans tussen techniek en toepassing. Het is van belang om de grote mate van afhankelijkheid van technisch gerichte ontwikkelaars drastisch te beperken. De verantwoordelijkheid voor de inhoud van het product moet uiteindelijk bij de gebruiker liggen of bij een partij die vanuit een eigen deskundigheid deze gebruikers kan vertegenwoordigen. De technische kant van een project blijft belangrijk en de verantwoordelijkheid hiervan ligt volledig bij de ontwikkelaars. Een goede dialoog en nauwe samenwerking tussen beide partijen is essentieel om tot meer hanteerbare systemen te komen en een versmelting van zowel de gebruikte technieken als ID en XP is een eerste stap op weg naar een betere integratie tussen beide disciplines. Kortom, XP en ID zijn twee relatief nieuwe benaderingen, die ieder een ander aspect van software- en hardware-ontwikkeling belichten. Ze hebben met elkaar gemeen dat de gebruiker stevig het stuur van het proces in handen wordt gegeven. Een combinatie van beide benaderingen levert een instrumentarium op dat goed bestand is tegen de druk van de 24-uurseconomie en dat in veel belangrijker mate rekening houdt met het feit dat niet alle gebruikers van computersystemen ervaren programmeurs zijn. Met de toenemende mate van gebruik van computerchips in alle apparatuur en de opkomst van ‘geprogrammeerde’ interfaces is dit beslist geen overbodige luxe. AUTEUR: Peter van Lith Peter van Lith RI (peter@lithp.nl) is onafhankelijk adviseur, opleider en ontwikkelaar (www.lithp.nl).