Yes/No/Cancel zorgt voor een stijging in de verkoop van aspirine

Dit online magazine (of blog) gaat over gebruiksvriendelijkheid, en het gebrek daaraan. Het bekritiseert slecht design en promoot goed design. Men zou kunnen denken dat mensen inmiddels geleerd hebben hoe ze het goed moeten aanpakken, aangezien er al jaren onderzoek naar usability wordt gedaan en er talloze boeken over zijn geschreven. Maar dat is niet het geval; mijn indruk is dat veel producten nog steeds net zo slecht zijn als ooit. Het doel van dit magazine is om het bewustzijn over deze problemen te vergroten.

Waarom is dit belangrijk?

Als gebruiker zou dit je moeten interesseren omdat je een keuze hebt: je kunt stoppen met het gebruiken of kopen van producten die niet gebruiksvriendelijk zijn. Door over te stappen naar een beter alternatief bespaar je jezelf frustratie en ergernis. Als fabrikant is de reden nagenoeg hetzelfde: je bevindt je in een concurrerende omgeving. Als je niet zorgvuldig nadenkt over de behoeften van je klanten, zullen zij je spoedig verlaten.

De oorsprong van de naam

Je vraagt je misschien af waar de naam van deze website vandaan komt. Yes/No/Cancel klinkt als computers, en een groot deel van de inhoud (hoewel zeker niet alles) zal inderdaad over computersoftware gaan. Tegenwoordig behoren veel softwarepakketten tot de meest complexe technische constructies die de menselijke geest heeft bedacht. Het is daarom niet verrassend dat sommige programma's extreem moeilijk in gebruik zijn.

Software wordt echter dagelijks gebruikt door mensen die niets willen weten van deze complexiteit. Is die moeilijkheid echt noodzakelijk? Er zijn voorbeelden van extreem complexe systemen die absoluut eenvoudig te bedienen zijn (denk aan Google Search; het resultaat van jaren werk door een groot team van de beste software-engineers ter wereld, maar voor de gebruiker is het slechts een eenvoudig zoekveld).

Het toegankelijk maken van gecompliceerde systemen is een lastig probleem. Deels komt dit doordat de engineers die het systeem ontwerpen gewend zijn aan een bepaalde manier van werken, die niet altijd het beste is aangepast aan een specifieke situatie of doelgroep. Ontwerpers en ontwikkelaars moeten daarom constant hun eigen gewoonten in twijfel trekken om betere oplossingen te vinden.

Het probleem met Yes/No/Cancel-knoppen

Er is één specifieke slechte gewoonte van programmeurs die me zo erg irriteert dat ik heb besloten de website ernaar te noemen: de keuze tussen 'Ja', 'Nee' en 'Annuleren' (Yes/No/Cancel). Deze keuze wordt je in veel applicaties voorgelegd, en vaak moet je even stoppen en nadenken omdat het niet direct duidelijk is wat elke optie precies doet. Welke knop zorgt ervoor dat al je werk verloren gaat? Welke knop slaat het op? En wat betekent 'Annuleren' in deze context eigenlijk? Het veroorzaakt letterlijk hoofdpijn.

Een veelvoorkomende situatie waarin je een Yes/No/Cancel-dialoogvenster tegenkomt, is wanneer je een document probeert te sluiten zonder het op te slaan. In sommige gevallen is de vraag duidelijk, maar in andere gevallen is de vraag tegenstrijdig. Wanneer een programma een tegenovergestelde vraag stelt, moet je plotseling nadenken, zelfs als je uit gewoonte weet welke knop je normaal gesproken zou indrukken. Bovendien is het vaak onduidelijk wat het verschil is tussen 'Nee' en 'Annuleren'.

De logica achter de verwarring

Fundamenteel is het probleem hier dat er eigenlijk twee vragen tegelijk worden gesteld:

1. Wil je het document opslaan?
2. Wil je de applicatie afsluiten?

