Overslaan en naar de inhoud gaan

Gebruikersvriendelijkheid is een haalbare kaart

Wouter Schoonman schrijft in zijn artikel dat psychologen meer invloed moeten krijgen op gebruikersinterfaces (Automatisering Gids 19, pagina 17). Ik ben het volledig eens met de stelling dat er vaak sprake is van ‘technische terreur’. Toch wil ik graag een aantal nuances toevoegen, omdat vooral vanuit de psychologische discipline wordt gedacht en eens te meer ‘de ICT’er’ of ‘de programmeur’ wordt gestigmatiseerd als iemand die niet mee kan denken met de gebruiker.
Tech & Toekomst
Shutterstock
Shutterstock

De voorbeelden van inconsistente menustructuren en taalgebruik vind ik kenmerkend. Natuurlijk heeft Schoonman gelijk als hij deze inconsistent noemt. Overigens hoef je geen psycholoog te zijn om dit te kunnen constateren. De kwaliteit van een gebruikersinterface wordt echter uiteindelijk bepaald door de eindgebruiker. Als grote groepen gebruikers zich niet bewust zijn van deze inconsistenties en goed met een applicatie kunnen werken, rijst de vraag of deze inconsistenties inderdaad een probleem zijn. Laten we gebruikersinterfaces dan ook niet te veel vanuit de theorie benaderen, maar vooral vanuit de praktijk. Ik heb schermen gezien die niet aan de theoretische regeltjes voldoen, maar die door de eindgebruiker hogelijk worden gewaardeerd, omdat ze erg handig werken. Soms zijn deze schermen in eerste instantie minder intuïtief, maar is deze initiële barrière voor de gebruiker snel vergeten door de snelheid/handigheid van werken die daarna geboden wordt. Dat de heer Schoonman psycholoog is en geen ICT’er, blijk uit het stukje over ‘user tests’. Als ik dit goed interpreteer, worden hier de acceptatietests door gebruikers bedoeld. Het ‘prototypen’ van gebruikersinterfaces kan echter vaak al in een veel eerder stadium, voordat het ontwerp vastligt, plaatsvinden. Verder biedt een iteratieve ontwikkelcyclus mogelijkheden om op regelmatige basis terugkoppeling van gebruikers te verwerken. Daarbij moet je als bedrijf niet bang zijn om toe te geven dat zaken minder goed uitpakken en deze dan ook eventueel aan te passen. Ook na het initiële ontwerp moet je vragen blijven stellen als: ‘kan dit simpeler, is dit echt nodig?’. Ik onderken de noodzaak van het bekijken van een applicatie vanuit verschillende invalshoeken, ook de psychologische en de linguïstische. Tevens vind ik een standaard waarin richtlijnen staan over de gebruikersinterface in de meest brede zin des woords, een must. Ik denk echter niet dat daar in alle gevallen psychologen en linguïsten bij nodig zijn. Niet alle ‘programmeurs’ zijn zonderlingen zonder gevoel voor gebruikersinterfaces of taal. Door te werken met goed opgeleide en ervaren applicatieontwikkelaars die binnen meer disciplines kunnen opereren, kan een te hoog ‘techneutengehalte’ worden voorkomen. Deze applicatieontwikkelaar dient tevens goede sociale eigenschappen te bezitten en zich thuis te voelen op het snijvlak tussen ICT en business. Een schaap met vijf poten? Nee, deze mensen zijn er steeds meer. De ICT­opleidingen leveren steeds vaker mensen af die zich tot zo’n allround ontwikkelaar kunnen ontplooien. De applicatieontwikkelaar (dus de allrounder) kan een gebruikersinterface ontwerpen binnen de opgestelde richtlijnen, gebruikmakend van zijn gevoel voor taal, bruikbaarheid en grafische vormgeving. Collega’s en potentiële gebruikers kunnen hier terugkoppeling over geven, liefst in een zo vroeg mogelijk stadium. Overigens zullen de echte techneuten altijd zeer nodig blijven om de technisch complexe zaken op te lossen. Deze liggen echter vaak niet op het gebied van gebruikersinterfaces. Een andere invalshoek op deze problematiek is dat naar mijn mening de ICT­industrie, de adviseurs en in zekere zin ook de eindgebruikers, voor een deel debet zijn aan het probleem. Zolang pakketten worden vergeleken op het aantal features in plaats van de gebruikersvriendelijkheid, is duidelijk waar de meeste aandacht van de producenten van software naar uitgaat. Een nieuwe versie van een applicatie staat bijna gelijk aan ‘meer’. Intussen is vrijwel geen enkele gebruiker meer in staat alle finesses van een pakket te doorgronden en wordt van alle mooie features 50 procent niet gebruikt. Het voorbeeld is nog verder door te voeren: meer functionaliteit betekent dat implementatie, onderhoud en gebruikersinstructie ingewikkelder worden en meer tijd kosten. Daar spinnen de consultants van de leveranciers zelf weer garen bij. Economisch gezien is het dus voor leveranciers niet zo interessant om eenvoud te prediken. Marco van Zelst is Manager Product Development bij Appenta bv.Bijdragen in de rubriek Opinie staan los van de redactionele opvattingen van AG. De redactie behoudt zich het recht voor artikelen te redigeren en in te korten. Bijdragen voor de rubriek kunnen worden gestuurd aan: ag@wkths.nl onder vermelding van ‘opinie’.

Lees dit PRO artikel gratis

Maak een gratis account aan en geniet van alle voordelen:

  • Toegang tot 3 PRO artikelen per maand
  • Inclusief CTO interviews, podcasts, digitale specials en whitepapers
  • Blijf up-to-date over de laatste ontwikkelingen in en rond tech

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in