Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Gebruikersvriendelijkheid geen doel, maar basisbehoefte

 

Expert

ing. Alexander Vermeulen
TOC-IT Consultant / Informatie Analyse Expert, Garansys. Expert van voor het topic .

Stel je voor: er is net een applicatie ter test aangeboden aan een groep gebruikers. Er is ruim voldoende interactie geweest met de gebruikers, je hebt hard gewerkt aan het systeem en er heeft een gedegen intern testtraject plaatsgevonden. Dan is het tijd voor de eerste testen door de gebruikers en dan komt het: de ene na de andere melding over 'gebruikersvriendelijkheid'. Het lijkt wel of men meer let op de layout van de schermen dan op de werking van het systeem…

Wat is gebruikersvriendelijkheid?

Als je de TMAP-definitie van gebruikersvriendelijkheid erop naslaat, lees je over het inleer- en bedieningsgemak van het systeem. Dat is natuurlijk een mooie kapstok, maar helaas houden gebruikers zich niet aan deze definitie. Gebruikers noemen heel veel dingen al dan niet 'gebruikersvriendelijk': de schermen zijn niet 'mooi', de performance is slecht, de installatie is lastig, etc.

Sommige bedrijven ontlenen hun bestaansrecht aan gebruikers die alles 'gebruikersvriendelijk' willen hebben, maar wat is dat nu eigenlijk? Mijn ervaring leert dat gebruikers gewoon een standaard verlangen, een aansluiting op datgene wat al bekend is en gebruikt wordt. Van het gros van de mensen die een nieuwe tv kopen, leest het merendeel maar één hoofdstuk in de handleiding: hoe moet je hem instellen? Daarna verdwijnt het boekje in de kast en voor de meest gebruikte functies pakt men blindelings de afstandbediening en gaat aan de slag. Meestal heeft men het met vijf minuten wel onder de knie. Wat kunnen we hiervan leren voor bedrijfsapplicaties? Dat men het niet als bezwaarlijk ervaart om voor ingewikkelde of niet vaak gebruikte functies een handleiding te raadplegen. Echter, veel gebruikte functies verwacht men binnen vijf minuten te kunnen.

Discussiepunt

Met dit in ons achterhoofd kijken wij eens naar onze praktijk als het gaat om applicaties. Hoe vaak ben je dan situaties tegengekomen zoals in de inleiding beschreven? Heb je dat ook als irritant ervaren? Want eigenlijk wil je focussen op het oplossen van een businessprobleem; gebruikersvriendelijkheid is hierbij eigenlijk helemaal geen discussiepunt. Mijn aanname daarbij is dat de gebruikers uiteraard de software naar behoren kunnen gebruiken, maar vooral nog esthetische wensen of bezwaren uiten. Als ict-professional beschouw je dit eigenlijk maar als een nare bijkomstigheid, want waarom besteden gebruikers gewoon niet meer aandacht aan de werkelijke functionaliteit van wat je gemaakt hebt?

Eigen boezem

Helaas, je dient hier de hand in eigen boezem te steken en dat kan je  ook! De oplossing ligt namelijk in een aantal aspecten: sluit aan bij algemene standaarden, manoeuvreer de verwachtingen van gebruikers richting deze standaarden en zorg dat ontwikkelaars deze standaard ook toepassen.

Sluit aan

Als wij weer kijken naar de tv, dan is er geen wereldwijde marktleider die een bepaalde bediening afdwingt. Toch zijn de tv-producenten zo verstandig om hun afstandbedieningen voor 90 procent op elkaar te laten lijken. Je hebt vast thuis ook drie à vier afstandbedieningen liggen. Leg ze maar eens naast elkaar en die ene met de afwijkende 'interface' vind je niet 'gebruikersvriendelijk'. Sterker nog, degene met de afwijkende afstandbediening diskwalificeert zichzelf. Deze fabrikant heeft er blijkbaar min-of-meer over nagedacht. Laten wij maar zeggen "ze hebben deze interface ontworpen". En dat vind ik nu diskwalificerend, want men had zo naar een elektronicazaak kunnen lopen, een tv van de concurrent kunnen kopen en de afstandbediening na kunnen maken. Is dat 'stelen'? Nee, dat is aansluiten bij een algemeen gangbare standaard. En dat is precies wat wij als ict-professionals moeten doen als wij applicaties ontwikkelen. Ga nu niet de gebruikersinterface zelf verzinnen, maar sluit gewoon aan bij de verwachtingen van de gebruiker. Wordt er gebruik gemaakt van Windows, gebruik dan ook de standaarden van Microsoft. Of je dat nu zelf wel of niet 'mooi' (of gebruikersvriendelijk!) vindt. Het gevolg is dat gebruikers de uiteindelijke applicatie sneller en makkelijker kunnen bedienen. En was dat nu niet de definitie van ‘gebruikersvriendelijk'?

Manoeuvreer de verwachting

Alleen zelf zo'n standaard toepassen is niet voldoende. Niet zelden projecteren gebruikers hun mening van 'mooi' en 'niet mooi' ook op de bedrijfsapplicaties. Wij spreken hier overigens niet over die (internet)applicaties waarbij gebruikersvriendelijkheid het onderscheidend vermogen vormt. Maar bij de meeste applicaties voegt het 'mooi' of 'handiger' vinden, niets toe aan de oplossing en de waarde daarvan. Nog sterker, het zorgt ervoor dat andere gebruikers het waarschijnlijk weer 'niet mooi' of 'onhandig' vinden. Sluit aan op een standaard en manoeuvreer de verwachtingen van de gebruiker ook daar naar toe, voor zijn/haar eigen bestwil.

