Five mistakes teams make with error messages
The gap between knowing this and actually doing it is where most teams lose ground. These are the ones we run into repeatedly when we audit error messages.
The measurable part of design is whether people can find what they came for and act on it without hesitating. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Common failure modes
- Treating it as a launch task rather than an ongoing one
- Assuming someone else already owns it
- Say what went wrong and what to do about it
- Never blame the person reading the message
- Never checking whether the fix actually worked
Put the error next to the field that caused it. Getting it slightly wrong is survivable. Ignoring it entirely is not. If it only works because one person remembers to do something, it does not work yet.
A reasonable first step
What this looks like day to day
Consistency is the quiet half of design work: it rarely gets complimented, and its absence is noticed immediately. 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
Worth checking on your own setup before it becomes someone else's problem to fix.