Microcopy: kleine woorden, groot verschil

In de demo hierboven staat twee keer hetzelfde veld met dezelfde knop. De eerste versie vraagt om “E-mail*”, meldt “Ongeldige invoer.” en eindigt met “VERSTUREN”. De tweede vraagt om “Je e-mailadres”, zegt erbij waarvoor (“voor ons antwoord, verder niets”), vertelt wanneer je iets hoort en eindigt met “Vraag je offerte aan”. Het veld is hetzelfde, de techniek ook. Alleen de woorden verschillen.

Die woorden heten microcopy. Hieronder lees je waar ze staan, hoe je ze schrijft, wat WCAG 2.2 ervan vraagt en hoe je ze test. Wat we over onze eigen sites zeggen, staat op hun casepagina.

Wat is microcopy?

Microcopy is elke korte tekst die iemand helpt iets te doen op je site of in je app. Het zijn zelden meer dan een paar woorden, en ze staan op de plek waar een bezoeker een keuze maakt: klik ik, vul ik dit in, ga ik door?

Het verschil met gewone webtekst zit in het doel. Een tekst op een dienstpagina legt uit en overtuigt: waarom jij, wat de klant krijgt, wat de volgende stap is. Microcopy begeleidt de handeling zelf. Hij hoeft niet meer te overtuigen; hij haalt de laatste twijfel weg. Zelfde vak, andere schaal. Over de langere teksten lees je meer in ons artikel over webteksten.

Omdat de teksten zo klein zijn, worden ze makkelijk vergeten. Dan blijft staan wat het systeem doet, zoals Versturen of Ongeldige invoer. Het goede nieuws: een betere knoptekst vraagt geen nieuw ontwerp, alleen aandacht.

Waar staat microcopy?

Overal waar een bezoeker iets moet doen of even twijfelt. Elke plek beantwoordt een eigen vraag:

• Knoppen en links: wat gebeurt er als ik klik, en zit ik dan ergens aan vast?
• Labels: wat moet ik hier invullen?
• Hulpteksten en voorbeelden: in welke vorm, en waarom vraag je dit?
• Foutmeldingen: wat ging er mis, en wat moet ik nu doen?
• Lege schermen: waarom zie ik niets, en hoe begin ik?
• Bevestigingen: is het gelukt, en wat gebeurt er nu?
• Statuslabels: wat betekent dit woordje bij een product, een winkel of een bestelling? Op snelrepareren.nl staan winkels met het label Geverifieerd of Niet geverifieerd.

Welke drie vragen stel je bij elke zin?

Eén: wat denkt de bezoeker op dit moment? Twee: wat moet hij weten om door te kunnen? Drie: wat is het kortste eerlijke antwoord daarop? Meer methode heb je niet nodig.

Neem de foutmelding uit de demo. “Ongeldige invoer” beschrijft het systeem: dat heeft iets afgekeurd. Wie het leest, weet nog steeds niet wat hij moet doen. “Dat e-mailadres mist een apenstaartje” beschrijft de oplossing. Zelfde fout, andere afloop.

Dezelfde drie vragen herschrijven ook je knoppen. Versturen zegt wat het systeem doet; Vraag je offerte aan zegt wat de bezoeker krijgt. Schrijf voor de kant die moet klikken.

Schrijf niet wat het systeem deed. Schrijf wat de gebruiker nu moet doen.

Hoe schrijf je een knop?

Een knop is een belofte: als je hierop drukt, gebeurt dit. Hoe preciezer de belofte, hoe minder iemand hoeft te raden.

• Begin met een werkwoord en zeg wat er gebeurt. Vraag je offerte aan, Schrijf je in, Bekijk de prijs. Het ontwerpsysteem van de Britse overheid zegt het zo: beschrijf de handeling die de knop uitvoert.
• Schrijf gewone zinsopbouw, geen hoofdletters. Datzelfde ontwerpsysteem raadt knopteksten aan met alleen een hoofdletter aan het begin. VERSTUREN in de demo valt daar dus buiten.
• Gebruik overal hetzelfde woord. Heet het in het menu Inschrijven, laat de knop en de kop van de pagina dan ook over inschrijven gaan.
• Zeg bij een formulier in stappen waar je bent. Een knop Volgende is prima tussen de stappen; de laatste knop zegt wat er dan echt gebeurt, zoals Verstuur aanvraag.
• Zet geen knop uit zonder uitleg. Een grijze knop die niets doet, laat de bezoeker raden wat er ontbreekt. De Britse overheid raadt uitgeschakelde knoppen af: ze hebben slecht contrast en verwarren sommige mensen. Laat de knop werken en zeg na de klik wat er mist.

Hoe schrijf je een label?

Een label zegt wat er in een veld hoort. Het staat bij het veld, het blijft staan als je typt, en het gebruikt de woorden van de bezoeker, niet die van je database. “Je e-mailadres” leest als een vraag van een mens; “E-mail*” als een kolom in een tabel.

