Metaforen zijn verraderlijk

Af en toe help ik mensen die in de problemen zitten met hun computer en programma’s. Op die momenten herken je vaak ontwerpfouten, die je zelfs als expert soms over het hoofd ziet. Al die drempels om de computer en programma’s goed te gebruiken zijn het waard om een oplossing voor te vinden.

Zo hielp ik iemand met Apple’s professionele foto­bewerkings­programma, Aperture. Hij is net van iPhoto afgestapt, naar Aperture en heeft al zijn foto’s netjes erin geïmporteerd. Maar tja, iPhoto is geen Aperture en het verschil in hoe je foto’s organiseert is groot. In Aperture bepaal je zelf hoe je je projecten indeelt: per jaar; naar categorie; naar familie; of…. Je mag het allemaal zelf bedenken. Ik heb hem uitleg gegeven en alles voor hem zo gezet dat hij met een verse start z’n nieuwe foto’s kan toevoegen.

Screenshot van Aperture met een project-doos in een folder.

Wat hij nou raar vond van Aperture was dat je een project in een folder kan stoppen. Het icoon van een project is een doos en de folder is afgebeeld als een klein mapje: Je kunt toch geen doos in een kleine map stoppen? En daar heeft hij groot gelijk in. Je kan geen doos in een hangmap stoppen maar wel een hangmap in een doos, andersom dus. Iconen sugge­reren hoe je je foto’s zou moeten organiseren. Alleen in dit geval gaat het dus mis. Hier is een verkeerde metafoor gekozen.

Metaforen wekken verkeerde verwachtingen

Het doel van een metafoor is om een relatie te leggen tussen wat iemand al kent en wat nieuw voor hem is. Het roept een verwachting bij de gebruiker op. Maar welke verwachting roept het op? Het roept een verwachting op die leeft in de belevings­wereld, de context, van de gebruiker terwijl de metafoor gemaakt is vanuit de context van de ontwerper. De gebruiker past de meta­foor toe, maar hoe lang? Tot welk moment blijft de metafoor van de ontwer­per geldig? De daadkracht van een metafoor houdt ergens op, maar wanneer? En dat wist de gebruiker van Aperture niet.

De gebruiker gaat vervolgens fouten maken, wordt onzeker en verliest grip op zijn data. Een verkeerde verwachting is misleidend en ernstiger dan geen verwachting. Wees daarom terughoudend met metaforen. Implementeer metaforen tot binnen een enkele laag en zorg ervoor dat het bij gebruikers geen verkeerde verwachtingen oproept.

Gebruik idiomen

Idiomen daarentegen, zijn juist heel geschikt om in user interfaces te gebruiken, omdat ze, anders dan metaforen, context-onafhankelijk zijn. Het zijn opzichzelfstaande concepten. Uitdrukkingen (ook idiomen) bijvoorbeeld kan je in verschillende situaties gebruiken. De betekenis blijft voor iedereen helder en eenduidig.

Een gebruiker verwacht geen relaties tussen idiomen onderling omdat ze zo context-onafhankelijk zijn en niet verder reiken dan hun eigen domein. Als user interface ontwerper introduceer je ook nieuwe idiomen, zoals een reddingsboei als icoon voor ondersteuning, help. Gebruikers doorzien dat direct en snappen dat een reddingsboei is om te helpen, ook zonder de illustratie van een boot op zee of in de haven erbij: context-onafhankelijk dus.

All idioms must be learned; good idioms need to be learned only once.

A. Cooper, R. Reinmann & D. Cronin, 2007, About Face 3, p.275.

Begrip voor idiomen is, net als voor metaforen, afhankelijk van cultuur en achtergrond, maar doordat ze juist opzichzelfstaande concepten zijn kan een gebruiker de user interface veel makkelijker stap-voor-stap onder de knie krijgen. Daarnaast kan je als user interface ontwerper idiomen voordelig hergebruiken zonder rekening te houden met een onbekende context.

Bart van de Biezen

Bart van de Biezen

Als cognitief ergonoom bij Aan Zee Communicatie, onderzoek, ontwerp, spreek en schrijf ik over user interfaces en usability. M'n achtergrond: Industrieel Ontwerpen en daarna Psychologie aan de Universiteit Twente, afgestudeerd bij Philips op midair pointing voor een nieuwe generatie TV's, Apple Design Award voor CSSEdit, usability onderzoeker bij MetrixLab en blogger.