Error Handling Ux
Shape how forms, pages, and network failures feel so users can recover without rage-quitting your app.
Overview
Error Handling UX is an agent skill most often used in Build (also Ship and Grow) that designs prevention, detection, messaging, and recovery for failure states in product interfaces.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill error-handling-uxWhat is this skill?
- 4-layer hierarchy: prevention, detection, communication, and recovery
- Error message scaffold: what happened, why (when useful), and what to do next
- Context-specific patterns for forms, full-page errors, network toasts, and empty results
- Recovery tactics: preserve input, retry with backoff, alternates, and undo for destructive actions
- Constraint-based inputs and confirmations to prevent errors before they happen
- 4-layer error handling hierarchy: prevention, detection, communication, recovery
Adoption & trust: 584 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your app fails in ways that feel cryptic, wipe user input, or leave people stuck without a clear next step.
Who is it for?
Solo builders defining signup, payments, settings, or data-entry flows where trust and completion rate hinge on how errors feel.
Skip if: Teams that only need backend exception logging or SRE runbooks with no user-facing copy or interaction design.
When should I use this skill?
You are designing or refining user-facing failure, validation, or empty states in a product UI.
What do I get? / Deliverables
You get a structured error UX spec—validation placement, copy patterns, and recovery flows—ready to implement in UI and test before release.
- Error-state UX rules per surface
- Message templates (what / why / next action)
- Recovery behavior checklist (retry, preserve input, undo)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because error states are designed alongside UI flows before you ship. Frontend is where inline validation, empty states, and error copy live in the product surface.
Where it fits
Spec per-field inline errors and a submit summary before coding a multi-step onboarding form.
Align QA scenarios with user-visible error copy and retry behavior on checkout and auth flows.
Rewrite top ticket-driving errors using the what-why-next message format.
Prototype landing signup with prevention defaults so fake-door tests measure intent, not confusion.
How it compares
Use for product-facing error experience design, not as a substitute for automated test suites or security incident playbooks.
Common Questions / FAQ
Who is error-handling-ux for?
Solo and indie builders designing web or mobile products who want error flows that match how users think, not how servers log.
When should I use error-handling-ux?
During Build when wireframing forms and critical paths; during Ship when reviewing launch flows and flaky network cases; during Grow when support feedback shows confusing failure messages.
Is error-handling-ux safe to install?
It is design guidance only—review the Security Audits panel on this page before installing any skill from the repo, and do not treat copy suggestions as compliance advice.
SKILL.md
READMESKILL.md - Error Handling Ux
# 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