Form validation looks like an engineering detail until it goes wrong.
Then the whole product feels rude. Errors show up too early. The submit button is disabled with no explanation. Focus jumps to the wrong place. The user fixes one field and still does not know what to do next.
Good validation is design work. It decides how the product helps someone recover.
Most field-level problems should be shown near the field. If the email is invalid, the message belongs under the email input. If the password is too short, the message belongs near the password input.
The user should not have to scan the whole page to find the problem.
Good inline errors are specific:
Enter an email addressPassword must be at least 8 charactersCard number is missing 3 digits
Bad inline errors only name failure: Invalid,
Error, Required. They make the user do the
product's work.
Inline errors are not always enough. Long forms may need an error summary at the top after submit.
A summary is useful when the user might not see every invalid field at once. For example, a billing form might have errors in contact details, address, and payment sections. A top message can say:
Fix 3 fields before continuing.
That message should not replace inline errors. It should point to them. The summary gives the overview. The field messages give the fix.
Showing errors too early makes a form feel hostile. If the user focuses an empty email field and you instantly show "Email is required," the product is scolding them before they have done anything.
A better rule is simple: do not show an error until the user has had a chance to answer.
Validation should feel like help, not surveillance.
After a failed submit, focus should help the user recover. Usually that means moving focus to the first invalid field or to the error summary if the form is long.
Do not leave focus on a submit button that did nothing visible. The user pressed the button. The product found a problem. Focus should now support the next step.
For short forms, focusing the first invalid field is often best. For long forms, focusing a summary can be better because it explains the whole situation before the user jumps into one field.
Disabled submit buttons look clean, but they often create confusion.
The user sees a button they cannot press and has to guess why. Is a field missing? Is the password too weak? Is the form still loading? Is something broken?
Sometimes it is better to let the user press submit and then explain what needs to change. This is especially true for forms with several fields.
If you do disable submit, the reason should be obvious from the UI around it. A disabled button without visible guidance is a dead end.
Some validation happens against the server. A username may look valid locally but already be taken. A coupon code may have expired. A domain may fail verification.
In those cases, the UI should show that a check is happening and then give a useful result.
Checking username...This username is availableThat username is already takenThe error should not feel like a surprise at the end if the product could have checked earlier.
Validation is not there to prove the user was wrong. It is there to help them finish.
Before shipping a form, ask:
A good form does not just reject bad input. It guides the user back to a valid path.