Moment

error_recovery

Validation, system errors, failed states. No blame, clear next step.

Weights

ContentRX adjusts how strictly each standard is enforced in this moment. Cross-reference any standard by its ID to read the full rule.

Emphasized — flag more aggressively

  • VT-05 — Show empathy in error and failure states, scaled to the severity of the problem. High-impact errors (payment failures, data loss) should acknowledge the frustration and reassure the user. Low-impact errors (failed upload, timeout) should be clear and helpful without over-dramatizing.
    Empathetic tone is critical. Never blame the user.
  • CLR-01 — Use plain language. Avoid jargon, technical terms, or insider language unless the audience requires it.
    Error messages must be jargon-free — the user is already stressed.
  • ACT-01 — Start button and CTA text with a verb. Tell the user what will happen. Navigation labels, tabs, section headings, and confirmation or status messages are not CTAs — patterns like 'Project created' or 'Payment sent' are valid confirmation copy and should not be flagged.
    Every error must suggest a clear next action.
  • PRF-11
    'Simply re-enter your password' is the worst thing to say to a struggling user.
  • VT-03 — Be conversational but not casual. Write like a knowledgeable colleague, not a robot or a buddy.
    Robotic error copy alienates users when they need empathy most.
  • ACT-03 — When communicating a limitation, lead with what the user can do or offer an alternative path. Don't leave users at a dead end. Stating a restriction is acceptable when it's paired with a next step or workaround.
    Negative framing compounds anxiety in error states.
  • ACT-04 — Make the next step obvious. Every screen should have a clear primary action.
    Errors need actionable next steps, not just a description of what went wrong.

Suppressed — rarely applies here

  • GRM-03 — Use exclamation points sparingly. Never use more than one at a time, and never in error messages or alerts.
    Exclamation marks in errors feel like shouting at a struggling user.

Example pairs

Concrete "this, not that" examples observed in 2 style guides. Attribution is inline — see /ethics for the commitment and /sources for the full list.

  • CLR-01 · error_messageCC-BY-NC-ND-4.0

    Not this. An unexpected authentication error occurred.

    But this. We couldn't sign you in. Try again.

    Mailchimp voice: plain language + actionable recovery instead of jargon. — Mailchimp · Content Style Guide — Error messages

  • VT-05 · error_messageCC-BY-NC-ND-4.0

    Not this. You entered an invalid password.

    But this. That password didn't match. Try again.

    Error-recovery voice: describe the failure state, not the user's mistake. Mailchimp's empathy principle in action. — Mailchimp · Voice and tone — Empathy

  • GRM-03 · error_messageCC-BY-NC-ND-4.0

    Not this. Oops! Something went wrong! Please try again!

    But this. Something went wrong. Try again.

    Mailchimp: exclamation points are earned in celebration, not piled in errors. Excessive punctuation undermines calm. — Mailchimp · Grammar and mechanics — Exclamation points

  • PRF-11 · error_messageall-rights-reserved

    Not this. Just re-enter your password to continue.

    But this. Enter your password again to continue.

    Atlassian: skip 'just' in error states. Users already feel friction; reminding them it's 'just' something undermines the acknowledgment. — Atlassian Design System · Voice and tone — Respect the user

← The content model