The error message that helped

A payment page's error message was changed from 'Transaction failed' to 'Your bank declined this card. Try another card or contact your bank.' Completed payments rose by six per cent.

The failure rate had not changed. What changed was what the user did next. 'Transaction failed' is a statement about the system and gives the user no action; a meaningful proportion of them concluded the site was broken and left. The replacement names the cause, locates it outside the site, and offers two next steps, one of which is immediately available.

Good error messages have a reliable structure: what happened, why, and what to do now. The third part is the one usually missing, and the first part is usually the only one present. A message that offers no action converts a recoverable problem into an abandonment, and the user's conclusion about who is at fault is formed by the wording rather than by the facts.

There is a constraint worth naming. Some causes cannot be revealed, because telling a user exactly why a card was declined would help someone testing stolen cards. In those cases the honest message states what can be acted on without stating the cause: this is why bank messages are vague in a way that looks careless and is deliberate.

The cheap audit is to collect every error string in a product and check each against the three parts. Most teams doing this for the first time find that a third of their messages are a single sentence naming a system component, and that nobody has read them since they were written.