A practical checklist for error messages

Every audit we run turns up some version of this. Run through this the next time error messages comes up.

Consistency is the quiet half of design work: it rarely gets complimented, and its absence is noticed immediately. The version that survives contact with a real deadline is the simple one.

The checklist

• Say what went wrong and what to do about it
• Never blame the person reading the message
• Put the error next to the field that caused it
• Someone is named as the owner
• There is a date to review it again

What is actually at stake

Say what went wrong and what to do about it. It is worth being explicit about, because assumptions differ quietly. It is the sort of thing that looks like polish right up until it costs you an enquiry.

The short version

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

Pick the one that would hurt most if it failed, and start there.