Inline validation in forms — designing the experience

Published in

WDstack

9 min readJun 7, 2016

After having released my own form validations library, I couldn’t stop asking myself one thing: What is the best user experience when it comes to displaying the inline validation errors? I know that the library itself can handle anything, but I wanted to find out what the best default experience was, something I could provide out-of-the-box.

While researching this topic, I chanced upon various articles and discussions, but I would like to recommend the following:

Inline Validation in Web Forms article has the following quotes:

When we used the “after” method in the first half of the form, participants completed the form seven to ten seconds faster than when we used the “while” and “before and while” methods respectively. The “before and while” method not only caused longer completion times, but also produced higher error rates and worse satisfaction ratings than the other inline validation variations we tested

and:

When compared to our control version, the inline validation form with the best performance showed compelling improvements across all the data we measured. Specifically, we saw:
a 22% increase in success rates,
a 22% decrease in errors made,
a 31% increase in satisfaction rating,
a 42% decrease in completion times, and
a 47% decrease in the number of eye fixations.

Inline validation UX matters a lot. This article is from 2009 and Aral Balkan’s Do you suffer from premature validation? is from 2008, so this is not new information.

Digging Deeper

After going through these articles, I’ve decided to do research on the current state of the validation UX in the wild. My hypothesis was that analyzing numerous sites would give me new ideas on how to approach this problem or that it would at least confirm the information from the cited article.

Unfortunately, the results were not what I was hoping for. Most of the sites that were analyzed have UX problems and bugs related to validation. In the next part of the article, I’ll attempt to present my findings and conclusions.

The goals I have set for this article are:

Determine and write down the best default experience for the inline validation
Share it with you, so you don’t have to go through the same process
Gather feedback and improve my approach

So, if you have any kind of feedback, please leave a comment, I’d really like to solve this problem.

Which sites to analyze?

The sites that were analyzed fall in one of the following groups:

Hosted form products (like Google Forms)
Big brand sites (like Facebook, Twitter, Apple Store…)

The reason why I picked hosted form products is because I expected them to have the best UX, after all that’s how they make their money.

On the other hand, I also wanted to include big brand sites seeing that their form is usually the last step you have to take before you become their customer, which is why I expected that the end of their funnel would be polished and easy to use.

The analysis will be focused on the following:

When is the validation happening (during or after)
When is the field marked as dirty (on field focus, on value change or after leaving the field) — or what interaction is required for the field to be validated
When are the errors hidden or shown

Let’s start with some heavy hitters…

Google Forms

Google Forms has the following workflow:

Focusing the field will not mark it as dirty
Validation is performed during the data entry
Errors are always shown

Google Forms has a pretty good UX overall, but they are still validating the field during the data entry which goes against the advice in the Inline Validation in Web Forms article.

Facebook

We can already see that even the biggest brands don’t agree on how and when to perform the validation. Facebook’s workflow:

Focusing the field will mark it as dirty
Validation is performed after the data entry
Errors are shown on field focus

But, there’s more. You see those two email fields (email and email confirmation)? Facebook’s validation is broken for them:

It seems that the validation is performed on the field level, so the email confirmation field is not picking up when the email field matches the value.

Twitter

Twitter’s form has some unique rules in place:

Full Name field is validated after the data entry
Phone or email field is validated during the data entry
Password field is validated during the data entry
Password field is showing a different error when the field is not focused (“Your password must be at least 6 characters.” vs “Please enter a password”).

The weirdest thing about the Twitter registration form is that it removes the errors if you focus into an empty field that’s in an invalid state. I wonder if this is a feature or a bug.

Apple Store

One thing I noticed about the Apple Store is that they use the yellow color for the error state. The first time I encountered this peculiarity I thought these were the fields that could be auto-completed by my browser. Other than that, here’s the workflow they use:

Focusing the field will not mark it as dirty
Validation is performed after the data entry
Errors are shown on field focus

JotForm

JotForm is a form builder product.

JotForm made an interesting decision. They show the errors while the field is not focused and hide them on focus. I’m not sure what to think about it, but it feels like it could lead to confusion (if the error disappears, does it mean that the field has a valid value?).

