Getting input validation right
How good your validation is correlates with form completion and indicates how helpful you are.
I was going through a vehicle registration a couple of years ago. It was a hot summer Friday and everyone was mentally in the weekend. At some point the person at the desk says that the data cannot be submitted. She was complaining that IT just installed this new system, and she is not sure why but it is not working sometimes. People were becoming more and more inpatient in the queue behind me as time went on. Not sure about what’s wrong she turns the screen to me and shows me the error. It was a blank screen with a generic PHP error. After turning the screen back, she took out a five pound book and started looking through the pages. Then after a while “AHA, so this the problem!”.
The book was a user manual with error codes and web pages where they could occur.
That is how her days looked like. Imagine the hell she had to go through on a regular basis besides having to deal with all those anxious people who thought of her as a roadblock standing between them and the well deserved ice cold beer or ice cream with the kids.
It’s not just about the form
Setting up the forms and UI that explains what the user should put in is just half the battle. You need to make sure you’re getting good data. It might be an email address or a time for an appointment, you want to make sure the email address is in the right format and the time is during business hours.
People make mistakes, that’s just the way things are. It is your job to warn and help them correct it. When showing an error, don’t just state the fact that there is an error, show the user where it is and give instructions. Be helpful.
The two sides of validation
There are two types of validation. One that you can do in real time, on the fly and another one that you can only do if you check things in the background. From a user’s perspective there is no difference.
- Client side validation: This form of validation usually relies on regular expressions. They are the holy grail of validation. You can describe the valid format with a regex and just run it against the data. It can check for the presence and the content of the data.
- Server side validation: This form of validation relies on some kind of communication with a server. It could be triggered on the fly, which then becomes inline validation or done when the user submits the form.
If possible, do most or all of your validation inline. You can check if the email or user name is take on the fly via an asynchronous request. Suggest alternatives, don’t wait for the user to submit the whole thing.
Language
Validation messages should clearly state what happened and give instructions, next steps on how to solve the problem. It is like the conversation before the “big event”. Let’s take two examples.
- During checkout you need to validate the data the user entered. In the offline world, that would be a conversation with a salesperson on the phone, in chat (text) or in person. What would you think if he would be shouting “Wrong email address!”, “Database error!”. Obviously this person is rude you would probably leave the store.
- Signing up for a newsletter. You are standing in front of a clerk who is behind a computer getting your data for a membership card. You make a mistake and forget a digit from your zip code. If she just says the card could not be issued but doesn’t give any helpful information why, how would you know where the problem is?
Avoid technical jargon. Instead of stating that the email address is invalid, also let the user know why.
If it is not in the correct format, show an example, like “you@yours.com” or if it’s a duplicate email say this email is already taken.
TIP: If you want to be really helpful, ask if they would like to reset the password and try logging in? Maybe they are already registered.
Be human and remember the person on the other side is a human too. Because you are not interacting with them face-to-face doesn’t mean it’s OK to shout all the time (that exclamation mark is harmful!) or be unhelpful and provide generic replies.
Consistency
Show the error the same way for each field. Be consistent in the way you communicate. You wouldn’t appreciate if someone would be talking to you with constantly fluctuating tonality. Show the errors and messages in the same place relative to the field it is referring to. When choosing the color go for something that is visible. Usually red, orange is for errors, yellow for warnings, blue for information and green for confirmation of validity or success.
View interactive example
Timing
Show the errors right away. Do as much inline validation as possible. It should happen in real time right after the user has interacted with the input. The best time to correct any error is right on spot.
There are some situations when you have to post the data and validate it against the database. Whenever you do that tell the user that there are errors, and show how to fix them. Scroll to the first occurrence or provide a summary of the errors that need to be fixed.
Preserve user data
Preserve as much user-input as possible. Don’t mess with other people’s things because they won’t appreciate it. There is a problem if the user types something in and then it gets auto-corrected to something totally different he was looking to enter. You might hit the correct answers sometimes, however you don’t know what the user intended to do so it is best to avoid it.
For example if the user enters a date, and that specific date is taken, don’t just move it around to an arbitrary day. Do not let the user select it in the first place.
REGEX
Regular expressions are the backbone of your validation. I won’t be going into details because things are technical with this one, but I wanted to mention it. If you are designing validation functions, it is something you should understand and use. You can get an introduction to it through this primer (not a pretty website, but the information is gold) and use these tools to build your regular expressions:
So let me close this with a comic by xkcd.
Be friendly, and helpful. Don’t let your users hanging and remember that you are talking to real people through a form. Great forms are conversations not monologues.
If you are looking for quick, no-hassle solutions that can be literally implemented in minutes, check out the products we provide at Mobiscroll.