An error message arrives at the worst possible moment: the user was trying to do something and failed. It is the point at which an interface reveals whether it was designed with people in mind or only for the case where everything goes well. A good message turns a hiccup into a few-second fix; a bad one turns a small slip into abandonment.
The three questions to answer
Every useful error message answers three questions:
- What happened? In understandable terms, without internal codes.
- Why? When the cause is known and worth knowing.
- What can I do? The concrete action to solve it.
Compare a few examples:
| Weak message | Useful message |
|---|---|
| «Invalid data» | «The postcode must have 5 digits» |
| «Authentication error» | «Incorrect email or password. Check you typed them correctly or reset your password» |
| «Operation failed» | «The file is larger than 10 MB. Reduce its size or upload a lighter one» |
| «Error 403» | «You don't have permission to open this folder. Ask the person who shared it for access» |
In the login case, saying generically that the «email or password» is wrong, without saying which, is a deliberate choice: it avoids revealing which email addresses are registered. Security is part of good message design too.
The right tone
An error message should not blame, nor joke out of place. Some guidelines:
- avoid accusatory phrasing such as «You entered a wrong value»: «The value must be a number» describes the requirement without pointing fingers;
- avoid technical jargon and acronyms;
- avoid shouting capitals and exclamation marks;
- use humor very cautiously: a joke about a failed payment amuses nobody.
The tone can be friendly, but clarity comes first. A frustrated person wants to understand right away what to do, not read three lines of apologies.
Where to show it
Placement matters as much as wording. In forms, the message should appear next to the field that caused the problem, ideally right below it, so it is clear what it refers to. If there are several errors, a summary at the top of the form, with links to each field, helps someone who filled in a long page not to miss anything.
A message shown only in a temporary notification that disappears after three seconds is easy to miss and problematic for slow readers or people using a screen magnifier. Errors that require action must stay visible until they are resolved.
Accessibility needs two more measures: the message must be associated with the field so that screen readers announce it, and the error must not be signaled only by red, but also by text and, if useful, an icon.
When to show it
Validation timing changes the experience a lot:
- validating while typing is annoying: flagging «invalid email» after the first letter is useless and stressful;
- validating when leaving the field is usually the best compromise for formats such as emails or codes;
- validating on submit suits checks that need the server, such as username availability or password correctness;
- confirming when an error is fixed, removing the message as soon as the value becomes valid, reassures the user.
Prevent before you report
Many errors can be avoided upstream:
- accept different formats instead of enforcing one: a phone number with spaces, dashes or an international prefix should still be recognized;
- show requirements beforehand, not afterwards: password rules belong next to the field, not discovered after the first failed attempt;
- use suitable controls: a date picker prevents impossible dates, a numeric keyboard on mobile devices reduces typos in number fields;
- keep data already entered: an error must never empty the form.
System errors
Not every error is the user's doing. When a service does not respond or the connection drops, the message should say so honestly: «We can't reach the server. Your data hasn't been lost: please try again in a few minutes». If the operation was only partly carried out, for example a payment whose outcome is unknown, it is essential to explain how to check, so the person does not repeat the action and pay twice.
A generic error page should always offer a way out: a link to the home page, a search box, a way to contact support.
In short
- A good message says what happened, why, and how to fix it.
- The tone is neutral and clear, without blame or technical jargon.
- The message appears close to the problem, stays visible and is accessible.
- Validating at the right moment and preventing errors reduces the need to report them.
