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 at​tempt 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 — yelling at you although you’re not done writing your email

Google Forms has the following workflow:

Focusing the field will not mark it as dirty

mark it as dirty Validation is performed during the data entry

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

Facebook Registration Form

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

mark it as dirty Validation is performed after the data entry

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

the data entry Phone or email field is validated during the data entry

the data entry Password field is validated during the data entry

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

Yellow? Really?

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

mark it as dirty Validation is performed after the data entry

the data entry Errors are shown on field focus

JotForm

JotForm is a form builder product.

JotForm

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

mark it as dirty Validation is performed after the data entry

the data entry Errors are shown on field blur

Errors are hidden on field focus

FormStack

FormStack is a form builder product.

FormStack

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: