General form setup
"Reward early, punish late"
Most of what's on this page is a variation on this saying, so let's quickly define it.
Punish late means that we shouldn't mark a form field as having an error until we're certain that it does.
Reward early means that we should mark a form field as not having an error as soon as we're no longer certain that it has an error.
Further reading on "reward early, punish late":
Don't disable form submit buttons
This can lead to people frantically scrolling through a form, trying to find the field they need to fill in or correct in order to enable it.
A better experience is to let them use the submit button any time, and if at that time there are invalid fields, we can let them know. Jump to the on-submit validation section to learn more.
Avoid optional fields; but label them when they exist
The longer a form is, the more complicated it's perceived as, and the less likely someone is to finish it, or even start.
So first of all, if we're including a question in a form, and we don't care if it gets an answer or not, we should think about whether it's worth asking at all.
In other words, optional fields should be the exception, not the norm. And as the exception, between optional and required fields, the optional ones should get a special label.
If your goal is to communicate that a certain question only needs to be answered if previous questions are answered a certain way, hide it until you get an answer that makes showing it appropriate.
Types of validation
There are three points at which form data can be validated:
- Inline validation: as someone interacts with a form, the system validates the data they've entered in each field
- On-submit validation: when someone indicates that they would like to submit the form, only then does the system validate the data
- Post-submit validation: after the form's data is actually submitted to some sort of backend, only then does the system validate it
Because each of these approaches has places where it's most appropriate, a given form may actually use two of them, or even all three.
Inline validation
Inline validation is the most common type of validation you'll use in a form.
If the criteria for validating a field are simple enough that we can run the validation near-instantly, inline validation is a good choice.
Wait as long as possible to show error messages on previously-valid fields
When someone focuses Usually a click or tap on the field, or using Tab or Shift+Tab until the field is reached a blank field, and starts typing or otherwise entering a value, wait until they blur Usually a click or tap outside of the field, or pressing Tab or Shift+Tab until another focusable element is reached the field to validate it.
The field doesn't necessarily need to start off blank though. Here's an example where the field starts with a valid value in it. In the second case, changing this to an invalid value doesn't show an error state until the field is blurred.
Clear a field's error state as soon as possible
When the value in an input field changes, we should immediately check to see if the new value is valid; or at least, whether we can still be certain that it's invalid. In other words, "reward early".
Don't penalize people for answering out of order
In other words: previously-answered, empty, required fields shouldn't show an error on blur. If someone focuses an empty, required field, then blurs it without entering a value, that shouldn't be enough to show an error.
If there had been a value previously, and they removed it, that's another story.
But wait, that means that a user can tab through a whole form full of required fields, never enter data in any of them, and then submit the form. In that case, how will they ever know which required fields they missed?
On-submit validation
When someone tries to submit a form, that's when you can tell them if they missed any required fields.
We shouldn't disable the submit button until all fields have valid data. We also should not mark blank, required fields with an error just because someone didn't answer them right away. But when someone tries to submit a form, this is our chance to let them know about these issues.
Post-submit validation
Post-submit validation is used for anything else we can't check without actually submitting the form data to some sort of backend.
Errors should be presented just like on-submit validation: an error summary at the beginning of the form, and error messages on each affected form field.