Getting started with error messages
It is rarely the thing that gets a project approved, and often the thing that decides how it goes. A short on-ramp to error messages for teams who have not touched it before.
Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The reason this keeps coming up
Say what went wrong and what to do about it. The cost of getting this wrong is rarely visible on the day it happens. Assume whoever inherits this will have half your context and none of your patience.
Your first week
- Find out what is already in place
- Never blame the person reading the message
- Change one thing and measure it
Put the error next to the field that caused it. In practice this is a scheduling problem more than a technical one. The version that survives contact with a real deadline is the simple one.
What this looks like day to day
The measurable part of design is whether people can find what they came for and act on it without hesitating. Three things worth confirming about error messages before you move on:
- Someone can say what the current setup is without going to look
- Put the error next to the field that caused it — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.