Het antwoord op elke vraag kan 'ja' of 'nee' zijn, wat leidt tot vier mogelijke acties:

• Wijzigingen opslaan en afsluiten (de 'Ja'-knop in een standaardvoorbeeld).
• Wijzigingen negeren en afsluiten (de 'Nee'-knop in een standaardvoorbeeld).
• Niets doen – niet opslaan en niet afsluiten (de 'Annuleren'-knop).
• Wijzigingen opslaan, maar niet afsluiten.

De vierde optie wordt over het algemeen als onlogisch beschouwd, waardoor er geen knop voor is en we overblijven met een keuze uit drie. In een slecht voorbeeld kan het klikken op 'Ja' echter betekenen dat je wijzigingen negeert en afsluit. Wie weet dan wat 'Nee' of 'Annuleren' doet, om nog maar te zwijgen over het mysterie van het rode kruisje in de hoek.

Uit deze eenvoudige voorbeelden blijkt dat het een slecht idee is om knoppen te labelen als Ja, Nee en Annuleren. De betekenis van deze woorden is namelijk sterk afhankelijk van de vraag. Een gebruiker wil simpelweg weten welke knop ervoor zorgt dat het werk van de afgelopen twee uur verloren gaat, en deze labels maken dat niet direct duidelijk.

Een betere aanpak: beschrijvende labels

Apple heeft geprobeerd dit probleem te vermijden door knoppen niet te labelen met Ja/Nee/Annuleren, maar met beschrijvende termen. Het gebruik van een werkwoord (zoals "Opslaan") wordt aanbevolen in de Human Interface Guidelines van Apple.

Daarnaast wordt de 'gevaarlijke' knop (die wijzigingen negeert en afsluit) visueel gescheiden van de twee 'veilige' knoppen. Dit is al aanzienlijk beter, hoewel het programma nog steeds probeert twee vragen tegelijk te beantwoorden, wat als een onnodige complicatie kan worden beschouwd.

Dit geldt niet alleen voor Microsoft of Apple, maar voor elke organisatie of persoon die software schrijft. Er zijn terrible voorbeelden van Yes/No/Cancel in de wereld waar geen van beide bedrijven verantwoordelijk voor is.

Impliciete herlabeling en negatieve vragen

Een ernstige fout is de 'impliciete herlabeling' van knoppen. Hierbij heeft de programmeur geen moeite gedaan om eigen knoppen te maken, maar legt de last bij de gebruiker. De gebruiker moet dan echt goed nadenken om te bepalen welke knop hij moet indrukken. Door de vraag vervolgens slecht te formuleren, wordt het nog erger.

Dit brengt ons bij het punt van negatieve vragen. Waarom zou je vragen of je iets niet wilt doen (het negatieve), als je simpelweg kunt vragen of je iets wel wilt doen (het positieve)? Ik zie dit bijzonder vaak gebeuren bij selectievakjes (checkboxes). Het is contra-intuïtief om een vinkje te zetten in een vakje voor iets wat je niet wilt. Stel simpelweg geen negatieve vragen.

Slotopmerkingen

• Deze website is niet gerelateerd aan de webcomic OK/Cancel, hoewel we over soortgelijke onderwerpen spreken.
• Windows Vista staat het herlabelen van knoppen toe (zie het artikel en de discussie door Raymond Chen). Dit artikel toont aan dat Vista deze herlabeling niet daadwerkelijk consistent toepast en contrasteert verschillende richtlijnen voor menselijke interfaces.
• Je hebt misschien gemerkt dat het voorbeeld van impliciete herlabeling eigenlijk een geval van Abort/Retry/Ignore was. Ik overwoog aanvankelijk om dat de naam van deze site te maken, maar gelukkig is Abort/Retry/Ignore inmiddels grotendeels uitgestorven. Er bestaat overigens een uitstekend gedicht over Abort/Retry/Ignore, geïnspireerd door E.A. Poe.