We went through a client's support tickets looking for a pattern in what people were confused about, and found that a large share of them traced back to an error message that was technically true and practically useless.
Technically true, practically useless
"Validation failed" is accurate and tells the user nothing they can act on. "Request could not be processed" is accurate and sounds like the user did something wrong when the actual cause was a server-side timeout. Error copy written at the point a check fails tends to describe the check, not the situation the user is actually in.
What a usable error message states
- What happened, in a sentence a non-technical reader would understand, not the name of the exception.
- Whether it is the user's problem or not — a validation error is theirs to fix; a server timeout is not, and telling someone to "try again" for the first case and "we're looking into it" for the second changes what they do next.
- What to do now — a specific next step, even if that step is simply "wait a moment and try again" rather than nothing at all.
The specific example that started this
A payment form showed "Error: 402" to a customer whose card had a temporary hold from their bank, unrelated to anything the checkout could fix. Support fielded the same confused message every day for months before anyone traced it to that single string. Replacing it with a sentence naming the likely cause and suggesting they contact their bank cut that specific ticket category by most of its volume within a week.
An error message is the one piece of copy guaranteed to appear at the exact moment a user is already frustrated. It is worth writing with more care than the happy path gets, not less.
Why this keeps happening
Error paths get written last, often by whoever is finishing the ticket rather than whoever designed the feature, and they get tested for whether they fire, not for whether they help. A checklist item — "read every error string in this diff aloud as if you were the user seeing it for the first time" — catches most of the bad ones before release.
The return on a boring afternoon
We spent an afternoon auditing every user-facing error string on that project. It was not billed as a feature and it reduced that support queue's monthly volume more than any of the actual features shipped that quarter, which is a fact worth remembering the next time error copy gets deprioritised.