Website Errors Customers Can Recover From

Most website errors are small.

The customer typed an email address with a missing dot. The card postcode has a space in a place the form did not expect. The file is too large. The date is in the future. None of this should be dramatic.

Then the website replies with something like "Invalid input" or "There was a problem". A tiny mistake becomes doubt.

Error messages are conversion copy. Unpleasant conversion copy, admittedly, but still conversion copy. They sit at the exact point where a motivated person has hit friction and needs help carrying on.

Every error message should explain the fix

A useful error message does three things.

It says what is wrong. It says where the problem is. It says what to do next.

That sounds basic because it is. It is also where many polished websites fail.

The GOV.UK Design System puts the standard in very practical terms: explain what went wrong and how to fix it, in plain English, beside the field that needs attention.

The accessibility standard says much the same thing. WCAG's error identification guidance requires the field with the problem to be identified and the error described in text. Its error suggestion guidance says that when the correction is known, the user should be given that suggestion.

Translated out of standards language: do not make the customer hunt.

A checkout error shows the difference

Imagine a service-business enquiry form with a required email field.

Bad:

Invalid.

Better:

Enter an email address in the format name@example.com.

Better still, if the page already showed the format nearby:

Enter an email address.

The difference is not tone polish. It is usefulness. "Invalid" tells the customer the website has rejected something. It does not tell them what to do. "Enter an email address" gives them the next move.

This is the small stuff that decides whether a warm enquiry arrives or quietly disappears.

Vague errors quietly lose customers

The most damaging error messages are not always the ones that sound rude. Sometimes they are polite, vague, and useless.

"Something went wrong. Try again later."

That can be fair if the system is genuinely down and the user cannot fix anything. It is poor when the problem is a missing field, a wrong format, a file size limit, or a payment detail that needs checking.

Polite vagueness forces the customer to guess. Should they refresh. Should they retype. Did the payment go through. Did the enquiry send. Will submitting again duplicate it. This is how a small wording failure becomes customer support work.

The useful version names the recoverable next step:

Upload a file smaller than 10MB.

Enter a postcode we can deliver to.

Check the card number and try again.

There are limits. If a payment provider declines a card, you may not be allowed to explain the exact reason. If a security rule blocks a login attempt, the message should not reveal information that helps an attacker. In those cases the best message may be less specific, but it still needs to say what the customer can safely do next.

Show the error while it can be fixed

There is a second failure pattern: the website tells people off before they have made a mistake. Nielsen Norman Group has a good phrase for this: hostile error messages.

That is not help. That is a form leaning over the desk and interrupting.

Show constraints before the mistake happens. Do not wait until failure to reveal that the file limit is 10MB. Prevent the error if you can, explain it clearly if you cannot, and avoid turning normal typing into a series of small accusations.

Test every error on the customer's path

If you are reviewing a website, do not only click through the ideal version. Break the forms on purpose.

Leave required fields empty. Type a bad email address. Upload a file that is too large. Zoom the page. Use the keyboard. Try the same thing on a phone.

Then read each error message as if you were the customer. Does it name the field or action that needs attention. Does it say what is wrong in plain language. Does it tell the customer what to do next. Can the customer find it without hunting.

On website projects, we treat the error state as the place where a site's apparent polish either holds or gives itself away. Our own contact form is deliberately plain: name, email, one context box, and a reply path that starts from what the visitor actually wrote.

If the answer is no, the site is leaking trust at the exact moment someone was trying to act.

This is not a full accessibility audit. It will not catch every issue around screen readers, cognitive load, high zoom, voice control, or complex dynamic behaviour. It is a practical first pass that catches a lot of expensive nonsense before customers do.

Small error messages can lose customers

Error messages are easy to leave until the end because they feel like edge cases. They are not edge cases to the person who hits one.

The useful version is short, specific, visible, and calm. It does not blame the customer or hide behind codes.

For small-business websites, that is often the design job in miniature: remove uncertainty, make the next step obvious, and do not make a good customer feel foolish.