Als iemand een fout tegenkomt in je formulier, is hij één moment verwijderd van vertrekken. Onderzoek laat zien dat meer dan 75% van de gebruikers een formulier verlaat als er fouten verschijnen en ze die niet direct kunnen oplossen. Dat is geen klein probleem. Dat zijn drie van de vier potentiële klanten, leads of aanmeldingen die weglopen. Het verschil tussen behouden en verliezen komt vaak neer op één ding: de foutmelding. Een verwarrende foutmelding stuurt ze weg. Een duidelijke, behulpzame foutmelding haalt ze terug en laat ze het formulier afmaken.
Een foutmelding is de kans van je formulier om iemand naar voltooiing te leiden als die een fout maakt. Een slechte foutmelding (vaag, beschuldigend of onbruikbaar) laat de gebruiker in verwarring achter of met een schuldgevoel. Een goede foutmelding vertelt precies wat er misging, waarom het ertoe doet en hoe je het oplost, in gewone taal. Dit artikel laat zien hoe je foutmeldingen schrijft die werken, waar je ze plaatst zodat ze niet te missen zijn, welke toon echt vertrouwen wekt en waarom duidelijkheid het verschil maakt tussen afhaken en voltooien.
Wat een foutmelding effectief maakt
Een effectieve foutmelding doet drie dingen. Ten eerste zegt hij duidelijk wat er misging. Niet "Ongeldige invoer." Maar "E-mailadressen hebben een @-teken nodig." Ten tweede legt hij uit waarom de invoer is afgewezen, als dat helpt. "Wachtwoorden moeten minstens 8 tekens hebben, omdat kortere makkelijker te kraken zijn." Ten derde vertelt hij de gebruiker precies wat hij hierna moet doen. "Ga terug naar het wachtwoordveld en voeg minstens 4 tekens toe." De gebruiker kent nu het probleem, begrijpt waarom het ertoe doet en weet hoe hij het oplost.
De toon van een foutmelding doet meer ertoe dan de meeste mensen beseffen. Een foutmelding die boos of neerbuigend klinkt, geeft de gebruiker het gevoel dat hij de schuld krijgt. "Je bent het @-teken vergeten" voelt als zijn fout. "E-mailadressen hebben een @-teken nodig" is dezelfde informatie, maar zonder schuldvraag. Een behulpzame toon erkent de fout zonder dat de persoon zich slecht voelt.
Het moment en de plek van een foutmelding bepalen of de gebruiker hem überhaupt ziet. Een foutmelding die drie schermen onder het veld verschijnt dat de fout veroorzaakte, is makkelijk te missen. Een foutmelding naast het veld met de fout, op het moment dat de gebruiker verder wil, dwingt hem om het op te merken en direct op te lossen.
Validatie tijdens het invullen of bij het versturen
Validatie tijdens het invullen toont een foutmelding op het moment dat iemand een veld onjuist invult, voordat hij het formulier verstuurt. Een wachtwoordveld toont een fout zodra iemand een te kort wachtwoord typt. Een e-mailveld toont een fout zodra iemand het veld verlaat zonder @-teken. Feedback in realtime is krachtig, omdat mensen fouten direct herstellen in plaats van ze te ontdekken na het invullen van het hele formulier.
Validatie tijdens het invullen doet één ding bijzonder goed. Het geeft vertrouwen. Typt iemand een e-mailadres en ziet hij een groen vinkje verschijnen, dan weet hij dat het goed is. Hij gaat zonder twijfel verder. Zonder die bevestiging vraagt hij zich af of zijn invoer klopte en twijfelt hij aan zichzelf.
Validatie bij het versturen gebeurt als iemand op verzenden klikt en het formulier alle velden tegelijk controleert. Heeft een veld een fout, dan verschijnt bovenaan het formulier een samenvatting met alle problemen en wordt elk veld met een fout gemarkeerd. Validatie bij het versturen vangt fouten op die validatie tijdens het invullen miste en geeft gebruikers een compleet beeld van wat moet worden hersteld.
De beste aanpak is allebei. Gebruik validatie tijdens het invullen voor velden die direct te controleren zijn (e-mailformaat, lengte van wachtwoord, formaat van postcode). Gebruik validatie bij het versturen als laatste vangnet. Klikt iemand op verzenden en heeft een veld nog een fout, laat dan direct zien wat moet worden hersteld voordat hij kan versturen.
Foutmeldingen schrijven die specifiek zijn en tot actie leiden
Een specifieke foutmelding vertelt de gebruiker precies wat het probleem is. Een algemene foutmelding laat hem raden. Vergelijk deze twee:
Algemeen: "Ongeldig telefoonnummer."
Specifiek: "Telefoonnummers hebben 10 cijfers nodig. Je hebt er 9 ingevoerd. Voeg nog één cijfer toe."
De algemene melding vertelt de gebruiker wat er mis is, maar niet waarom of hoe hij het oplost. De specifieke melding vertelt het probleem, waarom het gebeurde en precies wat te doen. De specifieke melding kost iets meer leestijd, maar bespaart de gebruiker minuten frustratie.
Een foutmelding die tot actie leidt, bevat instructies. "Wachtwoorden moeten minstens één cijfer bevatten" vertelt wat er ontbreekt. "Wachtwoorden moeten minstens één cijfer bevatten. Ga terug naar het wachtwoordveld en voeg een cijfer toe." vertelt wat je moet doen. Bij formulieren is de instructie meestal vanzelfsprekend (ga terug naar het veld), maar uitschrijven helpt mensen die niet vertrouwd zijn met formulieren of hulpmiddelen gebruiken.
Gebruik gewone taal. Niet "Formaat van postcode onjuist." Maar "Postcodes bestaan uit 5 cijfers. Je hebt letters ingevoerd." Niet "Ongeldig e-mailformaat." Maar "E-mailadressen hebben een @-teken en een domein nodig (voorbeeld: naam@bedrijf.com)."
Een plek waar fouten niet te missen zijn
Een foutmelding ver van het veld dat de fout veroorzaakte, is makkelijk te missen. Vult iemand een formulier met veel velden in, dan richt hij zich op één veld tegelijk. Een foutmelding die onderaan het formulier verschijnt terwijl hij nog bovenaan bezig is, blijft onopgemerkt.
De beste plek voor een foutmelding is direct onder of naast het veld met de fout. Gaat iemand naar het volgende veld of probeert hij te versturen, dan verschijnt de foutmelding direct onder het veld dat hij net invulde. Hij kan er niet omheen, omdat die verschijnt waar hij de volgende actie verwacht.
Plaats een samenvatting van validatiefouten (alle fouten tegelijk na het versturen) bovenaan het formulier. Zo krijgt de gebruiker een compleet beeld van alle problemen. Scrolt hij daarna omlaag, dan verschijnen de afzonderlijke veldfouten opnieuw naast elk veld dat hij moet herstellen. Deze dubbele aanpak dient twee doelen: hij laat zien wat er allemaal moet gebeuren en herinnert eraan bij elk veld dat hij aanpakt.
Gebruik in formulieren nooit foutmeldingen als toast. Een toast is een melding die kort in de hoek van het scherm verschijnt en dan verdwijnt. Bij formulieren is dat de slechtst mogelijke plek. De fout verschijnt ver van het veld dat hem veroorzaakte. Hij verdwijnt voordat de gebruiker tijd heeft om te lezen. Er ontstaat een kloof tussen het probleem en de plek om het op te lossen. Moet een foutmelding verdwijnen, dan pas nadat de gebruiker het veld heeft hersteld.
Visueel ontwerp van foutmeldingen
Kleur alleen is niet genoeg om een fout te laten zien. Iemand met kleurenblindheid ziet de rode kleur die een fout aangeeft misschien niet. Een heel klein foutpictogram kan iemand met een slecht zicht missen. Vertrouw op meerdere signalen: kleur plus tekst plus pictogram.
Een rode rand om het veld. Een rood of oranje pictogram naast de foutmelding. Tekst die het probleem duidelijk benoemt. Alle drie samen vormen een foutstatus die bijna iedereen herkent.
Lettergrootte doet ertoe. De tekst van de foutmelding moet even groot zijn als het label van het veld. Is de foutmelding kleiner, dan missen mensen hem misschien of denken ze dat hij minder belangrijk is dan hij is. De foutmelding verdient hetzelfde visuele gewicht als het label.
Ook het label van het veld met het probleem kan veranderen. De labeltekst kan rood of vet worden. Dat is nog een visueel signaal dat de gebruiker helpt het formulier snel te scannen en het veld te vinden dat aandacht nodig heeft.
Toon en beleefdheid in foutmeldingen
Foutmeldingen moeten klinken alsof je iemand helpt, niet beschuldigt. Vermijd woorden die hard of beschuldigend klinken.
Hard: "Je hebt een ongeldig e-mailadres ingevoerd."
Behulpzaam: "E-mailadressen hebben een @-teken nodig. Controleer je invoer en probeer het opnieuw."
Hard: "Wachtwoord is te zwak."
Behulpzaam: "Wachtwoorden hebben minstens 8 tekens nodig. Langere wachtwoorden zijn veiliger."
Hard: "Je bent vergeten dit veld in te vullen."
Behulpzaam: "Dit veld is verplicht. Laat ons weten wat je ervan vindt."
Een behulpzame toon erkent de fout zonder dat de persoon zich slecht voelt. Hij legt uit waarom de regel bestaat (als dat helpt). Hij gaat verder zonder bij de fout stil te staan.
Veelgemaakte fouten in foutmeldingen
De meest voorkomende fout is te vaag zijn. "Ongeldige invoer" vertelt de gebruiker niets. "Er ging iets mis" is even nutteloos. Wees specifiek over wat het probleem is.
Een tweede fout is technisch taalgebruik. "Regex komt niet overeen" of "Validatie mislukt" betekent misschien iets voor ontwikkelaars, maar gewone mensen hebben geen idee wat deze termen betekenen. Vertaal technische fouten naar gewone taal.
Een derde fout is te veel fouten tegelijk tonen. Heeft een formulier 20 velden en tonen alle 20 een fout, dan voelt de gebruiker zich overweldigd. Bepaal welke fouten kritiek zijn (zoals een leeg verplicht veld) en toon die eerst. Minder belangrijke fouten (zoals een opmaakprobleem in een optioneel veld) kun je daarna tonen.
Een vierde fout zijn foutmeldingen die het label herhalen zonder nieuwe informatie toe te voegen. Het label zegt "E-mailadres." De foutmelding zegt "E-mailadres is ongeldig." De gebruiker weet al welk veld het probleem heeft (hij ziet de rode rand), maar weet nog steeds niet waarom het ongeldig is. De foutmelding moet informatie toevoegen, niet het label herhalen.
Een vijfde fout is geen weg bieden om het probleem op te lossen. "Wachtwoord voldoet niet aan de eisen" vertelt de gebruiker dat er iets mis is, maar niet wat de eisen zijn. "Wachtwoord voldoet niet aan de eisen. Wachtwoorden hebben minstens 8 tekens en één cijfer nodig" vertelt wat hij moet herstellen.
Zo helpt WEMASY je duidelijke foutmeldingen te maken
De formulierbouwer van WEMASY bevat vooraf gemaakte foutmeldingen voor veelgebruikte veldtypen. E-mailvelden tonen "E-mailadressen hebben een @-teken nodig" als het formaat niet klopt. Telefoonvelden tonen "Telefoonnummers hebben 10 cijfers nodig" als de lengte niet klopt. Wachtwoordvelden tonen de eisen aan de sterkte terwijl de gebruiker typt. Deze meldingen zijn standaard duidelijk, specifiek en behulpzaam.
Je past foutmeldingen aan op de toon van je merk. Verander de melding van "E-mailadressen hebben een @-teken nodig" in "Oeps, dat lijkt niet op een e-mailadres. Nog eens proberen?" De toon verandert, maar de duidelijkheid blijft. Je bepaalt hoe de melding klinkt zonder in te leveren op helderheid.
Voor eigen validatie (velden met specifieke regels die uniek zijn voor jouw formulier) schrijf je je eigen foutmeldingen direct in de formulierbouwer. Het systeem helpt je de melding naast het veld te plaatsen, op het juiste moment te tonen (tijdens het invullen of bij het versturen) en op te maken passend bij je formulierontwerp.
Validatie in realtime is ingebouwd, zodat foutmeldingen kunnen verschijnen terwijl gebruikers typen, niet pas na het versturen. Zo worden fouten vroeg opgevangen en voorkom je de frustratie van een heel formulier invullen om pas aan het eind problemen te ontdekken.
Bekijk welke formulierfuncties in je WEMASY-abonnement zitten.