Error State Mobile

Error states communicate when operations fail, data cannot load, or problems prevent normal functionality. Mobile applications encounter errors from network failures, server issues, user input problems, and unexpected conditions. Design systems must specify clear, helpful error patterns that guide users toward resolution.

What Are Mobile Error States

Error states are UI patterns that display when something goes wrong. They replace or augment normal content with error indication, explanation, and recovery options. Good error states acknowledge the problem, explain it understandably, and provide paths forward.

Error categories include network errors (no connection, timeout, server errors), content errors (not found, access denied, corrupted data), input errors (validation failures, format issues), and system errors (crashes, unexpected states).

Each error category may warrant different treatment. Network errors might suggest retrying. Input errors should highlight specific problems. Permission errors should explain how to gain access.

How Error States Work on Mobile

Error messaging provides clear, non-technical explanations. Technical error codes and jargon confuse users. Plain language describing what happened and what users can do helps more.

Error State Components:

Full-Screen Errors:
- Icon: Visual error indication
- Title: Brief error summary
- Description: Explanation and context
- Action: Primary recovery button
- Secondary: Alternative action if available

Inline Errors:
- Contextual to the failing element
- Clear error message
- Visual highlighting (color, icon)
- Specific guidance for resolution

Toast/Snackbar Errors:
- Brief notification
- Action for retry or details
- Auto-dismiss or dismissible
- Non-blocking

Error Message Guidelines:
- Use plain language
- Be specific about what happened
- Explain what users can do
- Avoid blame ("You did something wrong")
- Provide actionable next steps

Examples:
Bad: "Error 500: Internal Server Error"
Good: "Something went wrong on our end. Please try again in a few minutes."

Bad: "Invalid input"
Good: "Email address should include @ symbol"

Visual treatment distinguishes error states. Color (typically red), icons (warning or error symbols), and positioning all indicate error conditions. These visual patterns should be consistent throughout the design system.

Recovery actions provide paths forward. Retry buttons address transient failures. Edit actions help fix input errors. Contact support provides escalation for persistent problems. Clear actions prevent users from feeling stuck.

Key Considerations

• Clear, non-technical error messages
• Consistent visual error treatment
• Actionable recovery options
• Error severity indication
• Accessibility for screen readers
• Error logging for debugging

Common Questions

How should error message tone be specified?

Empathetic tone acknowledges user frustration without blame. “We couldn’t load your content” is better than “Content failed to load.”

Action-oriented messages focus on resolution. “Try again” or “Check your connection” guides users forward.

Specific messages help with specific errors. Validation errors should identify exactly what is wrong. Generic errors are appropriate only when specifics are unavailable.

Design system writing guidelines should include error message examples demonstrating appropriate tone and structure.

When should errors use full-screen versus inline treatment?

Full-screen errors suit complete failures. When no content can load, when navigation is impossible, or when the entire experience fails, full-screen errors communicate severity appropriately.

Inline errors suit partial failures or specific issues. Form field validation, individual item loading failures, or feature-specific problems use inline errors without disrupting everything.

Toast/snackbar errors suit background operation failures. Actions that happen in background (sync failures, send failures) can use transient error notifications.

Severity guides treatment. Critical errors blocking all functionality need prominent treatment. Minor errors affecting non-essential features need less disruptive treatment.

How should error states handle accessibility?

Screen reader announcement ensures error communication. When errors appear, VoiceOver and TalkBack should announce error content.

Focus management helps keyboard and screen reader users. When errors appear, focus should move to error content or remain at a logical position.

Color should not be the only error indicator. Icons, text, and position supplement color for users who cannot perceive color differences.

Error recovery actions must be accessible. Retry buttons and recovery links need proper labeling and reachability.

Summary

Error states communicate failures and guide recovery. Clear messaging in plain language, consistent visual treatment, and actionable recovery options help users overcome problems. Design systems should specify error patterns for different severity levels and contexts. Accessibility ensures all users receive error communication regardless of ability.