Foutmeldingen schrijven waarmee iemand verder kan

Een foutmelding vertelt wat een handeling tegenhoudt en hoe iemand verder kan. Begin met het vastgestelde probleem, benoem relevante gevolgen en geef een uitvoerbare volgende stap. Schrijf alleen wat het systeem of de organisatie werkelijk weet. “Probeer opnieuw” is geen veilige standaard wanneer een handeling misschien al is uitgevoerd.

Een foutmelding is daarmee onderdeel van de dienstverlening, geen technisch restscherm. De lezer moet kunnen begrijpen of hij iets moet aanpassen, wachten of hulp vragen. Niet ieder probleem is zijn fout. Een rustige, precieze melding voorkomt dat de tekst schuld of zekerheid toevoegt die niet bij de situatie past.

Onderscheid invoerproblemen van storingen

Bij een invoerprobleem kan iemand vaak zelf iets corrigeren, zoals een ontbrekend verplicht gegeven. Bij een storing kan de oorzaak buiten zijn invloed liggen. Gebruik voor die situaties geen identieke melding. “Controleer uw gegevens” is misleidend wanneer de server tijdelijk niet bereikbaar is.

Maak een lijst met fouttoestanden en laat de technisch verantwoordelijke bevestigen wat vaststaat. Noteer of gegevens zijn bewaard, of een handeling is uitgevoerd en of opnieuw proberen verantwoord is. Een redacteur kan deze feiten niet uit de naam van een technische foutcode afleiden.

De W3C-uitleg over foutidentificatie beschrijft dat automatisch vastgestelde invoerfouten herkenbaar moeten worden gemaakt en in tekst moeten worden beschreven. De precieze implementatie vraagt meer dan alleen goede woorden, maar de tekst moet in elk geval het betreffende probleem benoemen.

Schrijf de melding in drie onderdelen

Gebruik als werkmodel: probleem, gevolg en herstel. Niet iedere melding heeft drie zinnen nodig. Bij een leeg verplicht veld kan “Vul uw e-mailadres in” voldoende zijn. Bij een mislukte verzending zijn gevolgen zoals wel of niet ontvangen juist belangrijk.

Vermijd technische details die de lezer niet kan gebruiken. Een intern foutnummer kan nuttig zijn voor ondersteuning, maar leg daarnaast in gewone taal uit wat er gebeurt. Publiceer geen gevoelige systeeminformatie. Ook de melding zelf mag niet meer over andere gebruikers of accounts onthullen dan passend is.

Een fictieve oefening met drie verschillende fouten

Het aanvraagformulier van Voorbeeldwinkel is verzonnen. De volgende meldingen zijn oefenteksten, geen beschrijving van een bestaand systeem. In de eerste situatie ontbreekt een verplicht postcodeveld. De melding luidt: “Vul uw postcode in.” Ze staat bij het betreffende veld en noemt dezelfde term als het label.

In de tweede situatie is een bestand te groot. De fictieve toepassing accepteert in deze oefening bestanden tot 5 MB. De melding wordt: “Dit bestand is groter dan 5 MB. Kies een kleiner bestand.” Die grens mag in een echte melding alleen staan als de toepassing ze werkelijk hanteert. De voorbeeldgrens is geen algemene aanbeveling.

In de derde situatie is de verzendstatus onbekend na een verbindingsprobleem. “Uw aanvraag is niet ontvangen, probeer opnieuw” zou te stellig zijn. De tekst moet aansluiten op wat de organisatie kan vaststellen, bijvoorbeeld: “We kunnen de verzending nu niet bevestigen. Controleer eerst uw aanvragenoverzicht voordat u opnieuw verstuurt.” Ook die route kan alleen worden aangeboden als dat overzicht werkelijk bestaat.

Geef een herstelstap die uitvoerbaar is

“Gebruik geldige gegevens” legt de oplossing bij de lezer zonder te vertellen wat geldig is. Noem het verwachte formaat wanneer dat nodig is, of pas liever de invoer aan als een onnodig streng formaat de fout veroorzaakt. Een formulier dat spaties redelijkerwijs kan verwerken, hoeft die niet per se als gebruikersfout te behandelen.

De W3C-uitleg over foutsuggesties behandelt het aanbieden van bekende correctiesuggesties, met aandacht voor de situatie. Geef geen suggestie die beveiliging ondermijnt of een onjuiste inhoudelijke keuze oplegt. Een onbekend klantnummer mag niet worden “hersteld” door gegevens van een ander account te tonen.

Koppel het probleem aan een duidelijke volgende stap. Een knop Opnieuw proberen moet daadwerkelijk een passende herhaling uitvoeren. De tekst kan niet zelfstandig garanderen dat die handeling veilig is.

Houd invoer en context beschikbaar waar dat kan

Laat iemand niet onnodig opnieuw beginnen omdat één veld ontbreekt. Bespreek met het technische team welke gegevens bewaard kunnen blijven en welke om veiligheidsredenen niet. Meld het als de gebruiker opnieuw informatie moet invullen. Maak geen belofte over bewaarde gegevens die de toepassing niet nakomt.

Een foutoverzicht bovenaan kan helpen bij meerdere invoerproblemen, naast aanwijzingen bij de velden zelf. De juiste technische verbindingen en focusvolgorde moeten worden gecontroleerd. Een rode rand alleen is onvoldoende uitleg. De gids over toegankelijke teksten behandelt taal als onderdeel van die bredere toegankelijkheid.

Laat stijl de oplossing ondersteunen

Gebruik dezelfde termen als in de labels en microcopy. Verander een “aanvraag” niet plots in een “ticket” omdat het interne systeem dat woord gebruikt. Houd de aanspreekvorm consequent en vermijd beschuldigingen zoals “u heeft iets verkeerd gedaan”.

Een verontschuldiging kan passend zijn bij hinder, maar is geen herstelstap. “Oeps, dat ging mis!” zegt weinig over de toestand. Voeg feiten toe of formuleer opnieuw. Vermijd ook geruststellingen zoals “alles is veilig” wanneer u alleen weet dat een verzending tijdelijk niet lukt.

Maak hulp vragen gericht en terughoudend

Wanneer zelf herstellen niet kan, bied een bestaand contactpunt en benoem welke informatie nuttig is. Denk aan het tijdstip, de uitgevoerde stap of een onschuldig referentienummer. Vraag geen wachtwoord, betaalkaartgegevens of onnodige persoonlijke informatie om een algemene fout te onderzoeken.

Een terugkerende vraag kan later een FAQ-antwoord opleveren, maar laat een foutmelding niet alleen naar een algemene helpstartpagina sturen. De lezer heeft op dit moment een concrete blokkade. Het eerste antwoord hoort zo dicht mogelijk bij die blokkade te staan.

Controleer de melding in de echte toestand

Lees de melding met de bijbehorende velden en knoppen. Is het verkeerde veld herkenbaar? Is het gevolg correct? Werkt de herstelroute? Neem fouttoestanden op in uw controle na publicatie, met geschikte oefengegevens en zonder onbedoelde echte transacties.

Bewaar tekst en technische toestand samen. Als de verwerking later verandert, moet de melding mee veranderen. Een inhoudelijk goede foutmelding is geen vaste zin uit een woordenlijst; ze is een juiste uitleg van een specifieke toestand op een specifiek moment.

Bronnen bij deze gids

• W3C: foutidentificatie, voor het herkenbaar benoemen van invoerfouten.
• W3C: foutsuggesties, voor passende hulp bij correctie.