• Elk veld een eigen label, ook elke keuze in een rijtje rondjes of vinkjes. Wie een vinkje zet, moet weten waarvoor.
• Een voorbeeld in het veld is geen label. De W3C schrijft dat zo'n voorbeeldtekst (een placeholder) verdwijnt zodra je begint te typen, vaak minder contrast heeft en door schermlezers niet als label wordt gelezen. Zet het label erboven.
• Zeg in woorden wat verplicht is, of juist wat niet. Een sterretje alleen moet je kennen. Zijn bijna alle velden nodig, zet dan (optioneel) achter de paar die het niet zijn. Ons eigen aanvraagformulier doet dat, bijvoorbeeld bij Omschrijving (optioneel).
• Splits wat je apart nodig hebt. Voornaam en achternaam in twee velden krijgen elk een eigen label.

Hoe schrijf je een hulptekst?

Een hulptekst staat bij een veld en beantwoordt de vraag die het label openlaat. Meestal is dat een van deze drie:

• Waarom vraag je dit? Wie zijn gegevens afgeeft, wil weten wat ermee gebeurt. In de demo staat bij het e-mailadres: voor ons antwoord, verder niets.
• In welke vorm? Een datum, een telefoonnummer, een postcode of een bestand met een maximale grootte. De W3C noemt dit expliciet: zeg welke vorm je verwacht, zeker als die afwijkt van wat mensen gewend zijn.
• Wat gebeurt er hierna? “Je hoort binnen twee werkdagen van ons” haalt de vraag weg of er wel iets met je aanvraag gebeurt.

Een hulptekst kan ook een fout voorkomen in plaats van herstellen. Op ArtsenPool, een platform voor artsen en ziekenhuizen dat nog niet gelanceerd is, waarschuwt elk formulier: vul geen medische of patiëntgegevens in. Bij nood: 112.

Houd het wel kort. De W3C schrijft bij de eis voor labels en instructies dat te veel informatie of instructie net zo schadelijk kan zijn als te weinig. Beantwoord alleen de vraag die de bezoeker hier echt heeft.

Hoe schrijf je een foutmelding?

Een goede foutmelding doet drie dingen: hij wijst het veld aan, zegt wat er niet klopt en zegt hoe je het oplost. In gewone woorden, zonder de bezoeker de schuld te geven.

Het NL Design System, een open verzameling ontwerpsystemen waaraan onder meer gemeenten, RVO en Logius bijdragen, geeft precies dit voorbeeld. Niet “Ongeldige invoer” of “Dit veld is verplicht”, maar “Vul een geldig e-mailadres in, bijvoorbeeld naam@voorbeeld.nl.” Of: “Vul het huisnummer in zodat wij je bestelling kunnen opsturen.” Het ontwerpsysteem zegt er ook bij: geef de gebruiker nooit de schuld, en zet een punt aan het eind, zodat een schermlezer een pauze neemt.

De Britse overheid gaat in haar ontwerpsysteem nog een stap verder. Ze raadt af om valid of invalid te schrijven, omdat die woorden niets toevoegen, en ook sorry, please en informele woorden als oops. Gebruik de woorden van het label in de melding, en lees hem hardop: klinkt het als iets wat je zelf zou zeggen?

Wanneer laat je de fout zien?

Niet terwijl iemand nog typt. Dat raden het Britse en het Nederlandse ontwerpsysteem allebei af. Het NL Design System noemt een melding die na de eerste letter verschijnt irritant en verwarrend; de Britse richtlijn wijst op mensen die langzamer typen. Daarna verschillen ze: het Britse controleert pas als je doorgaat of verstuurt, het Nederlandse ook als je een aangepast veld verlaat. Kies er een en toets hem met echte mensen.

Laat na een fout de invoer staan, schrijft de Britse richtlijn: wie een leeg formulier terugkrijgt, moet alles opnieuw doen. En staan er meer fouten op één pagina, zet dan bovenaan een samenvatting, naast de melding bij het veld zelf. Dat raden beide ontwerpsystemen aan.

Rood alleen is geen foutmelding. Wie kleuren slecht onderscheidt, ziet een rode rand niet. Zet de melding in woorden, met kleur als extra.

Wat zet je op een leeg scherm en in een bevestiging?

Een leeg scherm is een zoekopdracht zonder uitkomst of een overzicht zonder items. “Geen resultaten” is waar, maar laat de bezoeker staan. Zeg waarom het leeg is en wat hij nu kan doen. Bijvoorbeeld: “Geen resultaten voor ‘kroon’. Probeer een ander woord of bekijk alle behandelingen.”

Een bevestiging zegt drie dingen: het is gelukt, wat er nu gebeurt en wanneer. Ons eigen aanvraagformulier zegt na het versturen: Aanvraag verstuurd. Je aanvraag staat bij ons binnen. Je hoort meestal binnen twee werkdagen van ons.

Bij een formulier in stappen: vraag niet opnieuw wat de bezoeker al invulde. Wie in stap één zijn adres gaf, wil dat in stap drie niet nog eens typen. Sinds WCAG 2.2 is dat ook een eis.

Hoe ziet het verschil eruit, per soort tekst?

