Design Error States That Help Users Recover
Feedback & States · errors, undo
Updated 2026-07-28
- Treat errors as different categories, not one generic problem. Each type needs its own response pattern:
- Validation errors — the user entered something incorrectly.
- Network errors — the connection failed or timed out.
- Server errors — the system failed unexpectedly.
- Permission errors — the user is not allowed to complete the action.
- Authentication errors — the user needs to sign in or verify access.
- Match the error surface to the severity:
- Use inline errors for problems users can fix immediately.
- Use toasts for temporary issues that do not block progress.
- Use modals only when the user must make a decision or cannot continue in any other way.
- Avoid interrupting users with the wrong level of friction. A simple typo should not trigger a blocking server-style error message.
- Make every error recoverable. Provide a clear next step:
- Retry the action.
- Refresh the page.
- Check permissions.
- Contact support.
- Correct the input.
A dead-end error message leaves users stuck at the worst possible moment.
- Write errors for humans, not systems. Replace technical messages with clear explanations:
- Instead of: “An error occurred.”
- Use: “Lost connection. Reconnecting in 5 seconds.”
- Prevent errors before they happen. Use inline validation, clear requirements, and immediate feedback to catch issues before users submit a form.
- Guide users through recovery instead of simply reporting failure. A strong error state explains what happened, why it happened, and what the user can do next.
- Good error handling turns frustration into progress. The goal is not just to show that something went wrong—it is to help users move forward.
Related guides
UX Handbook