Op maat ontwikkelen komt steeds minder voor als we het hebben over de grote it-projecten. Dure licenties van pakketten worden gekocht, het pakket wordt geconfigureerd en binnen de organisatie geïmplementeerd. Allemaal volgens de regels en weer gemakkelijk te updaten als er een nieuwe versie van het pakket komt of als er een nieuwe versie in de cloud wordt open gezet. Maar hoe ga je om met de grillige wensen van de eindgebruikers?
Ik sta natuurlijk heel positief tegenover het betrekken van eindgebruikers. Hij of zij moet namelijk diverse handelingen verrichten waardoor de organisatie goedkoper, sneller en efficiënter gaat werken. Als voorbeeld noem ik het indienen van een declaratie of het aanvragen van vrije dagen als werknemer, of het volgen van een besteld pakketje als consument. De eindgebruiker bedient zichzelf, het zogenaamde self-service principe.
Bij veel pakketleveranciers werken usability specialisten en/of user experience consultants. Zij dragen zorg voor een generieke opzet van de schermen die een eindgebruiker ziet. Maar het is voor hen onmogelijk om voor de specifieke situatie van een project een opzet te maken. Dat kan komen doordat niet alle functionaliteiten worden gebruikt. Of omdat er andere omgevingen geïntegreerd moeten worden. Maar misschien wordt het pakket door een specifieke doelgroep gebruikt. Daarom heb ik de overtuiging dat juist op dit gebied de grote winst wordt behaald. Maar hoe dek je dit dan af?
Ken je doelgroep
Je kunt je gemakkelijk in de doelgroep verdiepen door scenario’s te schrijven waarin je stap voor stap beschrijft welke handelingen met bijbehorende verwachtingen er zijn voor een eindgebruiker. Dit scenario wordt natuurlijk techniek onafhankelijk geschreven. Een gebruiker wil niet inloggen maar moet inloggen. Dus wat wil een eindgebruiker uitvoeren en wat zijn de stappen. Hiervoor gebruik ik vaak workshops omdat ik dan de eindgebruikers kan bevragen waarom ze iets willen.
Te vaak wordt een pakket gevalideerd via een presentatie! Eindgebruikers zitten lekker in de zaal en luisteren onder genot van een kopje koffie of thee naar de expert die even verteld hoe je een taak kunt uitvoeren. Dat is geen validatie. Pas als de eindgebruikers echt hun taak kunnen uitvoeren op schermniveau krijg je een validatie. Hiervoor kan je snel iets met het pakket in elkaar zetten, maar je kunt ook gebruik maken van een simulatie. Hiermee zie je wanneer een gebruiker de weg kwijt raakt tijdens het uitvoeren van een (zware) taak.
Specifiek voor pakketten
Een pakket geeft een duidelijk functioneel en technisch kader voor de schermen. Als ontwerper moet je daar terdege rekening mee houden. Daarom laat ik graag een pakketexpert meewerken aan het ontwerp. Vanuit ervaring weet ik dat je dan een nog beter eindresultaat gaat bereiken want hij/zij denkt aan opties die ik niet weet. Maar stap nooit in de valkuil dat alleen een pakketexpert het scherm ontwerpt, hij heeft (onbewust) oogkleppen gekregen voor de echte behoefte van de eindgebruikers.
Zoals gezegd werken veel pakketten aan de gebruiksvriendelijkheid op een generiek niveau. Zoek als ontwerper de specifieke situaties van jouw project op door scenario’s te schrijven, en combineer dat met het denken vanuit het pakket. Valideer alle aannames op de juiste manier: met een prototype of simulatie.
Organisaties die een publieke website maken, maken vaak gebruik van een usability designer. Vele usability tests worden ook uitgevoerd eer de website live gaat. Zo zullen de grote enterprise applicaties dit ook doen, hoewel ze vaak het tegendeel bewijzen. Een workflow is hierin een ander gegeven. Gebruikers hebben vaak een taak in het gehele proces. Die taak moet aansluiten bij andere taken. Hierin kan de gebruiker niet altijd overzien hoe het gehele proces in elkaar steekt. Architectuur kan hier helpen door het gehele end-to-end proces in beeld te krijgen. Dit combinerend met usability tests moet een goed produkt opleveren.
@Ruud > Helaas wordt bij pakket implementaties vaak de rol van een usability designer vergeten. Uiteraard ben ik het met je eens dat die rol juist voor een hoog niveau van gebruiksgemak moet zorgen. Dit stukje is dan ook bedoeld om juist voor die vakgenoten aan te geven wat de belangrijkste aspecten zijn. Samen met architectuur het gehele proces designen en testen met nadruk op het gehele proces vanuit de eindgebruiker.
Titel is wat ongelukkig door de eindredactie gekomen dus focus op de inhoud van het artikel…
Inzet van een usability designer kan helpen, met de nadruk op “kan”
Je zult namelijk altijd uitzonderingen houden binnen de gebruikersgroep, die met het pakket net niet kan wat ze eigenlijk zouden willen. Maar als dit maar een paar procent van de gebruikers is, en ze hebben een workaround voorhanden, moet je daar dan tijd en energie in gaan steken?
Maar nog belangrijker is dat je zorgt dat de usability engineer met een representatieve gebruikersgroep praat, en niet met één of andere manager die denkt te weten hoe zijn collega’s werken.
@PaVaKe Daar heb je een goed punt: zorg dat je praat met de echte eindgebruiker en niet met een vertegenwoordiger. Want een gebruiker roept zijn wens maar een usabilitypersoon kan het waarom achter de wens achterhalen.