Error messages need specific recovery instructions
When a form submission fails, "Something went wrong" is not an error message—it's an admission that you didn't think through failure states. Users who encounter errors need two things: what broke and what action will fix it. Neither is optional.
Write for the specific failure condition
Every error message should identify the exact problem. "Email address is invalid" beats "There was an error with your submission" because it isolates the field. "Email address must include an @ symbol" is better still because it states the validation rule that failed. The more specific your error text, the faster users can correct their input and move forward.
This specificity requires that your CMS or form handler can distinguish between error types. If your system only supports one generic error message per field, that's a platform problem you need to solve before you write interface copy. Lumping "field required," "format invalid," and "value out of range" into the same message text wastes everyone's time.
State the corrective action in imperative mood
"Your password must contain at least 8 characters" tells users what the rule is. "Enter at least 8 characters" tells them what to do. Error messages are instructions, not documentation. Use imperative verbs: enter, choose, upload, remove, try again.
When the fix isn't obvious, spell it out completely. "This email address is already registered. Log in instead or use a different email address." That sentence gives two actionable paths. Compare it to "Email address already exists," which just states a fact and leaves users stuck.
For errors the user can't fix immediately—server timeouts, payment processing failures, file upload limits—your message must explain why the action failed and what the user should try instead. "This file is too large to upload. Maximum size is 5MB. Compress your image or choose a smaller file." Not "Upload failed."
Position error text next to the problem
Error messages belong adjacent to the field that triggered them, not in a dismissible banner at the top of the page. Users shouldn't have to scroll or hunt for context. Inline error text—preferably above the field, definitely below the label—keeps the problem and the solution in the same visual space.
If your form has multiple errors, show all of them at once. Forcing users to submit repeatedly to discover each new validation failure is hostile design. List every error, link each message to its field if the form is long, and let users fix everything in one pass.
Some CMSs make this harder than it should be. If your platform only supports page-level error messages, write them as a numbered list with field names: "1. Email address must include an @ symbol. 2. Password must contain at least 8 characters." It's not ideal, but it's better than a vague summary.
Test your error messages with real failure scenarios
You won't know if your error copy works until you trigger every error state and read what appears. Submit forms with missing required fields, invalid formats, duplicate values, and boundary-case input. Check that each message names the problem and states the fix.
Most error text is written once during initial development and never reviewed. That's how you end up with placeholder copy like "Error: 422" in production. Schedule time to audit your error messages the same way you'd audit alt text or menu labels. If you can't understand the error without reading the code, neither can your users.
Your error messages are part of your interface. Write them like it.