Why input validation could cost you a lot

Input validations could upset your users — especially when they are done wrong. Try to avoid them where possible.

Thierry Rietsch
3 min readSep 7, 2013

I just tried to order a gadget over some site but the input validation on the order form drove me crazy. Why do you make it hard for me to spend money?

Take a look at the screenshot above. This is the actual result after entering some data. The data above could represent a valid address of a Swiss citizien — but she would not be able to order it. The problem in the order form above are the special characters / umlaute (é, ü, …) within the name and street field. Furthermore there are no spaces allowed in the phone number.

It is a good example to see that input validation is heavy to achieve. And if it is not done sufficient enough, it annoys users.

There are so many input validations done nowadays — but for what? I agree that one should check that a name is present, but that’s it. I am ordering something, so it is anyway in my interest to enter a valid address. Especially as I am going to pay for this, so why should I even enter some wrong data? Furthermore you only check if the data is entered in a valid way but you still have no indicator if I entered semantically the right data (did I gave you a valid phone number or is it just a random one with a valid format?).

The problem behind wrong approached input validation can often be found in the lack of knowledge about other countries / cultures. The zip code is really great example where many pitfalls can happen. In Switzerland we do have zip codes from 1000 — 9999. So why not take an integer and validate, that the zip code is in the range above. Well suddenly someone comes up that Germany uses five digit zip codes (10000 — 99999). So far no problem, so we just extend the validation rule to check from 1000 up to 99999. Hey, but what about the UK? They do have zip codes like ‘WC1B’ and so on. Well, now we do have a serious problem. As you can see we can play this game until we have gone through all countries of the world. And exactly that localized information is required before you can build a working input validation rule. If you are not aware of that — better don’t try to validate.

Always try to avoid input validation wherever it is possible and not required. Of course there are situations where it helps the user to prevent errors (e.g. when entering a month, it wouldn’t make sense most of the time to enter a negative value). But only at those points, where you can ensure that your validation is working 100%. You do still have the possibility to process the data in the background and bring it to a format which is sufficient for your requirements — but just without bothering the user about that. Otherwise you are putting yourself to the risk that users cancel their intention and for example in case of an ordering process, will not order anything.

--

--