Inline validation in forms — designing the experience

Mihael Konjević
Jun 7, 2016 · 9 min read

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.

  • Share it with you, so you don’t have to go through the same process
  • Gather feedback and improve my approach

Which sites to analyze?

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

  • Big brand sites (like Facebook, Twitter, Apple Store…)
  1. 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
  2. When are the errors hidden or shown

Google Forms

Google Forms — yelling at you although you’re not done writing your email
  • Validation is performed during the data entry
  • Errors are always shown

Facebook

Facebook Registration Form
  • Validation is performed after the data entry
  • Errors are shown on field focus

Twitter

  • 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”).

Apple Store

Yellow? Really?
  • Validation is performed after the data entry
  • Errors are shown on field focus

JotForm

JotForm is a form builder product.

JotForm
  • 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
  • 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:

  • 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
  • When should the errors be shown?
  • When should the field be validated?

When should the field be marked as dirty?

In the research, you could see both approaches:

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

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 only shown when the user is interacting with the field
  • errors that are not shown only when the user is interacting with the field

When should the field be validated?

To reiterate, we can validate the field either during the data entry or 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
Hybrid — reward early, punish late — approach

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).

  • 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

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.

WDstack

Tools, apps & insight on design + development

Thanks to Writisan.

Mihael Konjević

Written by

Web developer from Croatia. Lead developer of the Keechma framework. CTO at VeryBigThings

WDstack

WDstack

Tools, apps & insight on design + development