Vaak optimaliseren we de plekken waar veel verkeer komt. Logisch, verkeer is een belangrijk onderdeel van optimalisatie. Het is de benzine waar je optimalisatiemotor op loopt. Op die plekken met veel verkeer heb je eerder resultaat dan wanneer je een plek optimaliseert waar veel minder verkeer komt. Je komt benzine tekort.
Toen ik bij SNS werkte had ik een collega die mij het belang van het invoeren van data leerde. Hij vond (en vindt nog steeds denk ik) dat gebruikers op alle (voor hen) mogelijke manieren data moeten kunnen invoeren en dat de techniek hen daarbij niet moet afstraffen, maar juist moet helpen, intelligent moet zijn, moet begrijpen wat iemand bedoelt, ook al hanteert hij/zij een andere schrijfwijze dan vanuit de back-end systemen van de bank ‘gewenst’ is.
Doe deze simpele validatietest
Om gelijk duidelijk te maken wat ik bedoel; open eens een formulier van jezelf en vul eens je telefoonnummer in. Gebruik de volgende schrijfwijzen en kijk of je formulier het accepteert. Kan je nog meer varianten bedenken? Test die dan ook!
- 06-12345678
- 0612345678
- 0031612345678
- +316 12345678
- 06 12345678
- (06) 12345678
- 06 123 456 78
Lukt het jou om bovenstaande nummers te bellen? Accepteert je formulier alle bovenstaande nummers? Als op beide vragen het antwoord ‘Ja’ is: super! (en ga door naar je ‘Postcode’ veld :)). Ik verwacht dat in veel gevallen het antwoord op vraag één ‘Ja’ is en op vraag twee ‘Nee’ is. In dat geval heb je nog werk te doen.
Voorbeelden uit de praktijk
Hieronder twee voorbeelden van formulieren die gebruikt worden op rabobank.nl, waarbij beide velden er hetzelfde uitzien, maar anders reageren / valideren. Het eerste veld doet het naar verwachting, het accepteert alle 7 voorbeelden (alleen geen buitenlandse nummers). Het tweede veld doet het niet naar verwachting, het accepteert 2 van de 7 voorbeelden (maar voor die voorbeelden dan ook wel weer buitenlandse nummers):
Telefoonnummer veld één, we vullen het telefoonnummer in:
Telefoonnummer veld één, het wordt geaccepteerd, prachtig!
Telefoonnummer veld twee, we vullen hetzelfde telefoonnummer in:
Telefoonnummer veld twee, het wordt niet geaccepteerd!
In dit geval willen we het beste van beide velden: de intelligentie van veld één mét de acceptatie van buitenlandse nummers.
Wat je zelf begrijpt, moet de techniek ook begrijpen
Het is vreemd dat ‘data’ die je zelf wel begrijpt, niet geaccepteerd wordt door de formulieren waar je klanten / gebruikers mee moeten werken. Je kunt deze tip wegwuiven onder het mom van ‘mijn klant is slim genoeg’ of ‘ach, dan passen ze toch even hun nummer aan, zo lastig is het toch niet?’, maar bedenk je dan wel hoe je klant zal reageren; geïrriteerd.
Inline validatie is geen oplossing
Steeds vaker wordt inline validatie gebruikt binnen formulieren. Inline validatie wil zeggen: ik vertel je direct of ik je invoer accepteer. Het voordeel van inline validatie is dat gebruikers direct hun invoer kunnen aanpassen als dat nodig is. Deze directe terugkoppeling wordt wel eens gezien als oplossing van slechte validatie: we vertellen de bezoeker toch immers dat de invoer niet goed is? Het punt is hier dat inline validatie op slechte validatieregels hele slechte inline validatie is. Het doet me denken aan ‘Little Britain’s’: ‘Computer says nooo’. Je voert je telefoonnummer in en je krijgt gelijk te horen ‘Computer says noohoo’, je past je telefoonnummer aan en hoort gelijk weer ‘Computer says noohoo’. Het formulier (het bedrijf) doet nul komma nul moeite om je te helpen. ‘Wil ik hier klant zijn?’: en weg ben je.
De tip is:
Bedenk voor ieder veld in je formulier verschillende mogelijke manieren van invoer en kijk of je door de validatie komt. Kom je er niet doorheen? Pas dan je validatieregel aan. Want wil je geïrriteerde klanten? Nee toch?!
