Error messages: what to get right first

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. If you only fix one thing about error messages this quarter, make it the first item below.

The measurable part of design is whether people can find what they came for and act on it without hesitating. It rarely shows up as a line item, which is exactly why it slips.

Start here

Say what went wrong and what to do about it. There is a version of this that is over-engineered, and it is worth avoiding. Assume whoever inherits this will have half your context and none of your patience.

Then this

Never blame the person reading the message. Where this goes wrong is almost never a lack of knowledge. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Eventually

Put the error next to the field that caused it. That sounds obvious written down. It is still the thing most often skipped. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. 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 any of that sounds like a description of your current setup, it is fixable.