Write error messages before the error happens

Most error messages get written after something goes wrong. A user hits submit, the system chokes, and someone scrambles to explain what just happened. That's backwards.

Write your error messages during initial setup—when you're defining fields, setting validation rules, deciding what's required. You know exactly what can go wrong at that point. Your thinking is clearer. You're not reacting to a problem; you're documenting the boundaries you just set.

Build the message when you build the constraint

If you're marking a field required, write the "this field is required" message right then. If you're setting a character limit, draft the "maximum 50 characters" message at the same time. If you're restricting file types, spell out "only .jpg, .png, or .gif files" before anyone tries to upload a .pdf.

The rule and its explanation should live together in your planning, not get bolted on later when someone complains.

Use plain structure, not apology

Error messages don't need cushioning. They need clarity. State what went wrong and what fixes it.

Bad: "Oops! Looks like something went wrong with your email address."

Better: "Enter a valid email address (must include @)."

The second version tells someone what to do. The first wastes time being friendly about a technical requirement. Be direct. People fixing errors want speed, not personality.

Test your wording against actual wrong input

Once you've drafted an error message, try it against the mistakes people will actually make. If your message says "invalid format" but someone typed a phone number with spaces instead of dashes, does your message help them fix it? If not, rewrite it to address the likely mistake: "Remove spaces between numbers."

This is easier to do during setup than after launch, when you're stuck debugging real user complaints. Similar to how validation messages that tell users what to fix work better when they're specific, error messages need to match the actual problem.

Keep a list as you go

Maintain a running document of every error state you've defined and its corresponding message. When you add a new validation rule six months later, you'll write a message that matches the pattern you've already established. Consistency matters more than cleverness.

If "Enter your last name" is how you phrase a required field error in one place, use that same structure everywhere. Don't switch to "Last name cannot be blank" three pages later. Pick a pattern during setup and stick to it.

Review them before you launch

Before anything goes live, read through your error messages as a list. Out of context, do they still make sense? Are you using the same terminology throughout? Have you accidentally written three different ways to say the same thing?

This review catches the inconsistencies that slip in when you're focused on individual fields. It also surfaces the messages that sounded fine in isolation but feel wrong when you see them all together.

Error messages written during setup are documentation you'll actually maintain. The ones written under pressure just pile up as technical debt.