Skip to content
UX Atlas

Design problem

Unclear errors

Something failed, the message does not say what or why, and there is no route back to working.

How you know you have it

  • The product says “something went wrong” and stops there.
  • Support tickets quote error text verbatim because it means nothing to the reader.
  • Errors appear far from the field that caused them.
  • The same failure produces different messages in different places.

Do these first

  1. 1Rewrite the five most frequent messages to name the cause and the next action.
  2. 2Move each message next to the control that produced it, and announce it to assistive technology.
  3. 3Remove the error entirely where a constraint or a better default would prevent it.
  4. 4Give every failure a way forward: retry, edit, or a route to a human.

Why it happens

Messages written from the system's point of view

A validation rule restated is not an explanation. The reader needs what happened, why if you can say honestly, and what to do next.

No recovery path

A message with no retry, no edit and no support route leaves the reader stuck with correct information.

Errors that should have been prevented

Many messages exist because the interface allowed an impossible input in the first place.

What to read, and why

Error quality is half interaction design and half writing, so both sets of entries appear here, alongside the accessibility requirements that govern announcement.

Why it behaves this way

5

The mechanism underneath the symptom. Read these when the fix needs justifying to somebody else.

  • Help Users Recognise, Diagnose and Recover From Errors

    Error messages should say what happened, why, and what to do next, in plain language.

    HeuristicExpert heuristic

  • Error Prevention

    Better than a good error message is a design in which the error cannot occur.

    HeuristicExpert heuristic

  • Forgiveness

    An interface people can explore without fear produces confident users and fewer support tickets.

    PrincipleExpert heuristic

  • Postel's Law

    Be liberal in what you accept and conservative in what you send, which for interfaces means accepting messy input and returning clean output.

    LawCraft convention

  • User Control and Freedom

    Users make mistakes and change their minds, so every state needs a clearly marked way out.

    HeuristicExpert heuristic

The craft decisions

3

The visual and structural levers that produce or relieve this problem.

  • Semantic Color

    Colours assigned a fixed meaning, which only works if the assignment is consistent and never the only signal.

    UI foundationCraft convention

  • Visual States

    Every interactive element needs a defined appearance for every state it can be in, and most designs specify only two.

    UI foundationCraft convention

  • Proximity

    Things placed close together are read as belonging together, before anything is read.

    UI foundationEstablished research

Patterns that address it

4

Recognised solutions, with the conditions under which each earns its place.

  • Input Validation

    Checking input at the right moment, which is rarely while the user is still typing.

    PatternExpert heuristic

  • Empty States

    The screen before there is anything to show, which is a teaching opportunity rather than a gap.

    PatternCraft convention

  • Undo

    Reversing the last action, which is the single highest-value safety mechanism in most products.

    PatternExpert heuristic

  • Confirmation

    An interruption that should be reserved for genuinely irreversible actions, because it stops being read when it is routine.

    PatternExpert heuristic

Components involved

3

States, behaviour and the accessibility contract you will need to specify.

  • Alert and Inline Message

    A persistent message tied to a context, which is where anything requiring action belongs.

    ComponentCraft convention

  • Toast

    A brief confirmation that disappears, which makes it unsuitable for anything the user must act on.

    ComponentCraft convention

  • Text Input

    Free-form entry, where the label, the hint and the error placement do most of the work.

    ComponentCraft convention

Language

3

Where the words carry more of the fix than the layout does.

  • Error Messages

    Say what happened, why if you know, and what to do next, in that order and in plain language.

    UX writingExpert heuristic

  • Microcopy

    The small pieces of text that do most of the work: labels, hints, empty states, errors and confirmations.

    UX writingCraft convention

  • Voice and Tone

    Voice is who you are and stays constant. Tone is how you speak in a moment and must change with the situation.

    UX writingCraft convention

Accessibility requirements

4

The requirements this problem raises, mapped to the decisions that produce them.

  • Error Identification and Suggestion

    Errors must be identified in text, described specifically, and accompanied by a suggested fix where one is known.

    AccessibilityCraft convention

  • Status Messages and Live Regions

    Telling assistive technology that something changed, when focus did not move to say so.

    AccessibilityCraft convention

  • Labels and Instructions

    Every input needs a persistent label, and format requirements must be stated before the user types.

    AccessibilityCraft convention

  • Focus Management

    Deliberately moving focus when the interface changes, so keyboard and screen reader users are not stranded.

    AccessibilityCraft convention

How to find out

2

Methods suited to confirming the cause before you commit to a fix.

  • Usability Testing

    Watching people attempt real tasks, which is the most direct evidence available about whether a design works.

    Research methodEstablished research

  • Product Analytics

    Measuring what people do at scale, which tells you where problems are and never why they exist.

    Research methodCraft convention

Check your work

2

Interactive review passes, with progress saved in your browser.

  • Form UX Checklist

    A review pass for any form, covering structure, labelling, validation, errors and accessibility.

    ChecklistExpert heuristic

  • Pre-Launch Checklist

    The pass before shipping, covering states, edge cases, accessibility, performance and the things that only break in production.

    ChecklistCraft convention

Decisions other teams made

1

Worked cases, including the options that were rejected.

Where this usually shows up

The same material, organised around the surface you are building rather than the symptom you are fixing.