Error Message Writing

Error messages should be specific, calm, and offer a clear recovery action.

Breaking down each option:
• A ("Error: Authentication failure. Status 401") — technical jargon, no recovery path
• B ("Wrong password") — the word "wrong" feels blaming; "Try again" is redundant (they will)
• C ✓ — neutral ("incorrect"), specific (password, not credentials), recovers with a direct link
• D — too verbose; "please verify" and "resubmit" are bureaucratic; no user should read this

Benchmark phrase: "Incorrect [thing]. [Recovery action]"

Key vocabulary:
• Error message — UI text explaining what went wrong
• Recovery action — a link or instruction that helps the user fix the error
• User-blaming language — copy that makes the user feel at fault (e.g., "wrong", "you entered")
• Inline validation — error messages shown next to the field that caused the error

Server errors require reassurance, a recovery action, and no technical jargon.

When the error is on your side (not the user's), the message must:
1. Own the problem ("we couldn't" not "there was an error")
2. Tell the user what happened in plain language
3. Give a recovery action ("try again in a moment")
4. Reduce anxiety ("your work is safe") if relevant

Option B ("something went wrong") is acceptable but vague — it doesn't explain what happened or reassure the user.
Option D is wordy and "we apologize for the inconvenience" reads as corporate boilerplate.

Key vocabulary:
• System-owned error — an error caused by your product, not user mistake
• Reassurance copy — text that reduces user anxiety during errors (e.g., "your data is safe")
• Plain language — no technical codes, jargon, or status numbers
• Conversational tone — first person ("We couldn't") rather than passive ("Error occurred")

Validation messages should tell users what to do next, not just what went wrong.

Anatomy of a good field-level validation message:
1. Action verb: "Please upload…" (directive, not declarative)
2. Accepted formats stated positively: "JPG or PNG"
3. Explains the constraint briefly: "PDFs aren't supported here"

Option A ("Invalid file format") — too vague, gives no path forward
Option B — better, but "Error:" prefix and the formal "Allowed types:" format feel cold
Option D — too long; users scan, not read; loses the key info in the middle of a long sentence

Key vocabulary:
• Validation message — inline text that tells users why their input was rejected
• Constraint copy — text that communicates acceptable input before or during entry
• Directive tone — using action verbs ("Please upload") rather than passive statements
• Affordance — communicating what a UI element can accept or do

Validation messages for blank required fields should be direct and instructional.

Option A ("Field required") — too terse; doesn't tell users what to do
Option B ("You forgot") — user-blaming language; creates a feeling of fault
Option C ("This field is required. Please enter…") — redundant; the user already knows it's required since they're seeing an error; cut the first sentence
Option D ✓ — direct action, specific, no blame, no redundancy

Principle: don't explain the constraint — tell them what to do instead.

Key vocabulary:
• Required field — a form input that must be completed for submission
• User-blaming language — copy that implies user error ("you forgot", "you missed")
• Action directive — a validation message that immediately tells the user the fix
• Brevity — eliminating redundant explanation in micro-level error copy

Network error messages should diagnose the likely cause simply and give a clear recovery step.

Mobile users encountering connection errors are typically on spotty Wi-Fi or cellular. The message should:
1. Describe what happened simply ("can't connect")
2. Suggest the most common fix ("check your internet connection")
3. Provide a recovery action ("try again")
4. Stay short — mobile screens have limited space

Option A — error code is meaningless to non-engineers
Option B — "device configuration panel" is too technical; most mobile users can't navigate there
Option D — "we have been notified" is only appropriate when it's a server-side issue you're actively fixing, not a client-side connectivity problem

Key vocabulary:
• Network error — failure caused by connectivity loss, not app logic
• Probable cause framing — suggesting the most likely fix when the cause is ambiguous
• Retry affordance — providing a "try again" button or instruction to encourage retry
• Context-appropriate length — keeping mobile error copy shorter than desktop copy