Here is a very sounding post about how to create better validation messages. I agree with Jamie: there are error messages that absolutely suck, and we should do better if we want to retain users.
Form validation errors are inevitable. Yes, they can (and should) be minimized, but validation errors won’t ever be eliminated – they are a natural part of complex forms and user’s data input. The key question then is how to make it easy for the user to recover from form errors.
I read the entire post and liked it very much. However, I wanted to add a couple of caveats:
1. Return of Investment
Before jumping and start creating variations for our error messages, we need to understand what's the ROI for each one of the problems with are trying to solve.
For any given field, we can easily find a million ways to input the information that goes in it in the wrong way. Does it make sense to create a specific message for each incorrect variant? Of course not. We need to identify which are the most common ones and only implement those.
But even before, we need to think about what Jamie said and I quoted above: error messages should be minimized, which leads me to the next point:
2. Do, don't tell
Should we spend our time working on specific validation messages, or should we rather spend it working on avoiding error messages on the first place?
I'd like to think that if we are good enough to detect that something specific is wrong, we are probably good enough to fix it for the user.
So instead of detecting specific problems to display errors to the user, we can spend the time trying to recover from these problems without having to display the messages at all.
Let's take the US phone number example from Jamie's post. Here are some possible erroneous inputs (think that only a 10 digit number is a valid input. For example:
434-343-3423: User entered dashes. Instead of displaying an error, we can remove them and save the number as
434 343 3423: User entered spaces. Instead of displaying an error, we can remove them and save the number as
+14343433423: User entered a country code (
+1). Instead of displaying an error, we can remove it and save the number as
434343342: Here the user is missing a digit. In this case we don't have any other choice than to display a specific error message.
As you can see, from 3 out of 4 possible errors we can easily recover. In these cases, we don't need to display the adaptive error message and we'll be providing a better experience overall.
Always think before doing
Like with anything else, there's no right or wrong way of doing things. Every application faces different constraints, and your ability to tackle the right problems in your specific context is what's going to make you a great engineer (or a crappy one).
Following Jamie's advise will add a nice touch to your application, something that you'll be able to measure in real dollars based on retention rates and fewer frustrated users.
But it comes at a price, and it's up to you to decide whether is worth it.