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.
Switching attention back and forth from completion to revision mode interrupts and splits the user’s focus of attention. A split and interrupted focus cause users to think more and make more errors leading to longer completion times.
Users prefer to focus on one task mode at a time because it allows them to complete the form faster. Attention to one task mode impairs their attention to the other task mode. When their full attention is focused only on completion or revision, they have more mental resources they can commit to that task mode.
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.
Source link http://feedproxy.google.com/~r/uxmovement/~3/dhrBZdqM4Gw/