Validation messages that tell users what to fix
Your form says "Invalid format" and expects the user to decode what you meant. They won't. They'll leave or paste the same thing again and hope it works.
Validation messages exist to prevent mistakes and guide corrections. Most fail at both.
Say what's wrong and what fixes it
Bad validation is vague: "Invalid email address." The user stares at their correctly-formatted email and has no idea what you want.
Good validation is specific: "Email addresses can't contain spaces. Remove the space before the @ symbol."
Even better: "We don't accept addresses from temporary email services. Use a permanent email address."
The pattern: describe the problem, state the fix. One sentence each if you can manage it.
Write for the error you're actually catching
If your validation catches empty fields, say "Enter your email address" — not "Invalid email." Nothing was invalid. Nothing was entered.
If you're checking format, say what format you want: "Phone numbers need 10 digits" or "Date format: MM/DD/YYYY."
If you're enforcing a business rule (no free email domains, no PO boxes, no addresses outside certain regions), say that. Don't disguise policy as a technical constraint.
Position messages where users are looking
Inline validation next to the field beats a summary at the top of the form. Users shouldn't have to hunt for what broke.
If you must use a summary, link each error to its field. Make the field label the link text, not "click here."
Write for the second attempt
Users read error messages after they've already tried something. They're annoyed. Your validation message is their second attempt at getting it right.
Skip the apology. Skip the reassurance. Get to the instruction.
Not: "Oops! Looks like something went wrong with your password. Passwords need to be strong to keep your account secure!"
Instead: "Password must be at least 12 characters and include a number."
Test your validation copy by breaking things
Fill out your own form wrong. Leave fields empty. Enter spaces, special characters, old dates, future dates, nonsense.
Read every error message as if you've never seen the form before. If you have to guess what to fix, rewrite it.
Some validation should prevent errors before they happen — that's what placeholder text and field-level help are for. But when validation fires, it should end the problem, not extend it.
Match validation timing to user intent
Real-time validation (as users type) works for format checks: email structure, character limits, required patterns.
On-blur validation (when users leave a field) works for completeness checks and lookups: "This username is already taken."
On-submit validation works for relationships between fields: "End date must be after start date."
Pick timing that helps users catch mistakes early without nagging them mid-thought.
Validation messages are instructions. If users can't follow them, you wrote the wrong instructions.