User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
What is really the preferred behavior of form validation? When should the validation take place?
Is the preferred way the same on long vs. short forms, wizards and so on? What do you think?
(The form will be on desktop platform only)
Generally,
The way in which validation should be implemented varies based on the unique needs of the form. However, in general, if the user’s input is incorrect, the system should inform the user by providing an identifiable and clear message that aids in correcting the error.
from https://www.nngroup.com/articles/indicators-validations-notifications/
More to the point,
The right time to inform about the success/failure of provided data is right after the user has submitted the information. Inline form validation that immediately informs users about the correctness of provided data results in an increase in the conversion rate.
from https://designmodo.com/ux-form-validation/
Working a lot with forms, I believe the least annoying way is to do it when the input field is out of focus until the user fixes the error.
Twitter has it quite right
Validation should be done per input field:
Edit:
For critical forms such as Login, Online transactions, providing any type of information it is necessary to use server validations over https that will execute when users hit the Submit button.
For field level validations such as email, tel, number we can take advantage of client-side validations but with fallback for browsers that have disabled JavaScript;
Looking at the new values in type attribute <input type="email" />,
and the best implemented in almost all browsers Pattern attribute <input type="tel" pattern="^\d{4}-\d{3}-\d{4}$" >
We are experiencing form validations as the user types / conditions are met [ HTML5 client-side form validations ]. The program/code doesn't send a request to server to validate the information, browsers are taking care of it.
Examples:
The user should be informed about an error as early as possible, in all types of forms (wizards, long forms, etc).
If it is possible to give error feedback while the user types, then do it. This will allow the user to fix his error more efficiently, because the cursor and his mind is located on the subject of the error.
I must stress the difference between informing the user about an error and stopping the user. The user may be informed about an error while he types, but he will not be stopped until the form is submitted or the field is out of focus. When to stop the user, depends from the severity of the error, the use case of the form, the type of the form and many other factors.
First of all though, you should try to prevent errors , i.e. by using list boxes.
This is a delicate balance, as the answers here indicate. Informing the user after they've completed the whole form (as some apps/sites still do) interrupts the flow.
You'll create less frustration and reduce cognitive load if you follow a "just-in-time" principal of informing progressively throughout the form. This is usually referred to as in-line validation.
You want to inform them:
The catch with just-in-time information is that you can't be entirely certain when the user is done typing/thinking.
Too early and you break their concentration on the field in question.
Too late and they're already onto the next one. Focus broken again.
Make an educated guess about the focus + typing + pause delay and then test it in action. Test with a prototype and continue watching your metrics (form abandonment, entry error) in production. Fine tune when you reach the happy middle ground.
Ouch. At first, I was convinced of one option. But thinking more carefully the answer, in my opinion, is Depends, and all 3.
There are different types of inputs, and some inputs need different validation.
A password could be validated as the user types. If your site does not accept for example simple passwords like "123" that could be validated on the fly. You see this in "password straight" evaluators.
Choosing a username could be also validated on the fly as user types.
Typing a phone number with non-numeric characters, like letters, slashes or spaces could display a warning when detecting one.
This should mark some possible typing errors, for example, a not valid email, a name with only one letter or an invalid postal code.
Here is a bit obvious that a "Send or Next step" button should mark the empty required fields.
Some fields could have additional help like autocomplete when typing common things like places, county, probably States.
What I want to explore here is that some validations can be for example more subtle, for example, when typing an email the field could be a light gray color as the background, and when the email is valid (after having an @ and a final .something) change to white.
But when validating empty fields this same field can turn to a strong angry red.
I need to use a cell phone provider's page constantly to add some cash to my phone.
But the "modern cool sleek" color scheme they have makes a check box for an "I accept terms and conditions" almost totally invisible. I assure you, that I would mark it if I could see it from start.
