← Back

Microcopy That Prevents Error.

Interfaces don’t fail in the happy path.

They fail in the gray, sweaty moments: when someone is tired, hurried, embarrassed, wrong. When the input doesn’t validate. When the card declines. When the “Save” button does nothing and the user feels the ancient dread of lost work.

Most microcopy treats these moments like an inconvenience. It says “Invalid input” and walks away.

That’s not copy. That’s abandonment.

Microcopy is error prevention

The goal of a good message is not to announce that something went wrong. The user already knows. The goal is to reduce uncertainty.

In practice, that means three things:

  1. identify the error (what, where)
  2. suggest the correction (how)
  3. preserve trust (tone, reversibility, clarity)

If you do those well, support tickets drop and the interface starts behaving like an adult.

Tactics that actually work

  • Name the field. Don’t say “Invalid.” Say “Email address is missing” or “Card number is too short.”
  • Say what format you accept. If you know the correction, give it. One line. No lecture.
  • Avoid blame. Don’t scold. State the mismatch: what you got vs what you need.
  • Make reversibility explicit. “Undo,” “Restore,” “You can change this later.” Calm is a feature.
  • Ban the useless phrases. “Something went wrong.” “Try again later.” “Invalid input.” These are placeholders masquerading as messages.
  • Be consistent with verbs. Delete/remove/archive are not three different actions unless they truly are.
  • Write for the moment, not the manual. Progressive disclosure: give essential detail now; offer deeper detail only if needed.

Two prompts to build a real microcopy system

1) Generate a microcopy library (field-specific, consistent, useful).

You are writing microcopy for a product UI. Be concise and precise.
 
Create an error-message set for this form:
{list the fields + rules, e.g., email must be name@domain.com}
 
For each field, produce:
- Missing value message
- Invalid format message
- Security-sensitive variant (do not reveal account existence)
 
Rules:
- Each message must identify the field and describe the error in plain text.
- If a correction suggestion is known, include it in the same line.
- No generic phrases (“something went wrong”).
- Tone: calm, adult, non-blaming.

2) Adversarial review (find ambiguity, leakage, bloat).

Act as a hostile reviewer.
 
For each message:
- Identify ambiguity (“what does the user do now?”)
- Identify security leakage (does it reveal too much?)
- Identify bloat (extra words that don’t change action)
 
Return a revised set with the smallest edits possible.

The quiet standard

The best error message is one the user almost doesn’t notice. Not because it’s hidden, but because it is instantly legible: what happened, where, what to do.

Good microcopy turns user mistakes into trivial events.