Formulierfouten uitleggen zodat iemand verder kan

Een formulierfout is een moment waarop een bezoeker hulp nodig heeft. Een rood kader en “Ongeldige invoer” vertellen zelden genoeg. De melding moet laten zien welk gegeven aandacht vraagt, waarom de invoer niet bruikbaar is en hoe iemand verder kan. Beoordeel foutmeldingen daarom als onderdeel van de inhoud en de interactie, niet als technische resttekst.

Schrijf vanuit de volgende handeling

Vermijd beschuldigende of abstracte formuleringen. “Vul een e-mailadres in waarop we kunnen antwoorden” is concreter dan “Validatie mislukt”. Wanneer een formaat nodig is, geef dan een duidelijk voorbeeld. Maak onderscheid tussen een leeg verplicht veld en een ingevulde waarde die niet wordt geaccepteerd. Die situaties vragen een andere aanwijzing.

In een fictief voorbeeld ontvangt een projectformulier een datum die vóór vandaag ligt. De bezoeker moet weten of dat werkelijk niet mag of dat een toelichting voldoende is. Als ook bestaande projecten kunnen worden aangemeld, is de validatieregel mogelijk verkeerd gekozen. Een foutmelding verbeteren begint soms dus met het herzien van de onderliggende vraag.

Plaats uitleg waar de fout kan worden hersteld

Geef feedback bij het betrokken veld en zorg bij meerdere fouten voor een bruikbaar overzicht. Een algemene melding bovenaan mag niet de enige aanwijzing zijn wanneer het formulier lang is. De W3C-documentatie over formuliermeldingen behandelt zowel terugkoppeling bij velden als een algemene bevestiging na verzending.

Gebruik kleur als ondersteuning, maar laat de tekst zelfstandig betekenis dragen. Controleer ook de samenhang tussen label, invoerveld en melding met de ontwikkelaar. Wat visueel naast elkaar staat, moet technisch op een begrijpelijke manier verbonden zijn. Zo kan de uitleg ook in andere manieren van bedienen en lezen beschikbaar blijven.

Bewaar wat de bezoeker al goed heeft ingevuld

Een fout in één veld mag niet zonder reden het hele formulier leegmaken. Test daarom niet alleen het verschijnen van meldingen, maar ook de overgebleven inhoud. Lange toelichtingen, eerder gekozen opties en bijlagen verdienen extra aandacht. Wanneer een onderdeel opnieuw nodig is, moet de pagina dat duidelijk vertellen.

Maak ook onderscheid tussen een invoerfout en een probleem bij het versturen. Bij een tijdelijke technische storing weet de bezoeker niet altijd of de aanvraag is ontvangen. De tekst moet die onzekerheid correct weergeven en een passende vervolgstap bieden. Verwijs alleen naar een andere contactroute wanneer die route ook werkelijk beschikbaar is.

Controleer fouten als vaste scenario’s

Gebruik een korte set proefaanvragen: een leeg formulier, een ontbrekend verplicht veld, een onjuist formaat en een poging met geldige gegevens. Voeg situaties toe die specifiek zijn voor het aanbod. Laat iemand zonder uitleg de fout herstellen en vraag waar die twijfelt. Controleer de route op mobiel en met het toetsenbord.

Leg de gekozen foutteksten vast bij de formulierdefinitie, zodat latere technische aanpassingen ze niet vervangen door standaardmeldingen. Bij een websiteproject hoort ook een bevestiging van succesvolle verzending in de oplevering. Bezoekers moeten immers niet alleen weten wat er fout ging, maar ook wanneer hun taak klaar is. Een goed formulier behandelt de eerste onjuiste poging als een normaal onderdeel van het invullen en geeft voldoende informatie om zelfstandig verder te gaan.

Vorig inzicht
Volgend inzicht

Begin met je vraag

Waar loopt jouw team op vast?

Een eerste vraag hoeft geen technische briefing te zijn. Vertel welke systemen je gebruikt en waar het werk nu blijft liggen. Samen bespreken we wat mogelijk is en welke stap je daarna kunt zetten.

Bespreek mijn vraag