UX Glossary · E
Error message
Also: Error state
What the system says when something has gone wrong, and one of the cheapest things to fix well.
An error message has three jobs: say what happened, say why it matters, and say what to do now. Most manage the first badly and skip the other two.
Nielsen’s ninth usability heuristic puts it directly: help users recognise, diagnose and recover from errors. Recovery is the part that gets dropped.
What makes them bad
System language. “Error 422: Unprocessable entity” describes the server’s state to a person who cannot act on it.
Blame. “You entered an invalid date” is worse than “Enter the date as DD.MM.YYYY”, which contains the fix.
No route forward. A message describing a failure without an action leaves the user to guess whether to retry, wait, or give up.
Wrong timing. Validating an email before someone has finished typing it flags an error that is not yet an error.
Why they get neglected
Error states are filed as copywriting rather than design, so they get written last, by whoever is closest to the code. They are also the moments when a user is already frustrated, which makes them the highest-leverage words in the product.
In practice
Write the error states while designing the happy path, not after. And prefer preventing the error: an input mask, a sensible default or a constrained control removes the message entirely, which is always better than wording it well.