Gebruiksgemak is niet subjectief, maar je kan het ook niet eisen.
Bij het aanbesteden van gemeentelijke software wordt gebruiksgemak vaak helemaal verkeerd toegepast in de eisen en/of de wensen.
Photo by Fabian Wiktor from Pexels
Gebruiksgemak of gebruikersvriendelijkheid wordt bij veel software aanbestedingen belangrijk gevonden. Dat is op zich terecht, maar de manier waarop het meestal opgenomen wordt in de eisen en/of de wensen laat echt nog te wensen over. Grofweg zijn er twee aanpakken te ontdekken als je op TenderNed kijkt:
Er wordt aangenomen dat gebruiksgemak subjectief is, maar belangrijk. Daarom wordt ervoor gekozen om het gebruiksgemak te beoordelen op basis van een demonstratie. De gedachte is waarschijnlijk dat, als er maar genoeg mensen beoordelen, dat er vanzelf een meer objectief oordeel ontstaat.
Er worden eisen gesteld aan de gebruikersinterface, waarbij de aanbestedende dienst dus gaat voorschrijven welke eigenschappen minimaal aanwezig moeten zijn om gebruiksgemak te bereiken.
Beide aanpakken zijn problematisch zowel bezien vanuit het nut van de gekozen werkwijze als bezien vanuit de aanbestedingsregels. Het is zeker niet per definitie verkeerd om de eigenschappen van een gebruikersinterface op basis van een demonstratie te beoordelen. Maar dan moet je wel (het liefst vooraf) weten waar je op gaat beoordelen. En als je ervoor kiest om bepaalde eigenschappen voor te schrijven, dan ga je op de stoel van de leverancier zitten en doe je de impliciete aanname dat jouw voorgeschreven eigenschappen de enige zijn die tot gebruiksgemak kunnen leiden.
Gebruiksgemak is geen eigenschap, maar een resultaat
Hoe moet het dan wel? Allereerst is het belangrijk om gebruiksgemak of gebruikersvriendelijkheid niet als eigenschap van software te beschouwen. Gebruiksgemak is dat wat ontstaat door het gebruik van software. Het is een resultaat. Om dit beter te begrijpen helpt het om over ‘bruikbaarheid’ (usability) te praten in plaats van over gebruiksgemak. Het concept ‘bruikbaarheid’ staat centraal in de standaard ISO 9241. Dit is een omvangrijke (uit meerdere delen bestaande) standaard over de interactie tussen systeem en mens. Voor ‘bruikbaarheid’ als resultaat geeft ISO 9241-11:2018 verschillende facetten, waaronder effectiviteit, efficiëntie en tevredenheid. In een ander deel (ISO 9241-110:2020) geeft deze standaard uitgangspunten en aanbevelingen die bijdragen aan de bruikbaarheid van software (in het Engels):
Suitability for the user’s tasks
Self-descriptiveness
Conformity with user expectations
Learnability
Controllability
Use error robustness
User engagement
En in de standaard ISO 9241-112:2017 worden aanbevelingen gedaan specifiek voor het presenteren van informatie aan de gebruiker (in het Engels):
Detectability
Freedom from distraction
Discriminability
Interpretability
Conciseness
Consistency
Het zijn dus deze eigenschappen van de software die, wanneer de software gebruikt wordt, ertoe leiden dat een taak efficiënt uitgevoerd kan worden of dat een gebruiker tevreden is. De manier waarop leveranciers die eigenschappen vormgeven kan veel objectiever beoordeeld worden dan ‘de applicatie moet gebruiksvriendelijk zijn’.
Hoe kun je ‘bruikbaarheid’ beoordelen?
Je moet vooral niet gaan voorschrijven hoe een leverancier de ‘usabilty’ eigenschappen vorm moet geven. Dat doen de standaarden ISO 9241-110:2020 en 9241:112:2017 ook niet. Dus eisen als ‘bij een fout moet het systeem een pop-up tonen’ of ‘bij het typen in invoervelden gebruikt het systeem auto-fill’ worden echt afgeraden. Dit zijn voorbeelden van hele specifieke oplossingsrichtingen en je sluit zo leveranciers uit die een andere en wellicht beter ontwerp hebben gekozen.
Om de ‘bruikbaarheid’ van software te beoordelen zul je eerst moeten bedenken welke resultaten belangrijk zijn. Dat is niet voor iedere aanbesteding hetzelfde. Dat is enerzijds afhankelijk van wat de organisatie en haar gebruikers belangrijk vinden en anderzijds van de verschillen tussen leveranciers. Het kiezen van de juiste beoordelingsaspecten van ‘bruikbaarheid’ bij de aanbesteding van software bestaat uit drie hoofdvragen:
Welke resultaten zijn belangrijk? Is efficiëntie in het gebruik belangrijk? Of juist effectiviteit? Of misschien toch de tevredenheid van de gebruiker?
Welke eigenschappen zijn in de context van het gebruik belangrijk om de resultaten te bereiken? Dus voor een applicatie voor hoog-volume data invoer door medewerkers die er de hele dag gebruik van maken zul je andere eigenschappen kiezen dan voor een klantcontact applicatie die door medewerkers slechts enkele keren per week gebruikt wordt.
Op welke eigenschappen bestaan er significante verschillen tussen leveranciers? Het heeft weinig zin om naar eigenschappen te vragen als alle leveranciers die op dezelfde manier invullen.
Geen eisen dus, of toch wel?
In principe is het niet verstandig om ‘bruikbaarheid’ op te nemen in de vorm van eisen. Er zijn echter enkele uitzondering. Het beste voorbeeld is bijvoorbeeld dat de gebruikersinterface in de Nederlandse taal moet zijn. Dat is een eigenschap die valt onder ‘suitability for the user’s tasks’ bijvoorbeeld. Maar voor het overgrote deel van alle mogelijke eigenschappen is het advies om eisen te vermijden.
Gebruik open vragen
Ook het gebruik van gesloten vragen (ook al zijn het wensen) wordt afgeraden. Gesloten vragen schrijven nog steeds de oplossingsrichting voor. Gebruik open vragen en vraag naar hoe een leverancier een bepaalde eigenschap heeft ingevuld. En beoordeel het antwoord op basis van de resultaten die je belangrijk vindt.
Voorbeeldvraag #1
Vraag: Beschrijf op welke wijze in uw helpdesk-applicatie gebruikers relevante informatie en schermelementen kunnen onderscheiden van niet-relevante informatie en schermelementen.
Beoordeling: De mate waarin het gebruik van de oplossing bijdraagt aan het efficiënt uitvoeren van taken.
Toelichting: Het gaat in de vraag om eigenschappen van de oplossing om de ‘discriminability’ (ISO 9241-112:2017) te vergroten. En omdat het hier om een helpdesk-applicatie gaat is ervoor gekozen om dit beoordelen op basis van efficiëntie omdat het belangrijk is dat gebruikers snel relevante informatie op het scherm herkennen als ze een klant aan de telefoon hebben.
Als het mogelijk is, dan is het zeker de moeite waard om deze eigenschap (ook) op basis van een demonstratie te beoordelen. De vraag zou dan beginnen met “Laat zien op welke wijze..”
Voorbeeldvraag #2
Vraag: Beschrijf op welke wijze in uw financiële applicatie gebruikers geholpen worden om foute invoer te voorkomen en ingevoerde fouten te herstellen.
Beoordeling: De mate waarin het gebruik van de oplossing bijdraagt aan een volledige en accurate administratie.
Toelichting: Het gaat in de vraag om eigenschappen van de oplossing om de ‘use error robustness’ (ISO 9241-111:2020) te vergroten. Het gaat dan specifiek om ‘error avoidance’ en ‘error recovery’. En de beoordeling vindt plaats op basis van ‘completeness’ en ‘accuracy’ als onderdeel van effectiviteit (ISO 9241-11:2018).
Referenties
ISO 9241-11:2018
ISO 9241-110:2020
ISO 9241-112:2017
Juristo, N., A.M. Moreno, and M. Sanchez-Segura, “Guidelines for eliciting usability functionalities”, IEEE Transactions on Software Engineering, Vol. 33, No. 11, (2007).
Nasar, V., “Common criteria for usability review”, Work, Vol. 41, No. Supplement 1, pp. 1053-1057, (2012).
Rafla, T., P.N. Robillard, and M. Desmarais, “A method to elicit architecturally sensitive usability requirements: its integration into a software development process”, Software Quality Journal, Vol. 15, pp. 117-133, (2007).
Sindhuja P.N., and S.G. Dastidar, “Impact of the factors influencing website usability on user satisfaction”, The IUP Journal of Management Research, Vol. VIII, No. 12, (2009).
