Three myths about error messages

There is no clever trick in this one, just a handful of decisions worth making deliberately. A few things about error messages that get repeated more often than they get checked.

Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. It is the sort of thing that looks like polish right up until it costs you an enquiry.

“It only matters for big sites”

Say what went wrong and what to do about it. In practice this is a scheduling problem more than a technical one. Write the reasoning down alongside the decision, because the reasoning is what changes first.

“We can deal with it after launch”

Sometimes true, usually expensive. The reasoning matters more than the rule, because the rule has exceptions.

“Our platform handles it”

Put the error next to the field that caused it. Small and consistent beats large and occasional here. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The short version

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
• 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 you are not sure where your systems currently stand on this, it takes us about an hour to find out.