If you’re using inline validation on your form, you’re slowing users down from completing it. Inline validation displays error messages inline with its offending field. When this is done before users submit the form, it causes them to make more errors and takes them longer to complete the form.
Validating Fields Before Submission
Two research studies, one with 77 participants and the other with 90 participants, concluded that users made significantly more errors completing a form if error messages were presented the moment a user filled out and left an erroneous field.
Even though users had the chance to correct their errors immediately, they ignored the error messages. Users continued to fill out the form and encountered more error messages when they submitted the form. Error messages presented pre-submission frustrated users in the study.
This finding proves that validating fields before submission causes users to make more errors, and more errors leads to user frustration. It’s more favorable to have a low error rate on your form, so users don’t spend a long time to complete it. The slower it takes to complete the form the more frustrated they’ll get, which can lead them to abandon the form.
Validating Fields After Submission
In contrast, the study discovered that users made fewer errors when error messages were presented after they pressed the submit button.
This finding can be explained by understanding the different modes users enter when completing a form. Users enter completion mode when they initiate a form. They’re focused on filling out each field regardless of making mistakes. After filling out each field, they switch to revision mode and are then focused on correcting errors.
Inline validation forces users to switch from completion to revision mode constantly. Switching modes back and forth splits and interrupts the user’s focus. A split and interrupted focus increases their cognitive load, causing more errors that lead to longer completion times.
Users prefer to focus on one mode at a time because it allows them to complete the form faster. Attention to one mode impairs their attention to the other. When their full attention is focused only on completion or revision, they have more mental resources they can commit to that mode.
Change Blindness
Validation pre-submission can cause change blindness in users. Users tend to ignore error messages when they’re in completion mode. When they do this and press the submit button, any new error messages that appear will likely be missed. It’s harder for users to detect a visual change to the form when it’s already populated with error messages.
Validation post submission prevents change blindness because users progress from an errorless form to a form with errors. This gives users a prominent visual change that indicates their submission attempt was performed.
Exceptional Fields to the Rule
Inline validation post submission isn’t suitable for every type of field. Username and password fields need to be validated pre-submission because they have the strictest input requirements. If these fields were validated post submission, it would take users an excessive amount of submissions to enter a valid input.
Users often choose usernames that are already claimed by other users. Finding an available username would require multiple input attempts.
Password fields have many character rules for user security. Meeting each character rule would also require multiple input attempts.
Inline validation pre-submission is not only for the username and password field, but any field with the strictest input requirements.
Validate Fields After Users Submit the Form
Inline validation post submission minimizes completion times, form errors, and user frustration. Designers need to stop validating fields before the user submits the form if they want to improve these metrics.
Validating fields after form submission matches the mental model of how users fill out forms. Users want to complete the form as quick as possible and will behave in ways that allow them to do so. Make sure you’re validating your fields when users are in revision mode, not completion mode, otherwise you’ll slow them down.
Book
Affiliate
Interesting article! However, it seems to contrast directly with the findings from https://baymard.com/blog/inline-form-validation
What are your thoughts on that? I’d love to hear. 🙂
They actually tested a wrongly implemented inline validation (see false error on e-mail format while the focus is on the field). So obviously there are more errors than with post-submit validation. But this is not linked to inline, this is linked to poor usability of that inline validation system. They should have compared error rates more properly. In other right use cases, inline validation clearly helps and reduces frustration.
That article concludes, “In essence, premature validations must be avoided. More specifically, when users enter a new field – without any existing errors – and begin their typing, the validity of the input should not be checked until the user has had a chance to fully type a valid input.”
They provide reasons against validation as users type their input, but they fail to provide reasons in support of validation when users leave the field. Thus, I trust their conclusion against “premature validation”, but I don’t trust their conclusion in support of validation when users leave the field.
Validation when users leave the field is also “premature” because most users will ignore those error messages as explained in my article. Not only that, but users have to go back to their previous field to correct their error. This is a lot of work because the user has to either tab backwards (which most don’t know how to do), or take their hand off the keys, put it on the mouse, and click on the previous field. This is inefficient and regressive and goes against the user need for progress and completion.
The shorter completion times may speak for validation after submit, but as the Baymard article shows the positive inline validation can actually help users moving forward through the form. Giving the users the sense they are doing the right thing may be more important than just sheer speed in ploughing through it. “The user need for progress and completion” can be met with nice green checkmarks.
Also, the research you base this article on is 15 years old! Certain things may never change, but the authors stating that the on blur type of validation is “not well known on the World Wide Web”, makes it feel pretty outdated.
Wouldn’t you say it’s more the intrusiveness of the ‘help’ that is what bothers users?
I for one do really not need to be notified, by a big warning, while I’m typing that ‘peter.parker’ is not a valid email.
If the box color of the field would be
black for fields I have not entered information in and
red for fields where the information I am entering or have entered is not correct,
I would really not mind at all I think.
Also, there is something to be said against validating usernames and passwords without a user submitting a form. It could make it (a lot?) easier (faster) to check if a certain username or password is valid for the site in question.
– Anne
Have you not heard of ‘onBlur’? The field is validated once the user leaves it.
Make more sense than these other tactics.
That’s what I was wondering the whole time I was reading this.
I actually came here looking for a best practice about when to save onBlur vs. having a save button.
This really depends on how inline errors are used and implemented. Inline errors are extremely frustrating when they come up WHILE you are attempting to fill in a field on the first attempt. For example, an email address for instance always has an “@” symbol. If a user is keying in their email address and inputs an invalid format and clicks/tabs out of the field, then an error message is justified so it can be corrected immediately.
It gets extremely frustrating when you are in the middle of typing the email address and you get the error message that pops up immediately as soon as you start typing the first character.
Users should be given the chance to input required information correctly first before being blasted with inline errors.
‘onBlur’ may have an advantage with this solution, however, it may be incorrect in assuming that just because a user leaves the field (onBlur) that they are done filling out the field.
This article is incorrect. It misinterprets the first study it cites (which claims n=77, but is actually n=76 when you add up the number of participants in each of the four groups it tests (18 + 19 + 17 + 22)) since the first study doesn’t test immediate *inline* validation at all – the immediate feedback after filling out the form is shown in an alert dialog (and thus not inline), which would certainly slow down the user.
The second study is misleading – it claims that immediate inline validations have a higher rate of user error. But the way it counts errors is flawed – the methodology double-counts how many user errors occurred when the user attempts to submit a form with immediate inline validations: if a user ignores an immediate inline validation and attempts to submit the form, the study counts two errors – one “first time” error and one “consecutive” error – even though the user has only typed one error! In contrast, for the groups without inline validation, the same series of steps would only count one error – a “first time” error. This would explain why the error rate for immediate inline validations is more than double the error rate for the other types of validations it tested – because many of those “errors” have been double counted.
It’s also noteworthy that the other two metrics the study tracked suggest that there is no significant difference between immediate inline validation and the other validation strategies – the time to complete was essentially the same for all strategies, and users actually subjectively *preferred* immediate inline validation by a significant amount. This is also evidence that the error-counting methodology was flawed – if there were really more than double the errors for immediate inline validation, you’d expect to see worse subjective user metrics and also a much higher time to complete.
Makes sense – thanks
Every other study I have read has shown the exact opposite statistics. Couple that with the fact that the data is very dated and does not represent the majority of input forms out there today.
An interesting article, but I will have to take it with a pinch of salt until I can test its conclusions myself, as it goes against most articles I’ve seen on similar topics.
Also, I found it interesting that uxmovement.com actually takes you to a different page entirely to tell you that you have entered an incorrect email address if you don’t enter an ‘@’. I’ve never seen an article that suggests that’s best practice for email fields! 🙂