Alles hierboven op één plek. Links wat je vaak ziet, rechts een versie die de vraag van de bezoeker beantwoordt. Het zijn voorbeelden, geen vaste teksten: schrijf ze in je eigen woorden en voor je eigen formulier.

Wat vraagt WCAG 2.2 van je microcopy?

WCAG is de internationale richtlijn voor toegankelijke websites, van de W3C. Versie 2.2 is een W3C-aanbeveling; de huidige tekst is van 12 december 2024. Een deel van de eisen gaat letterlijk over woorden op knoppen en in formulieren. Dit zijn de belangrijkste, met het niveau erbij (A is het eerste niveau, AA het tweede):

Twee dingen vallen op als je de uitleg van de W3C leest. Ten eerste is de lat voor een foutmelding lager dan je denkt: volgens de uitleg bij 3.3.1 is “Email is not valid” al genoeg om de fout aan te wijzen. Hoe je het oplost, valt onder 3.3.3. Een goede melding doet beide. Ten tweede adviseert de W3C bij 2.5.3 om de naam in de code te laten beginnen met de tekst op de knop, zodat iemand met spraakbesturing hem met precies die woorden indrukt.

Of jouw organisatie wettelijk aan deze eisen moet voldoen, lees je in ons artikel over de Europese toegankelijkheidswet. Hoe je een site toegankelijk maakt, staat bij website toegankelijk maken.

Welke toon past bij microcopy?

Dezelfde toon als de rest van je site, maar rustiger. Een paar vuistregels:

• Kies je of u, en houd het vast. Een site die je zegt op de homepage en u in de foutmelding, klinkt als twee verschillende loketten.
• Wees direct, en grap niet bij een fout. Een knipoog op een pagina die niet bestaat kan passen. Bij een betaling die mislukt of een inschrijving die niet doorkomt, wil iemand alleen weten wat hij moet doen.
• Eén woord voor één ding. Leg vast welke woorden je gebruikt: aanvraag of offerteaanvraag, inschrijven of aanmelden. Een designsysteem legt vast hoe een knop eruitziet; leg daarin ook vast hoe hij heet.

Goede microcopy kan een druk scherm niet redden. Minder velden, één vraag per stap en geen dubbele boodschappen geven de woorden ruimte. En vertel eerlijk waarom je iets vraagt: eerlijkheid leest als rust.

De eindtest is simpel: lees je formulier hardop. Klinkt het als een mens aan de balie, of als een systeemmelding uit 2009? Je hoort het meteen.

Hoe test je of je microcopy werkt?

Je hebt er geen lab voor nodig:

1. Lees alles hardop, van de eerste knop tot de bevestiging.
2. Vul het formulier fout in. Laat een verplicht veld leeg, typ een e-mailadres zonder apenstaartje, kies een datum in het verleden. Staat elke fout in woorden bij het juiste veld, en blijft je invoer staan?
3. Doe het op een telefoon, met één hand. Zie je de foutmelding zonder te scrollen?
4. Doe het met alleen het toetsenbord en een schermlezer, zoals VoiceOver op een iPhone of Mac of NVDA op Windows. Hoor je het label bij elk veld, de foutmelding en de bevestiging?
5. Geef het aan iemand die je site niet kent, met een echte taak: schrijf je in, vraag een offerte aan. Kijk mee en zeg niets.
6. Kijk in je statistieken per stap, als je die hebt: waar haken mensen af? Verander één ding tegelijk.

Bij een UX-audit lopen wij de routes na van landing tot aanvraag, met formulieren en teksten. Bij UI/UX-design krijgt elke knop en elk veld zijn situaties mee, ook wat er verschijnt als iets misgaat.

Wanneer dit niet geldt

Microcopy repareert geen formulier dat te veel vraagt. Vraag je twaalf velden waar er vier genoeg zijn, schrap dan eerst velden; betere labels maken een lang formulier niet kort. En is je aanbod of je prijs onduidelijk, dan haalt geen knoptekst dat weg. Begin dan bij conversie-optimalisatie.

Bij juridische teksten, zoals toestemming voor nieuwsbrieven, voorwaarden of een privacyverklaring, telt precisie meer dan kortheid. Een kortere zin kan daar iets anders betekenen. Laat zulke teksten nakijken door iemand die de regels kent.

Wat we niet weten: we hebben niet gemeten hoeveel extra aanvragen betere microcopy op onze eigen sites of die van klanten opleverde, en we noemen daarom geen getal. De Britse richtlijnen zijn geschreven voor Engelstalige overheidsdiensten, en de richtlijnen van het NL Design System zijn volgens de site zelf nog in beta. En WCAG is een ondergrens: wie aan alle eisen voldoet, weet daarmee nog niet of mensen de tekst begrijpen. Dat weet je pas als je het ze laat proberen.

Benieuwd waar jouw formulier schuurt? Stuur ons de link van je formulier of aanvraagpagina, dan kijken we mee. Meer over hoe we schermen en formulieren ontwerpen, lees je bij UI/UX-design, en wat een grondige doorlichting oplevert bij de UX-audit. Je werkt rechtstreeks met Nawid; per project zet hij een vast team van specialisten in.