Error messages that lose customers at the point of action

4 days ago
3 min read

Updated: 3 days ago

Introduction

An error message appears only to people who were actively trying to do something. Nobody sees one while browsing. That makes these the most consequential sentences on a site, appearing at the moment of maximum intent and minimum patience, and they are almost always written by whoever built the form using whatever the system supplied.

The results are predictable. Vague messages that do not say what is wrong, messages that appear far from the field they refer to, forms that clear themselves, and rejections of perfectly valid input because a rule was written too narrowly. Each one ends a transaction that had already been won.

1. Error messages that lose customers usually fail to say what to do

The primary fault.

"Invalid input" identifies neither the field nor the problem nor the remedy. A message naming the field and the required format resolves it in one attempt. Every additional attempt loses a share of the people making it.

2. Put the message beside the field

The placement requirement.

A summary at the top of a long form is off-screen on a phone. The person needs to see the problem where they will fix it, and scrolling to find it loses a proportion. Scrolling the field into view automatically is better still.

3. Never clear the form

The unforgivable failure.

Losing everything somebody typed ends the transaction outright, and it happens most often on the pages where they typed the most. This is the highest-priority technical fix in this whole area. Test it after every change to a form, because it breaks silently.

4. Accept input people actually give

The over-strict validation problem.

Phone numbers with spaces, postcodes in lower case, names with apostrophes, addresses that do not fit your format. Rejecting valid data because it was formatted differently is a self-inflicted loss. Normalise the input yourself rather than asking the customer to.

5. Validate as they go, not at the end

The timing.

Flagging a problem when the field is left is easier to fix than presenting six errors after submission. Late validation also frequently loses the data. It also spreads the effort rather than concentrating it.

6. Use plain language

The tone.

No codes, no field names from the database, no blame. A person who has just been told something they did not understand is a person deciding whether this is worth continuing.

7. Say what happens after a real failure

The system-error case.

If a payment or submission genuinely failed, say what to do: try again, use another method, telephone. An apology with no instruction abandons somebody at the worst possible moment.

8. Do not lose the enquiry on a failure

The recovery.

Where possible, capture what was entered even when the process failed, so you can contact them. A failed submission is still somebody who wanted to reach you.

9. Trigger every error yourself and read them

The audit nobody does.

Deliberately break each field on your own forms, on a phone, and read what appears. Most businesses have never seen their own error messages.

Be careful about messages that reveal too much. Errors indicating whether an email address exists in your system, or exposing internal detail, create security and privacy issues, so plain language should not become excessive disclosure.

Conclusion

Write them as instructions, because they appear to people who were trying to buy.

Name the field and the required format rather than saying input is invalid, put the message beside the field where it will be fixed, never clear what somebody has typed, accept the formats people genuinely use, validate as they go rather than all at once, use plain language without codes or blame, say what to do after a genuine system failure, capture the details where you can so a failed submission is not a lost contact, and break every field on your own forms to read what appears.