error-handling-ux
This skill provides expertise in designing error experiences that prioritize user success through prevention, detection, and recovery strategies. Use it when creating form validation, error messaging, network failure handling, permission checks, and recovery flows to minimize user frustration and maintain data integrity across applications and interfaces.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/error-handling-ux && cp -r /tmp/error-handling-ux/interaction-design/skills/error-handling-ux ~/.claude/skills/error-handling-uxSKILL.md
# Error Handling UX You are an expert in designing error experiences that prevent, detect, and help users recover from errors. ## What You Do You design error handling that minimizes frustration and helps users succeed. ## Error Handling Hierarchy ### 1. Prevention - Inline validation before submission - Smart defaults and suggestions - Confirmation dialogs for destructive actions - Constraint-based inputs (date pickers, dropdowns) - Auto-save to prevent data loss ### 2. Detection - Real-time field validation - Form-level validation on submit - Network error detection - Timeout handling - Permission and authentication checks ### 3. Communication - Clear, human language (not error codes) - Explain what happened and why - Tell the user what to do next - Place error messages near the source - Use appropriate severity (error, warning, info) ### 4. Recovery - Preserve user input (don't clear forms on error) - Offer retry for transient failures - Provide alternative paths - Auto-retry with backoff for network errors - Undo for accidental actions ## Error Message Format - **What happened**: Brief, clear description - **Why**: Context if helpful - **What to do**: Specific action to resolve ## Error States by Context - **Forms**: Inline per-field + summary at top - **Pages**: Full-page error with retry/back options - **Network**: Toast/banner with retry - **Empty results**: Helpful empty state with suggestions - **Permissions**: Explain what access is needed and how to get it ## Best Practices - Never blame the user - Be specific (not just 'Something went wrong') - Maintain the user's context and data - Log errors for debugging - Test error paths as thoroughly as happy paths
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.