Toepassen!

Tot slot komt de laatste stap. Dit is zeker niet de minst lastige. Nu je de standaard hebt en de verwachtingen van de gebruikers daar ook naar toe gemanoeuvreerd heeft, is het wel zo handig als ook de applicatie  zo ontwikkeld wordt! Ook bij analisten, ontwerpers en ontwikkelaars kom ik allerlei meningen tegen over 'mooi' en 'handig', maar net als bij de gebruiker doet het er niet toe. Ook hiermee moet je aan de slag en via interne testen controleren of men zich aan de standaarden houdt. Vergeet niet: we lossen een business probleem op!

Alexander Vermeulen
Systeemanalist
Caesar Groep

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2910185). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

De problematiek zit niet in het al of niet gebruiken van windows of andere standaarden maar het veel te laat betrekken van de eindgebruiker. De oplossing is hiervoor is ook al lang bekend. De agile projectaanpak!

In reactie op Niek:
Er staat in het artikel geen methodiek genoemd, omdat naar mijn mening dit probleem bij elke methodiek optreedt. Ook bij de Agile aanpak (naar mijn idee met name juist daar) moet je zorgen dat je een basis hebt voor scherm layout en applicatie gedrag.
Of geef jij aan dat je dit fenomeen nog niet bent tegengekomen in je agile sessies danwel op moment dat je je agile ontwikkelde software aan alle gebruikers ging uitrollen?

Waar ik op doel is dat de schermen moeten aansluiten op het werkproces. Hier kom je alleen achter als je de eindgebruiker vroegtijdig bij het ontwikkelproces betrekt EN de gelegenheid geeft om in de praktijk te testen.Desnoods bouw je een prototype waarmee je de "routes" kunt testen.

Geen eindgebruiker zal wakker liggen als er een sluitrondje links van het midden wordt gebruikt i.p.v. een standaard sluitkruisje rechtsboven. Natuurlijk is het wel belangrijk dat de programmeur zich bij de gangbare standaarden aansluit en wordt de leercurve hierdoor korter maar daar ligt niet de kern van het probleem!

Alexander, je kunt het misschien wat concreter maken met voorbeelden. Zo heeft de iPhone een hele consistente interface, waardoor de gebruiker na het gebruiken van een aantal apps al verwachtingen heeft die meestal waargemaakt worden. Kijk ik naar Windows mobile waarop ik tegenwoordig alleen nog Tomtom gebruik, dan mis ik die consistentie.
In diezelfde lijn heb je OSX, waarin de interface over het algemeen zeer consistent is. Dit komt niet alleen door hoe OSX werkt (1 menubalk e.d.), maar ook door de richtlijnen die programmeurs voorgeschoteld krijgen. Ga je de manual van Apple erop naslaan, dan kom je al heel snel de User Interface Guidelines tegen e.d. Daarnaast dwingt het OS een bepaalde consistentie af. Dus iedereen doet ook zijn best die consistentie te behouden, op een aantal applicaties na die geport worden, zoals Google's Picasa die met kunst en vliegwerk aan de praat gekregen is onder Linux en OSX.

Ga je nu vervolgens bij grote bedrijven kijken, dan kom je honderden applicaties tegen met allemaal verschillende manieren van werken, verschillende manieren van benoemen, etc. Dat is niet iets dat je 123 aan kan passen, maar het is wel een beleid wat in te voeren is, zodat over de loop van de komende jaren er een convergentie plaatsvind. Deze convergentie wordt, denk ik, makkelijker gemaakt door de opkomst van intranet applicaties bij veel bedrijven en instanties. Het beheer is makkelijker en het aanpassen van de layout is makkelijker, beide dankzij de centralisering van de software.

@Erik-Jan
Interessant dat je de iphone en windows mobile noemt. Windows mobile tracht zoveel mogelijk de look-and-feel van windows over te brengen (inclusief alle inconsistenties) maar daardoor sluit het niet aan bij de behoefte van de gebruiker. De iphone zet een hele nieuwe "standaard" waarmee intu?tief gebruik op een hoger plan is gekomen. Maar ook de iphone heeft een paar grote eigenaardigheden in de userinterface.

Ik ben het niet met je eens dat de nieuwe generatie webapplicaties tot een grotere standarisatie zouden kunnen leiden. Het onderscheidende vermogen is hierbij nu juist de userinterface. Maar zelfs als je voor je bedrijf zelf alle (web)applicaties ontwikkeld zal er door voortschrijdend inzicht en toename van de mogelijkhheden in de loop der jaren inconsistentie ontstaan tussen oude en nieuwe applicaties.

Ik moet het met Niek eens zijn dat ook ik merk dat juist met webapplicaties de verscheidenheid in user interface alleen maar groter wordt. De reden die ik daarbij zie is dat juist bij webapplicaties veel mensen ineens het idee krijgen dat ze een website moeten maken.

Een website is in mijn ogen een digitale folder van het bedrijf. In de website kunnen er (kleine) applicaties aanwezig zijn (zoals aanmelden voor een nieuwsbrief of een forum) die dan in dezelfde look-en-feel van de gehele "folder" dienen te zijn.

Een business applicaties is geen website en ook geen ipod. Gebruikers van business applicaties zijn er bij gebaat dat applicaties op elkaar lijken.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×