"Invalid input" is not a message, it's a dead end
Most validation errors fail the user before the form does. They confirm something went wrong without saying what, where, or how to fix it — which turns a fixable typo into a support ticket or an abandoned form.
A good error message answers three questions in order: what's wrong, where it is, and what to do next. Drop any one of those and the user is left guessing, which is exactly the state validation was supposed to prevent.
The patterns that separate helpful from hostile
Validate on blur, not on keystroke
Flagging an email as invalid after the third character punishes someone mid-typing. Wait until they've left the field, or until submit for fields that are cheap to get wrong.
Name the field, not just the rule
"Must be at least 8 characters" floating near three password-shaped fields is a guessing game. Anchor the message to the exact field, inline.
State the fix, not just the failure
"Invalid date" describes a symptom. "Use DD/MM/YYYY" describes a cure. The second one ends the interaction; the first one starts a support thread.
Summarize on submit, detail inline
A top-of-form summary ("3 fields need attention") helps orientation on long forms, but it should link to each field's own inline message — never replace it.
Never blame the user in the copy
"You entered an invalid value" reads like an accusation. "This field needs a value between 1 and 100" reads like information. Same rule, different relationship with the reader.
Preserve what the user already typed
Clearing a field on error and forcing a retype is the fastest way to make a form feel punitive. Keep the value, fix the one thing that's wrong.
Server errors deserve the same care as client ones
Client-side validation gets the design attention; server-side failures — a duplicate record, a stale reference, a permission the UI didn't know about — often get dumped as a raw API message or a generic "Something went wrong." That's the exact moment a user is most likely to give up, because it happens after they've already committed to submitting.
Map server error codes to the same three-question format as client errors: what's wrong, where, what to do. If the mapping doesn't exist yet, that's the gap most worth closing before adding another field-level validator.
The takeaway
An error message is a design surface, not an afterthought. Validate at the right moment, name the field, state the fix, and never blame the user — and most "form errors" stop being errors at all, just quick corrections on the way to submit.
Let's talk about your product