Ontwerpaanpak met gebruikers

Veel problemen rond software ontstaan doordat de interactie niet goed is afgestemd op de gebruikers en de taken die zij uitvoeren. Een goede manier om dit te voorkomen is de gebruikers vanaf het begin te betrekken bij het (laten) ontwerpen van een programma. Dit is mogelijk door hen in die eerste fase taken te laten inbrengen bij het ontwikkelen of kopen en inrichten van nieuwe software.

Als gebruikers pas in de fase van evaluatie en bijsturing bij een nieuw ontwerp worden betrokken, bestaat er een groot risico dat het basisconcept niet goed past bij de taken die zij uitvoeren. Mogelijk helpen vijf verbeterslagen in een agile traject dan wel om de scherpe kantjes eraf te halen. Maar goed bruikbaar wordt het niet meer. Of het is te laat om dit nog binnen redelijke kosten te realiseren.

Probleem herkennen

De volgende zaken duiden erop dat gebruikers onvoldoende of te laat worden betrokken bij het ontwerpen van softwareprogramma’s: 

• Je merkt tijdens het ontwikkelen van een nieuwe applicatie dat er steeds maar weer commentaar is van gebruikers en dat er zelfs nieuwe eisen van hen gehonoreerd worden met extra ontwikkelingsbudget. En toch komt er geen pakket uitrollen waarvan de gebruikers zeggen: “Ja, dit is wat we zochten.”
• Na de eerste introductie blijft het pakket nog lange tijd veranderen.
• Er is veel meer training nodig met de nieuwe software dan in eerste instantie werd verwacht.
• De nieuwe software biedt technisch gezien alle faciliteiten om de vereiste bewerkingen op de gegevens te kunnen uitvoeren. Maar de gebruikers blijven verdwalen in al die mogelijkheden en maken vaak vergissingen.

Tips

Voor leidinggevenden en ICT

• Betrek gebruikers vanaf het begin bij plannen om nieuwe software te introduceren. Vertrouw niet op de gedachte dat een pakket uiteindelijk wel gebruikersvriendelijk wordt als je het maar voldoende vaak bijstelt aan de hand van evaluatie met gebruikers.
• Voorzie alle functionele eisen aan nieuwe software van deze drie specificaties:
  1. Wie zijn de gebruikers (klantcontactcentrum, afdeling finance, applicatiebeheerder, accountant, …) ?
     • Incidentele gebruikers hebben veel ondersteunende informatie nodig omdat ze geen routine hebben.
     • Zeer frequente gebruikers hebben vaak last van overdreven veel aanwijzingen omdat ze het ‘blindelings’ kunnen.
     • Een call-center-medewerker, een CEO en een applicatie-beheerder hebben elk een eigen denkniveau en woordenschat.
  2. Hoe vaak voeren de gebruikers een bepaalde taak uit (af en toe voor het jaarverslag, elk uur, bij elke wijziging van …)? Naarmate een functie vaker wordt gebruikt:
     • wordt het meer de moeite waard te investeren in goede bruikbaarheid, en;
     • is er minder ondersteunende informatie nodig voor de taakuitvoering omdat de gebruiker meer geoefend raakt.
  3. Hoe belangrijk is een correcte werking?
     • Is iets niet erg belangrijk en wordt het maar één keer per jaar uitgevoerd (bijvoorbeeld een formaliteit in een jaarverslag), dan is het niet de moeite waard tijd te steken in optimalisatie daarvan.
     • Wordt iets bij elk klantcontact uitgevoerd en is het belangrijk of zelfs cruciaal voor een goed vervolg van het contact, dan loont het al gauw om er samen met gebruikers extra ontwerptijd in te steken. Bijvoorbeeld: 10 seconden besparen in de verslaglegging van een klantcontact van gemiddeld 1,5 minuut scheelt uiteindelijk 10% formatie in een callcenter.

  Voor ICT

  • Besteed bijzondere aandacht aan analyses voorafgaand aan het agile traject. Het eerste ontwerp moet niet alleen innovatief zijn, maar ook passen bij de essentie van de gebruikerstaken.
  • Analyseer hiervoor samen met gebruikers grondig de huidige taakuitvoering. Wat zijn de plus- en minpunten, welke subtaken zijn essentieel of komen heel frequent voor? Enzovoort.
  • Zorg ervoor dat elke afzonderlijk herkenbare functionaliteit (zoals een menu-optie of gegevensformulier) past bij een herkenbare taakstap van de gebruiker.

  
  Voor leidinggevenden en gebruikers 

  • Maak een paar gebruikersvertegenwoordigers onderdeel van het projectteam. Kies hiervoor niet alleen gebruikers die zich gemakkelijk in kunnen leven in een nieuw ontwerp. Neem juist ook de weerbarstige gebruikers mee, want met en voor hen creëer je draagvlak.
  • De gebruikersinbreng bij een ontwerp-evaluatie moet niet beperkt zijn tot vragen naar wat mooi of lelijk of wat goed of fout is. Vraag altijd door naar de argumenten achter de meningen. Die leiden namelijk naar de kern van het commentaar en daarmee naar ontwerpbeslissingen. Gebruikers zijn weliswaar geen ontwerpers, maar ze zijn wél expert in de taakuitvoering.