Error messages: the questions we get asked most

Most teams know this matters. Fewer have decided who owns it. The questions about error messages that come up most often on our calls.

Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Do we need to care about this?

Say what went wrong and what to do about it. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Put the error next to the field that caused it. None of that requires a large budget, only a decision and someone to own it. If it only works because one person remembers to do something, it does not work yet.

In practice

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
• Say what went wrong and what to do about it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.