Vaak is het willen verbeteren van de efficiency een reden voor het inzetten of herbouwen van software. Door onderliggende processen te versnellen en te vereenvoudigen werken gebruikers efficiënter en worden kosten bespaard. Daarnaast worden ergernissen voorkomen en ontstaat misschien zelfs plezier in het werk.
Om dit te bereiken kunnen usability tests worden uitgevoerd, zodat problemen in het gebruik van de software boven water komen. Door aanpassingen aan de applicatie als gevolg van de bevindingen in de usability tests verbetert de werking. Testen van de usability is een goede methode om bruikbare software te maken, maar het heeft een nadeel.
Grote procesmatige verbeteringen
Het verbeteren van de efficiency lukt niet met het testen van de usability. De impact van het bijschaven van de applicatie op basis van testen met eindgebruikers is gewoon te klein om grote procesmatige verbeteringen te bereiken. Het aanpassen van de volgorde van labels of velden, het hernoemen van labels of toevoegen van extra helpopties en –meldingen, heeft niet veel effect op de efficiency.
Er zijn design tools die een goede reputatie hebben als het aankomt op het boeken van efficiencywinst. Het verzinnen van persona’s, typische gebruikers, is er zo een. Door persona’s in een bepaald scenario een rol te geven, worden zinvolle interacties opgebouwd, die de persona naar zijn of haar zakelijke doelen helpen. Het opstellen van persona’s is een goede aanpak om bruikbare software te maken, maar ook deze aanpak kent beperkingen.
Creatieve schrijfoefening
De verzonnen persona’s ‘sterven’ in het ontwerp- en bouwproces van software. Door gebrek aan kennis van hun processen bij de ontwerpers hebben ze onvoldoende lading, geen ruggengraat of komen ze ongevoelig over. Begrijp me niet verkeerd: het maken van persona’s is een prima ontwerptechniek. Maar als persona’s alleen maar verzonnen personages zijn, hebben ze niet de kracht die hen vaak wordt toegedicht. Verzonnen persona’s zijn niet meer dan een creatieve schrijfoefening.
Het verbeteren van de efficiency bij het ontwerpen van software, kan alleen worden bereikt door de problemen in het huidige proces te ontdekken en op te lossen. Daarbij moet een antwoord worden gevonden op enkele belangrijke vragen. Ontbreekt het vertrouwen in het systeem, is extra communicatie nodig of worden er dubbele handelingen uitgevoerd? Gebruikers vinden vaak ‘workarounds’, en ze vergeten zelf waarom die er zijn. Er komen onderbrekingen in het proces voor of aanleidingen voor problemen later in het proces. Een discrepantie tussen de scenario’s van verschillende rollen en afhankelijkheden van andere systemen, belemmeren de efficiency. Tenslotte leiden data die buiten de applicatie worden onderhouden tot zich herhalende scenario’s en kunnen handmatige stappen het proces afremmen.
Software in kaart brengen
Om problemen in het huidige proces te ontdekken, is het raadzaam een gebruikersonderzoek te verrichten. De 51 IDEO Method Cards en de 100 methodieken in het boek Universal Methods of Design laten zien hoe dat werkt. Voor één van onze klanten hebben we onlangs Context Mapping toegepast met een Sensitizing periode vooraf om meer doordachte resultaten te behalen. Hiermee wordt niet alleen het proces, maar ook de context van het gebruik van software in kaart gebracht.
De informatie die hierbij boven water komt, vormt een goede basis voor het opstellen van persona’s die veel meer contextuele informatie in zich dragen en daardoor meer gewicht hebben. Dit biedt een ontwerper goede argumenten bij een onvermijdelijke discussies over functionaliteit. De empathie die ontstaat door het spreken met echte mensen, is de basis voor een beter doordacht concept en interactieontwerp.
Werk efficiënt uitvoeren
Als efficiency van software een doelstelling is in een project, is gebruikersonderzoek noodzakelijk. Alleen dan komen de problemen in het huidige proces boven tafel en heeft een ontwerper voldoende kennis en ervaring om een concept en interactieontwerp te ontwikkelen die gebruikers daadwerkelijk helpen hun werk zo efficiënt mogelijk uit te voeren.
Maarten,
helemaal eens. En in die gebruikersonderzoeken zou dan ook zeker aandacht moeten zijn voor (eind)gebruikersdocumentatie en -informatie. Ik loop al een tijdje mee(DEC; medio 1980; we bouwden mooie oplossingen waarvan onze Sales-mensen vaak het bestaan niet eens wisten, zo techniek-gedreven was de organisatie) en herinner me uit die tijd dat we pilots deden waar we eerst gebruikersinformatie ontwikkelden (rekening houdend met eisen en wensen van gebruikersgroepen) en daarna pas software ontwikkelden. Helaas heeft dit nooit doorgezet en zijn we nog steeds (te) IT-gedreven. Wij (L&L, technisch documentatie-specialisten, Veenenaal) merken nogal eens dat aandacht voor de gebruiker – voor wie we zeggen het allemaal te doen – vaak nauwelijks (maar in ieder geval te laat) op de agenda staat.