102.3K+Download
Skip to the usage guide
Error Handling UXby Owl-Listener

Error Handling UX Skill.

Make failures explain what happened and give people a way forward without losing their work.

  • UX
  • Design Guidance
Download OpenDesignView Usage Guide
Source Review · Error Handling UXSKILL.md
Task UX Produces • A cross-flow error-state inventory • Context-specific messages and placements • Recovery, retry, undo, and data-preservation requirements Before You Start An agent that can read the affected flows, known failure cases and the recovery actions your product actually supports.
Editorial summary · source reviewed 2026-10-07 · not a generated example

01 What It Does

Error Handling UX: Design Recovery Across Flows

Plan how errors are prevented, explained and recovered from across product flows.

Source-based workflowNot an execution benchmark

The Working Approach

Error Handling UX spans multiple product flows. It organizes the problem into prevention, detection, communication, and recovery rather than treating every failure as a message-writing exercise.

The source distinguishes form, page, network, empty-result, and permission contexts. Preserved input, retry, alternative routes, and undo are part of the design. A precise message helps only if the proposed recovery is genuinely available in the product.

Expected Deliverables

  • A cross-flow error-state inventory
  • Context-specific messages and placements
  • Recovery, retry, undo, and data-preservation requirements
See the Example Brief

From Brief to Review

  1. 01
    Map Failure Contexts

    Identify preventable mistakes, transient failures, permission limits, and other relevant states.

  2. 02
    Write Useful Messages

    Explain the event, helpful context, and a real next action without blaming the user.

  3. 03
    Specify Recovery

    Preserve work and define retry, alternative routes, or undo according to the failure.

02 When to Use It

When to Use It

Use it when failures across several flows need consistent messages, recovery actions and protection against lost work.

A Good Fit

  • Fragmented Failure BehaviorBring consistency to errors across several product flows.
  • Lost-Work ProblemsDefine how input and context survive failed actions.

Limits to Check

  • Not Backend ReliabilityThe design does not implement network recovery or guarantee service availability.
  • Not Just Form ValidationA single form's field-level validation belongs to the form-design task.

Bring These Inputs

  • Failure InventoryProvide known errors and their actual causes.
  • Recovery CapabilitiesIdentify real retries, undo, and alternative channels.
  • User ContextState what data or progress must survive each failure.

03 Decisions That Matter

Decisions That Matter

  1. Messages and Actions Agree

    An error should not offer a recovery the system cannot perform.

  2. Failure Does Not Erase Progress

    Preserving context makes recovery less costly for the user.

04 Try a Focused Brief

Try a Focused Brief

The example brief below has not been tested. Check the skill’s setup before using it.

Review the Setup

Load this task's SKILL.md from the designer-skills repository in your agent's supported skill location. No universal installer command is established by the entry file.

Upstream Source File
https://github.com/Owl-Listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/interaction-design/skills/error-handling-ux/SKILL.md

Supply the actual failure cases and available recovery actions. This workflow specifies the experience; it does not implement backend recovery.

Start With One Deliverable

Adapt the scope, source material and constraints in this brief before running the skill.

Example Brief
Use error-handling-ux to review our upload, save, and permission failures. For each, specify prevention, message placement, preserved data, and a real recovery action. Distinguish retryable network failures from access denial, and do not invent backend capabilities.

Inspect the Result

Check the actual output against these observable criteria.

  • Messages identify a useful next action.
  • User input survives appropriate failure paths.
  • Retry and permission recovery are not conflated.

OpenDesign provides a local design workspace for coding agents. This listing does not mean the skill is bundled or that its external tools, credentials and software dependencies are included.

Download OpenDesignRead the Quickstart

05 Source and License

Source and License

This page describes the pinned source revision linked below. Upstream behavior and requirements can change.

Source Owner
Owl-Listener
Repository
Owl-Listener/designer-skills
Skill File
interaction-design/skills/error-handling-ux/SKILL.md
License
MIT
Reviewed Snapshot
2026-10-07 · 9a6930cf84a8
Editorial Source Summary
Plan how errors are prevented, explained and recovered from across product flows.

Original summary by OpenDesign, based on the linked source. Repository stars are a dated popularity signal, not skill usage or a quality score.

06 Questions Before You Start

Questions Before You Start

Should every error use a toast?

No. The source ties placement to context, including inline, full-page, banner, and permission states.

Can retry solve an access error?

Not automatically. Recovery must match the actual permission requirement.

Does this implement auto-save?

No. It identifies design requirements; implementation and testing are separate.

OpenDesign

Make Room for the Next Design Iteration.

Keep your brief, source material and design work together in a local workspace. Check the skill’s own setup before adding it to your workflow.

Download OpenDesignBrowse Design Skills
Upstream Source File
https://github.com/Owl-Listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/interaction-design/skills/error-handling-ux/SKILL.md