There is also an issue where the error is shortly flashed after the field enters the valid state.

JotForm’s workflow:

Focusing the field will mark it as dirty
Validation is performed after the data entry
Errors are shown on field blur
Errors are hidden on field focus

FormStack

FormStack is a form builder product.

FormStack has some consistency issues. Notice how the email field is live validated by default, but the name field is live validated only after the submit was attempted. Disregarding this, the workflow is as following:

Focusing the field will not mark it as dirty
Validation is performed after the data entry
Errors are always shown

Designing the default UX

At the end of this research, my conclusion is the following:

Nobody knows what they’re doing, humanity is doomed and our only hope is the colonization of Mars.

Ok, it’s not that bad. But, we still have some serious problems:

There is no consensus on the default validation handling
Differences between the sites are huge, we can’t expect users to be familiar with any of the presented approaches
A lot of solutions are bug ridden, which is a good indicator of how hard it is to implement a good inline validation

Let’s recap the questions stated before the research:

When should the field be marked as dirty?
When should the errors be shown?
When should the field be validated?

If we can find the right answers to these questions, we can assure that the validation UX will be at least good. Validation UX is determined by the timeliness of the reaction, so let’s define the correct timing for each of those cases.

When should the field be marked as dirty?

In the research, you could see both approaches:

mark field as dirty as soon as the user focuses the field
mark field as dirty after the user entered some data in it

Facebook and JotForm mark the field as dirty immediately after you focus them. In my opinion that feels janky and aggressive. It felt much better when the field was marked as dirty after I had interacted with it. And I’m not counting focusing of the field as an interaction.

Also, when the user clicks the “Submit” button, all fields in the form should be considered dirty, and should be immediately validated.

When should the errors be shown?

This is another question where the research hasn’t given any clear answers. We’ve seen all of the possible combinations:

errors that are always shown
errors that are only shown when the user is interacting with the field
errors that are not shown only when the user is interacting with the field

None of these feel like the best answer, but my vote goes to the errors that are always shown. They do add some visual noise, and might feel redundant, but at least we can avoid the confusion where errors are disappearing on (seemingly) random occasions.

When should the field be validated?

To reiterate, we can validate the field either during the data entry or after the data entry.

In my opinion both of these approaches have timing issues.

Forms that perform the validation during the data entry punish the users as soon as they start entering the data. It is most apparent with the email fields. On the other hand, forms that perform validation after the data entry are not informing the user that they fixed the error soon enough.

For the default behavior I propose a hybrid — reward early, punish late — approach:

If the user is entering the data in the field that was in a valid state, perform the validation after the data entry
If the user is entering the data in the field that was in an invalid state, perform the validation during the data entry

Combining these two approaches feels like a pretty good compromise. Remember, we are looking for the best default behavior possible, different forms will have different needs, so make sure to adjust the approach as needed.

Notice how this implementation is not suffering from the email confirmation bug present in the Facebook registration form.

The implementation

If you are using ClojureScript, you should try out the Keechma Forms library because it definitely has you covered. That’s what I used to build the example (check out the code).

I don’t know of any other validation libraries that support this kind of customization (if you do, please send me the link to include it here), so I’ll just write down how to implement it:

The validation library must keep track of the dirty fields.
If the field was in a valid state, perform the validation on the blur event
If the field was in an invalid state, perform the validation when the field value is changed (using the combination of onchange, onblur and onkeypress events)
When the field goes from the invalid to valid state, treat it like a valid field

You should also make sure that the validation functions can check the current data of the whole form. For instance, email confirmation validation should be able to check what’s the current value of both the email and email confirmation fields. This way you can avoid bugs like in the Facebook registration form.

In my opinion (and implementation) the validation should not be defined on the input components. Validations should be always performed on the data, never on the fields itself.

Conclusion

I thought that the live validation is a solved problem, but after doing this analysis, it seems that every team has a different approach. I’m also pretty sure that most of these sites (they are some of the biggest sites in the world, after all) are doing extensive A/B testing on their forms, which left me pretty confused about the best approach.

In the end I’m pretty satisfied with the defaults, and I hope you found this article useful. Please let me know if you have any feedback, I’m very interested in your thoughts about this topic.