We kennen het allemaal. Je hebt een leuke dienst, informatiebron of product gevonden. Je doet je best om een online formulier in te vullen. Beantwoordt netjes alle vragen op het best van je kunnen… ok. Dan opeens, na het klikken op de ´volgende´ of ´verzend´ knop, zie je dezelfde pagina weer verschijnen. Dat je niet alles in één keer goed invult… dat kan wel eens voorkomen, maar wees eens eerlijk, word je niet soms laaiend boos over foutmeldingen?
In dit artikel, bestaande uit 2 delen, wil ik graag dit fenomeen gaan toelichten. Nee, ik ben niet de uitvinder van het wiel. Ben zeker niet de eerste die hierover heeft geschreven. Martin van Kranenburg deed dit al in 2006 op Marketingfacts in zijn artikel ´Hoe optimaal zijn de webformulieren op jouw site?´. In mijn vorige artikel ging ik dieper in op zijn eerste punt: ´worden er relevante vragen gesteld´. Vandaag wil ik wat dieper in gaan op zijn vierde punt: ´foutmeldingen´.
Tijd voor wat voorbeelden
Laten we beginnen met een paar voorbeelden. Ik moet wel zeggen dat ik overdreven situaties heb opgezet om de foutmeldingen ´uit te lokken´. Hierdoor kan het misschien extreem overkomen. Maar houd rekening met het feit dat het kan gebeuren. Een bezoeker kan immers te snel op de ´volgende/verzend´ knop drukken waardoor een overweldigende hoeveelheid foutmeldingen tegelijkertijd getoond kunnen worden.
voorbeeld 1: Jiba.nl
[klik voor volledige voorbeeld]
Dit plaatje is niet groter gemaakt. Het uitroepteken is letterlijk zo groot! Het verschijnt bovenaan aan het formulier nadat er fouten zijn geconstateerd. De invoervelden worden ook rood gekleurd.
voorbeeld 2: Unive.nl
[klik voor volledige voorbeeld]
Vanwege de breedte van dit blog heb ik dit plaatje wel iets kleiner gemaakt. De uitroeptekens zijn duidelijk zichtbaar, maar naast deze foutindicaties zijn de labels naast de invoervelden ook rood gemaakt. Een gebruiker zou hier last van kunnen hebben omdat zijn ogen in principe twee richtingen op proberen te kijken om beide meldingen te zien (saccades). Uitleg over de foutmeldingen worden pas onderaan het formulier verder toegelicht.
voorbeeld 3: Hetnet.nl
[klik voor volledige voorbeeld]
Bij Hetnet.nl verschijnen alle foutmeldingen bovenaan de formulier. Hierdoor komt het wel onder de aandacht van de bezoeker, maar het kost de bezoeker extra moeite om elke foutmelding te koppelen aan het bijbehorende veld, zeker als de namen van de labels anders zijn dan de namen in de tekst van de foutmelding. De rest van het formulier (invoervelden en labels) blijft ook ongewijzigd.
voorbeeld 4: Vodafone.nl
[klik voor volledige voorbeeld]
Bij Vodafone wordt een andere aanpak gebruikt. Hier plaatsen ze bij elk veld wat niet goed gevalideerd is een uitroepteken in een gele driehoek en passen ze de kleur aan van het veld in kwestie. Op zich een redelijk goede aanpak was het niet dat nu de bezoeker zelf deze fouten moet gaan opsporen. Er is geen collectieve lijst van fouten boven aan het formulier.
voorbeeld 5: Albert.nl
[klik voor volledige voorbeeld]
Je zou denken dat het bovenstaande plaatje het totaalbeeld zou geven van hoe het aanmeldformulier van albert.nl omgaat met foutmeldingen. Niets is helaas minder waar. Op het volledige voorbeeld is te zien hoe agressief er om wordt gegaan met de foutmeldingen en dat er geen rekening is gehouden wanneer een bezoeker meerdere velden niet of verkeerd invult.
Natuurlijk zijn er nog vele andere voorbeelden, maar ik wilde het even bij deze houden, zodat jullie een goed beeld hebben van wat er gebeurt bij het tonen van een foutmelding.
Vergeet ze niet: Relatie, Conversatie en Weergave
Zoals het woord ´foutmelding´ zelf al aangeeft, hebben we te maken met een melding van de site van ´Het Bedrijf´, dat er iets niet goed is gegaan bij het invullen van het formulier. Deze melding moet getoond worden aan de bezoeker die bezig is met het invullen hiervan. Alle drie aspecten van formulieren (relatie, conversatie en weergave) komen hier samen. Ten eerste de relatie tussen Het Bedrijf en de bezoeker. Blijkbaar heeft Het Bedrijf genoeg vertrouwen gewonnen van de bezoeker om deze te overtuigen het formulier in te vullen. Na de relatie stap, komt de conversatie stap.
Tijdens de conversatie kan het wel eens misgaan. Denk aan een situatie waarbij je in gesprek bent met een verkoper van bijvoorbeeld een mobiele telefonie winkel (niet online) waar je een abonnement wilt afsluiten. De verkoper gaat zijn best doen om een formulier voor je in te vullen. Tijdens dit proces zullen er vragen aan je gesteld worden die jij dient te beantwoorden wil je de verkoop afronden. Bij vragen die voor jou niet duidelijk zijn kan je de verkoper gerust om toelichting vragen. Andersom ook, als de verkoper jou antwoord niet verstaat of begrijpt kan dit aangegeven worden op een communicatieve (en hopelijk ook vriendelijke) manier. Online moet dit toch anders. Daar zit geen verkoper die voor jou de gegevens invult. Je zult het zelf moeten doen. Als bedrijf moet je er dus voor opletten dat je de plank niet mis slaat.
Als laatst is er de weergave van een formulier. Wat we te vaak tegenkomen, zie bovenstaande voorbeelden of denk aan voorbeelden uit eigen ervaringen, is dat formulieren zeer onzorgvuldig met foutmeldingen omgaan. Grote uitroeptekens, ingewikkelde foutmeldingen, FOUT FOUT FOUT. Ik moet dan vaak denken, zoals het plaatje ook laat zien, aan een man die tegen mij staat te schreeuwen en mijn zelfvertrouwen in het invullen van het formulier hard onderuit haalt. Vaak slaat dit gevoel van onzekerheid en schuld om in frustratie. Schuldgevoel weerhoud ons er namelijk van om verder te gaan, en waar of niet, we willen graag ons doel bereiken (aankoop, nieuwsbrief etc.). Wat bedrijven vaak vergeten, is dat de klant altijd in controle is en dat de opgewekte frustratie een reden kan zijn om het formulier of website te verlaten.
Tastbaarheid of Emoties
Ook al heb je een formulier samengesteld dat aan alle eisen voldoet van je zakenplan en is er met alle ijl gebruik gemaakt van technische hoogstandjes dan valt je lot nog steeds in de handen van de bezoeker. De bezoeker is altijd de drijfveer van je website en als je de bezoekers niet centraal stelt zullen de resultaten tegenvallen.
Keer op keer zien we dat enkel het tastbare/materiële doel van een gebruiker als doel wordt beschouwd en er geen aandacht uit gaat naar de emotionele behoeften. Met emotionele behoeften bedoel ik natuurlijk de manier waarop je omgaat met je bezoekers online. Rekening houden met emoties levert immers geen geld op, althans, dit wordt vaak als excuus gebruikt. Naar mijn mening is dit ´hidden gem´.
Lees in deel 2 van dit artikel tips en methodes om een positieve draai te geven aan foutmeldingen.
Thomas Cook
Gepassioneerd en enthousiast over alles wat met website te maken heeft. Online marketing, analytics, customer experience en nog veel meer. Het blijft de ultieme uitdaging om voor elke site de perfect combinatie te vinden om er zo maximaal...
Lees verder »Nieuwsbrief
Voortdurend op de hoogte van het laatste analytics en optimalisaties nieuws met onze nieuwsbrief!
Gebruik je al Mint?
Deze Web Analytics software wordt in Nederland onder andere gebruikt door 925.nl, geldenrecht.nl en 123.nl
Lees meer over MintAangeboden door AboutAnalyticsNieuwste reacties
- the pilatesbiz: Hi there! Quick question thats entirely off topic. Do you know how to make your site mobile friendly? My web site looks...
- Leendert: Als ik het nu zo kijk heeft independer dit met de lening site wel aangepast. Ik vind dit een interessante materie. Al...
- Jan de Vries: Dank Michel voor je tip!
- Michel Kompanje: Leuke site om in de gaten te houden is http://visual.ly/. Binnenkort kun je hier op een gemakkelijker manier je eigen...
10 reacties
En hoe denken jullie over het gebruik van Tooltips? Zelf hanteren wij die meestal, bij een ToolTip wordt er dus op het moment dat je op een invoerveld klikt een popup weergegeven waarin we uitleggen HOE we het ingevuld zouden willen zien.
Op die manier voorkom je in onze ogen veel voorkomende foutmeldingen?
Hoi Gerben, In het algemeen vind ik foutmeldingen een oplossing voor client-side validation. Een betere oplossing zou zijn server-side validation, binnenkort verschijnt hier een artikel over. Maar even terugkomend op Tooltips…. wat je je af moet vragen over tooltips is wat de klant hiervan vindt. Help/Tooltips zijn een geval apart. Moet je dit automatisch tonen (automatic inline help) of moet de gebruiker dit zelf aanroepen (user activated inline help). Veel hangt af, denk ik persoonlijk, van de manier waarop je de help teksten toont. Pop-up, dynamisch ergens in een sidebar naast de formulier, in een box rechts of onder van de invoerveld. Vergeet niet, de klant is je beste bron van informatie. Ik kan veel suggesties maken, maar jullie doelgroep en persoonlijke wensen zullen moeten bepalen wat de beste oplossing zal zijn. Wees in ieder geval consistent met je oplossing over de hele site!
@Matthew: interessant artikel, zoals je zelf al aangeeft is er veel over geschreven, maar de emotie is soms een ondergeschoven kindje.
Een paar aanvullingen: Jiba.nl legt de schuld bij de gebruiker “U bent vergeten…”. Niet echt gebruiksvriendelijk.
De foutmeldingen van Univé zijn om meerdere redenen niet erg helder: het is gangbaar om foutmeldingen bovenaan formulieren te zetten, en de uitroep-iconen tonen gelijkenis met informatie-iconen. Tot slot is er een deel van je groep gebruikers die kleurenblind zijn en mogelijk de roodgedrukte tekst niet eens zien (dit lijkt triviaal, maar kleurenblindheid, en dan met name voor rood komt nog best veel voor). Beter om bv óók een vette lijn om de velden te zetten die niet of onjuist zijn ingevuld.
De aanpak van Vodafone kun je over discussiëren: een lange opsomming bovenaan voegt m.i. niet zoveel toe aangezien je tóch de bijbehorende velden moet opzoeken om je invoer aan te passen. Wellicht zou een combinatie handig zijn: bovenaan melden en bij het betreffende veld.
@Gerben: een tooltip heeft zeker nut, mits je hem goed gebruikt. Als je gebruikers niet op voorhand wilt afschrikken met veel informatie en deze tóch wilt bieden wanneer dit voor hen relevant is kan het een mooie oplossing zijn (progressive disclosure).
Overigens “waarin we uitleggen HOE we het ingevuld zouden willen zien”: het is gebruiksvriendelijker om de gebruiker de vrijheid te geven (!). Bv het afdwingen van telefoonnummers die per se gescheiden moeten zijn met een streepje én geen spaties mogen bevatten is vragen om foutmeldingen. Beter om dit mbv de techniek om te zetten naar de juiste informatie voor in de database.
Wij geven eerst alleen de ‘u hebt niet alles ingevuld’ melding weer, daarna geven we alle andere foutmelding weer. Daarbij omlijnen we altijd het veld die nog niet (goed) is ingevuld.
Een server-side voorbeeld kun je vinden op: http://countus.nl/werken/mijn_cv.
Een client-side (het is AJAX, dus niet helemaal client-side) voorbeeld kun je vinden op: http://motivo.nl/Ons_benaderen.
Ik vraag me altijd af waarom niet meer formulieren online validation gebruiken. Elke keer als je een invulveld verlaat wordt via javascript gecheckt of alles goed is ingevuld. Door hier positieve teksten neer te zetten (ipv foutmeldingen) kun je mensen het veld meteen goed laten invullen.
OP het moment dat iemand zijn telefoonnummer invult dan is zijn aandacht gericht op dat veld. Dat is ook het moment waarop er een melding moet komen of het telefoonnummer klopt zodat het meteen aangepast kan worden. Enkele voorbeelden staan op http://www.wwohn.nl/real-time-live-validatie/
Een andere zeer grote en onnodige frustratie die aandacht verdient is het onthouden van de inhoud van velden. Ik kom nog steeds formulieren tegen die als ze een foutmelding geven het hele formulier leeg opleveren zodat je opnieuw moet beginnen. Soms worden alleen bepaalde velden gedelete zoals het opgegeven password. Dan krijg je bijvoorbeeld een foutmelding dat je postcode niet klopt waarna je deze opnieuw invult. ALs je dan weer op submit drukt krijg je de foutmelding dat je je gewenste password niet hebt ingevuld. Deze moet je namelijk elke keer dat je een foutmelding krijgt opnieuw invullen.
Erik, je hebt inderdaad gelijk. Toevallig heb ik dinsdag hier een artikel over afgerond die na het weekend op deze site zal verschijnen. Ik gebruik o.a. ook het voorbeeld van Twitter. Ik heb het dan niet alleen over validatie via javascript (getriggerd door een event) maar ook asynchroon validatie via AJAX.
vwb telefoonnummer, tja, dit zou je natuurlijk ook goed ingevuld willen hebben, maar mensen geven vaak aan telefoonnummers een eigen draai. Met streepjes, zonder streepjes maar met “.” tekens of met spaties. Ik denk dat je moet oppassen dat je niet te streng valideert. Wees coulant. Je kan als webbouwer immers makkelijk de invoer formatteren naar je eigen wens in een later stadium. Voor telefoonnummer, geef een voorbeeld van hoe het moet (bv. 010 2345678) en dan controleer bijvoorbeeld op de aanwezigheid van precies 10 cijfers waarbij de eerste cijfer een 0 is. Indien de mensen +31612345678 of 0031612345678 gebruiken, dan kan je dit later wijzigen naar 0612345678 met een script.
Een voorbeeld van te streng valideren is te vinden bij het internet bankieren applicatie van de Rabobank. Als je daar geld over wilt maken naar een girorekening, bijvoorbeeld rekeningnummer 1111, dan verschijnt er een alert met ‘Giro rekeningnummers moeten vooraf gegaan worden met de letter P’. Mijn reactie is ‘als je al weten dat het hier om een Giro rekening gaat, pas de invoer dan zelf aan.
Het blijft een balans tussen de invoer die je verwacht van je doelgroep en de zakelijke doelstellingen die neergelegd zijn bij het maken van de formulier. Elk formulier moet uniek behandeld worden.
Dat van de rabobank is inderdaad een mooi voorbeeld. Hetzelfde zie je bijvoorbeeld ook op sites waar je een URL in kan vullen. Soms staat er expliciet dat je wel of geen http:// moet gebruiken. Je krijgt dan een foutmelding als je het niet goed doet. Dit kun je heel makkelijk in een script oplossen zodat het altijd werkt.
Andere voorbeelden die in ieder geval mij mateloos irriteren zijn bijvoorbeeld:
-wel of geen spatie in de postcode
-alle combinaties met een telefoonnummer
-wel of geen hoofdletter gebruiken
-de url met of zonder http://
HIer is echt nog heel veel winst te maken. En toch wordt het niet opgelost. Er is al zoveel geschreven over usability bij die formulieren maar er lijkt maar weinig te veranderen.
Pas was ik op een site waarin ik verplicht een aanhef moest geven (mevr, dhr, drs, etc). vervolgens moest ik apart nog invullen of ik een man of vrouw was, etc. En dat voor een gewone eenmalige bestelling in een webshop (helaas de url vergeten).
De toppers zijn natuurlijk de websites die een opmerking of klachtenformulier opnemen waar je verplicht je adres, telnr, email, geslacht, geboortedatum enz moet invullen.
Dan zit ik weer uitgebreid xx en 00 in te vullen waarna de eerste klacht die ik opneem in het klachten of opmerkingen formulier meteen het formulier zelf betreft.
@Gerben, ik denk dat tooltips inderdaad bijdrage aan een hogere conversie van het formulier (hangt natuurlijk wel af van de tekst, maar ik ga er even vanuit dat er geen onzin in staat
) Door middel van tooltips kan je de aandacht van de klant direct richten op een stukje tekst dat hem/haar kan helpen bij de actie die hij/zij aan het uitvoeren is.
@Erik, goede punten! Helaas maak ik vaak mee dat niet alle validaties realtime, client-side, uitgevoerd kunnen worden omdat er een koppeling met de backend gedaan moet worden om de informatie te verifiëren. Wat doe je dan? Het is ook voor de beleving van de klant heel vreemd wanneer je een gedeelte client-side doet en een gedeelte na een POST command (klik op ‘volgende’). Reacties als ‘maar alles was toch al gecontroleerd?’ en ‘waarom komen ze daar nú pas mee’, zijn op dat moment niet vreemd.
@Matthew, scherp dat Rabobank voorbeeld
het is inderdaad niet nodig (weet ik uit ervaring 
)
Er waren wat reacties (van Erik en Lennard) blijven hang in ons spamfilter, excuses daarvoor, ze zijn ‘goedgekeurd’!
@Reinout,
Met ajax kan je al best veel doen. Al die tools die je username verifieren die maken ook een koppeling met de backend.
En met een goede client side validatie plus evt een backend connectie voor usernames e.d. kun je al een groot deel van de validatie fouten uitsluiten. Wie weet hoeveel mensen er uit je conversie vallen door irritatie over die validatie dingen. Het lijkt me dat die paar mensen die onverhoopt na het submitten toch nog tegen een server side validatie fout aanlopen minimaal zijn. Kwestie van afwegen waar je de meeste mensen kwijtraakt.