Error Message UX — What Users Do After Something Goes Wrong

Short answer: users recover from errors when the message says what went wrong, where, and what to do, and appears next to the problem. They leave when the message is vague, hidden, blames them, or wipes out what they typed. Track each error users see as an event, measure how many continue afterwards, and watch recordings of the ones that end sessions.

Table of Contents

1. Two Kinds of Error
2. Measuring Errors Users See
3. What Recordings Show
4. Writing a Good Message
5. Preventing the Error
6. Key Takeaways

Two Kinds of Error

Silent errors are worse, because the user has no idea what happened. They are covered by JavaScript error tracking. This article is mostly about the errors you choose to show.

Measuring Errors Users See

Send an event whenever a message is displayed:

deepsync("track", "error_shown", { area: "signup", reason: "password_too_short" });

Use a reason code. Never include what the user typed.

Then measure:

A message seen by many people with a low recovery rate is your priority. A message seen repeatedly by the same person is unclear.

What Recordings Show

Filter to sessions containing the error event and watch what follows.

• The message is off screen. The user presses submit, the page scrolls nowhere, and the error is at the top, out of view. They press submit again and again.
• The keyboard covers it on mobile.
• The field is not marked. The user cannot tell which of twelve fields is wrong.
• The form was cleared. Everything typed is gone, and so, soon, is the user.
• The error appears while typing, shouting "invalid email" after the first character.
• The message disappears after a few seconds, before it is read.
• The same correction is tried repeatedly because the rule was never stated.
• A generic "Something went wrong" with no next step.

Typed text is masked in DeepSync recordings, so you see the struggle without the content (PII masking).

Writing a Good Message

A useful error message answers three questions: what happened, why, and what now.

Rules:

1. Plain language. No codes or internal terms.
2. Specific. Name the field and the rule.
3. No blame. "Enter a date in the future" not "You entered an invalid date".
4. Offer the next step. A link or button where possible.
5. Place it beside the problem.
6. Keep the user's input.
7. Leave it visible until fixed.
8. Make it accessible: not colour alone, and announced to screen readers.

Preventing the Error

The best message is one never shown.

• Accept what people naturally type. Spaces in phone and card numbers, any letter case.
• State requirements up front, such as password rules and file size limits.
• Use the right input type so phones show the right keyboard.
• Validate when the user leaves a field, not on each keystroke and not only on submit.
• Disable impossible choices with an explanation.
• Offer sensible defaults.
• Confirm before destructive actions, and allow undo.
• Save progress so an error is not a restart.

Key Takeaways

• Shown errors need tracking as events; silent errors need error tracking.
• Measure recovery after each message.
• Place messages beside the field and keep the user's input.
• Prevent errors by accepting natural input and stating rules first.

Conclusion

Every error is a point where a user wanted to continue and could not. A good message lets them. A bad one sends them away.

Start free with DeepSync.