This content originally appeared on Adam Silver and was authored by Adam Silver
In 2009 I was given some new designs to implement for the forms on Argos.co.uk.
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.
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.
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.
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.
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:
- Make sure your questions are easy to understand so that users are more likely to not make mistakes
- Start with one thing per page to reduce cognitive load
- Allow users to make little mistakes like extra whitespace
- 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.
Summary #
While it may seem logical to validate as the user types, in reality it punishes users too early or too late.
Instead, validate as the user submits and use other techniques to reduce the chance of users making an error in the first place.
This content originally appeared on Adam Silver and was authored by Adam Silver
Adam Silver | Sciencx (2017-06-26T09:00:01+00:00) 9 reasons why live form validation is a bad idea and what to do instead. Retrieved from https://www.scien.cx/2017/06/26/9-reasons-why-live-form-validation-is-a-bad-idea-and-what-to-do-instead/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.