Anti-patterns are approaches that fewer than 2 of 10 systems use—often for good reason. Each includes frequency data, why it fails, and what to do instead.
Category
Anti-Patterns
Delivery
4 anti-patterns
Tone
4 anti-patterns
Recovery
3 anti-patterns
Microcopy
3 anti-patterns
Delivery Anti-Patterns
Anti-Pattern 1: Modal for Form Validation
Frequency: 0 of 10 systems
No system uses a modal dialog to show form validation errors. Not one.
The correct approach: inline validation at the field level, not a modal interruption
Why it fails:
Breaks flow—user must dismiss before fixing
Loses context of which field has the error
Feels punishing for simple mistakes
Adds unnecessary clicks
Better alternative: Inline validation below the field. Show error on blur or submit, clear on valid input.
Anti-Pattern 2: Toast for User-Initiated Actions
Frequency: 1 of 10 systems (Figma only, for multi-field validation)
When a user explicitly triggers an action (upload, submit, save), toast notifications feel disconnected from the action.
Why it fails:
Toast appears away from the action
May auto-dismiss before user reads it
Doesn't connect error to cause
User may miss it entirely
Better alternative:
Single field: Inline at field
Upload modal: Error within modal
Form submit: Summary at top of form
Exception: Background operations (sync, auto-save) where toast is appropriate.
Anti-Pattern 3: Blocking UI for Network Errors
Frequency: 0 of 10 systems use full-page block for temporary network issues
No system shows a full-page "No connection" that prevents all interaction.
The correct approach: Slack shows offline status without blocking the entire UI
Why it fails:
User may be able to continue working (cached content)
Connection may return momentarily
Feels like app is broken, not network
Creates anxiety and frustration
Better alternative:
Banner for persistent status
Toast for temporary failures
In-context for specific features
Allow offline work when possible
Anti-Pattern 4: Hidden Error States
Frequency: Observed in edge cases across 2 systems
Showing nothing when an error occurs—blank space, silent failure, or unchanged UI.
Why it fails:
User doesn't know something went wrong
May retry repeatedly
May assume action succeeded
Erodes trust in the product
Better alternative: Always communicate errors visibly. Even "Something went wrong" is better than silence.
Tone Anti-Patterns
Anti-Pattern 5: Apologetic Tone for Validation Errors
Frequency: 0 of 10 systems say "Sorry" for validation
No system apologizes for user input errors.
Why it fails:
User made the mistake, not the system
Feels insincere
Adds unnecessary words
Confuses responsibility
Better alternative:
Terse: "Invalid email"
Instructional: "Please enter a valid email"
Specific: "Email must include @"
When "Sorry" IS appropriate:
System errors: "Sorry, something went wrong"
File type restrictions: "Sorry, this file type isn't supported" (Notion, Slack)
Service failures: "Sorry, we couldn't connect"
Anti-Pattern 6: Encouraging Tone for Errors
Frequency: 0 of 10 systems
No system uses encouraging language like "Great try!" or "Almost there!" for errors.
Why it fails:
Feels patronizing
Minimizes the problem
Inappropriate for the context
Users are frustrated, not encouraged
Better alternative: Neutral or reassuring (for network issues). Never cheerful.
Anti-Pattern 7: Blaming the User
Frequency: 0 of 10 systems explicitly blame
No system says "You entered the wrong..." or "Your mistake was..."
The correct approach: Atlassian takes ownership with 'We're having trouble' rather than blaming the user
Why it fails:
Damages relationship
Creates defensiveness
Often inaccurate (system may be at fault)
Unnecessary negativity
Better alternative:
Neutral: "File exceeds size limit"
System ownership: "We couldn't upload the file"
Focus on fix: "Try a file under 5 MB"
Anti-Pattern 8: Technical Jargon for Non-Technical Users
Frequency: Technical systems only (appropriate there)
Consumer-facing products shouldn't expose raw technical errors.
Appropriate for developers:
"Network request failed" (Linear)
"Failed to fetch dynamically imported module" (Retool)
"No such product: 'prod_TcvVpIlW2dy7Qm'" (Stripe)
Inappropriate for consumers:
"Error 500: Internal Server Error"
"null reference exception"
"CORS policy blocked"
Better alternative:
"Something went wrong. Please try again."
"We're having trouble loading this. Refresh to try again."
Show technical details in expandable section for power users
Recovery Anti-Patterns
Anti-Pattern 9: No Recovery for Recoverable Errors
Frequency: 53% of errors lack explicit recovery (too high)
Many errors that could offer recovery actions don't.
Error Type
Should Have Recovery
Often Missing
Network
Retry button
55% lack it
Permission
Request access
40% lack it
404
Go home / Search
30% lack it
Best practice: Linear offers 3 recovery paths for network errors
Why it fails:
User doesn't know what to do next
May abandon the task
Increases support burden
Feels like dead end
Better alternative: Always provide at least one recovery action for non-validation errors.
Anti-Pattern 10: Only Destructive Recovery Options
Frequency: 2 of 10 systems for some errors
Offering only "OK" or "Cancel" when better options exist.
Why it fails:
Doesn't actually help user recover
Feels dismissive
Loses context when dismissed
User must start over
Better alternative:
"Retry" for transient failures
"Try different file" for upload errors
"Go home" + "Search" for 404
"Request access" for permissions
Anti-Pattern 11: Auto-Dismiss Before Reading
Frequency: Observed in toast implementations
Toasts that disappear after 2-3 seconds for complex errors.
Why it fails:
Error message not read
User doesn't know what went wrong
No time to process
May not notice it at all
Better alternative:
Persist until dismissed for errors
Auto-dismiss only for confirmations/success
Provide dismiss (X) button always
Longer duration for complex messages
Unlock 6 more sections
Subscribe to access the full content and unlock all chapters.
Locked sections:
Avoid the 10 mistakes that make errors worse (with real failure examples)
Know what never works: Blocking UI, auto-dismiss, technical jargon
Fix tone issues before users complain (neutral vs apologetic data)
Design recovery that doesn't trap users in destructive-only choices
Complete 'what zero systems do' data to guide your decisions