The problem with live validation and what to do instead

In 2009 I was given some new designs to implement for the forms on

One requirement was to validate as the user answers each question.

But it wasn’t clear whether it was best to validate as the user types or as they leave the field.

In the end we went with the latter because otherwise, users would be shown errors before having a chance to answer the question.

Having been asked to implement live validation several times, I’ve collected 9 usability issues which I wanted to share with you today.

And I’ll also share 4 better ways of reducing error rates in forms without any complicated patterns.

1. It can interrupt users before they have a chance to type their answer completely

For fields that must be a certain number of characters, the first keystroke will constitute an error which interrupts users.

As soon as the user types, an error will be displayed before the user has answered the question

2. It can distract users while they’re trying to answer the question

Showing an error as the user tabs to the next field can cause users to be distracted by errors in the previous field.

When the user goes to fix the error, it’ll trigger an error in the field below.

Blurring the field causes errors to show prematurely

Similarly, when a user opens their password manager, the blur event will fire causing an error to be shown prematurely.

3. It can cause the page to judder

As the input becomes invalid and valid, an error will appear and disappear state changes between valid and invalid, errors will appear and disappear respectively quickly.

This causes the page to jump which can be disorientating and cause users to make mistakes.

The page judders as the field switches between invalid and valid

4. It can’t be used with multi-input fields

Fields that are made up of multiple inputs need to be validated as a whole.

For example, take a checkbox group that needs at least 1 to be checked. It would be premature to show an error when the user tabs over the first checkbox to focus on the second checkbox.

It would also be presumptious to validate after the user tabs past the last checkbox as they could be just exploring the options or tabbing back to a previous option.

The same issues apply to a date field consisting of day, month and year inputs.

An interface that relies on users doing things in a specific order is prone to error and takes control away unnecessarily.

We could validate these types of fields on submit, but this would be inconsistent with the way the other fields work.

A checkbox group (left) and date field (right) can’t be validated as the user tabs between inputs

5. It can mislead users into thinking that their answer is valid when it isn’t

For example, account credentials can only be validated by the server. So if a user enters an email address in the correct format, an account may not exist for that email address.

Luke Wroblewski’s research had similar findings:

Participants knew we had no way to know their correct name, so they knew that the green check mark didn’t mean “correct.” But they weren’t sure and that was the problem.

6. Different fields need to be validated at different times

Some inputs can be validated as soon as the user types like typing a letter when only numbers are expected.

For other inputs, that would be too early so you would have to validate them after the user is finished which causes inconsistency.

7. It’s tiresome to constantly switch between answering questions and fixing mistakes

As errors are shown as users are answering, the user has to switch between 2 modes of operation repeatedly which is draining.

8. It can create multiple screen reader announcements in quick succession

Some screen reader users tab through the whole form to get a feel for what’s involved. But this would announce errors for each and every question which is tedious.

9. Users may not notice the errors as they appear

As many users don’t look at the screen as they type, users may not even notice the errors appearing.

4 ways to stop users seeing errors without any downsides

Instead of resorting to a complex validation pattern that causes more problems than it solves, instead you can:

  1. Make sure your questions are easy to understand so that users are more likely to not make mistakes
  2. Start with one thing per page to reduce cognitive load
  3. Allow users to make little mistakes like extra whitespace
  4. Validate when the user submits to give users a chance to answer the question and proceed when they’re ready

I’ve seen these approaches work time and time again in user research.