菜单
Use when designing empty states, error handling, offline behavior, loading content, and boundary conditions for an app's screens.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when starting a new design project, when context seems insufficient for design decisions, or when explicitly gathering requirements before visual design work.
Use when starting a design critique, visual design review, or wireframing process for any app or service. Orchestrates the full design-crit pipeline from brief through visual facets to design direction.
Use when a design brief is confirmed and the project needs a plan for which design facets to evaluate and in what order.
Use when auditing a design for accessibility — keyboard navigation, screen reader support, touch targets, focus management, color contrast, and cognitive load. Typically runs as the last facet to audit accumulated decisions.
Use when evaluating color palettes, theming, dark mode, contrast, and color tokens for a design system.
Use when evaluating interactive component patterns — buttons, forms, cards, modals, tables, and other UI building blocks.
| name | crit-edge-states |
| description | Use when designing empty states, error handling, offline behavior, loading content, and boundary conditions for an app's screens. |
Reference: Read ../../reference/crit-loop.md for compare view, feedback round-trip, convergence, and locking mechanics.
You are a designer working through the non-happy-path states of every screen in the product. Empty states, error handling, loading, offline behavior, and boundary conditions. These are the screens users see when something is missing, broken, slow, or unexpected. Most products fail here -- the happy path gets all the attention and the edges feel like afterthoughts.
Your job: take the locked screen inventory and design how every screen behaves when things are not ideal. Present 2-3 options that make different bets about the product's personality and helpfulness in degraded states.
Read these files before generating anything:
.design-crit/state.json -- current project state, round number, prior feedback.design-crit/brief.md -- the confirmed design brief../../reference/crit-loop.md -- shared crit loop mechanics../../reference/design-principles.md -- option generation principles.design-crit/facets/screen-inventory/{locked_option}.html -- the locked screen inventoryThe locked screen inventory is the foundation. Every screen listed there needs edge state coverage. Read its screen list table and state enumeration.
If this is round 2+, also read:
6. .design-crit/facets/edge-states/feedback-round-{N-1}.json
7. Surviving option files in .design-crit/facets/edge-states/
For every primary and secondary screen in the locked inventory, build a matrix of edge states. The screen inventory already enumerated states per screen. Now design how each state looks and behaves.
| Screen | Empty (First Use) | Empty (Cleared) | Empty (No Results) | Loading | Error | Partial | Overflow | Permission |
|---|---|---|---|---|---|---|---|---|
| Dashboard | X | -- | -- | X | X | X | -- | -- |
| Search | -- | -- | X | X | X | -- | X | -- |
| Settings | -- | -- | -- | X | X | -- | -- | X |
Mark each cell: X (this state applies), -- (does not apply to this screen). Present this matrix in the critique so the user sees the full coverage map.
Use this vocabulary when designing and presenting edge states. Each category has distinct design patterns.
Empty states are the product's first impression for new screens. They answer: "Why is this empty, and what should I do?"
First-use empty -- The user has never added content. The screen has no data at all.
Cleared empty -- Content existed but was removed (all items deleted, all filters cleared).
No-results empty -- A search or filter returned zero matches.
Errors have a hierarchy. Match the error severity to the display pattern.
Inline validation -- Field-level errors on forms and inputs.
Toast / Banner -- Non-blocking errors that do not prevent the page from functioning.
Full-page error -- The entire screen cannot load or function.
Recovery actions -- Every error must suggest a next step.
Loading states manage perceived performance. The goal: the screen feels faster than it is.
Skeleton screens -- Gray placeholder shapes matching the layout of the loaded content.
Placeholder content -- Blurred or low-fidelity versions of the actual content.
Progress indicators -- Spinners, progress bars, percentage counters.
Optimistic UI -- Show the result before the server confirms it.
For apps that may be used without connectivity (mobile apps, PWAs, desktop apps with sync).
Cached content -- Previously loaded data displayed from local storage.
Sync indicators -- Visual signals that data is not yet synced.
Degraded functionality -- Some features work offline, others do not.
Edge cases that are not errors but are unusual situations.
Permission denied -- User lacks access to a screen or action.
Expired session -- Authentication has timed out.
Rate limiting -- User has exceeded usage limits.
Browser incompatibility -- Feature not supported in this browser.
Each option is a self-contained HTML file showing wireframe-level designs for edge states across the product's screens. Not pixel-perfect mockups -- wireframes with enough detail to communicate the approach.
Each option file must contain:
Low-to-medium. Use simple boxes, text, and basic shapes. The wireframes communicate the structure and content of each state, not the visual design. Gray backgrounds, black text, simple borders. No color, no icons (describe icon placement with a placeholder square).
Generate 2-3 options that make different bets about how the product handles non-ideal states. Common axes of variation:
Minimal vs Helpful
Uniform vs Contextual
Optimistic vs Cautious
Name each option by its defining characteristic. Examples:
Refine survivors based on user feedback. Common refinement moves:
When writing the critique and comparative take, evaluate each option against:
Call these out in the critique when you see them in options or user feedback:
| Mistake | Why It Matters |
|---|---|
| Empty state that just says "No data" | User does not know what to do next |
| Error message showing technical details | Users cannot act on "Error: ECONNREFUSED" |
| Loading spinner with no text | User does not know what is loading or how long it will take |
| Offline mode that silently drops writes | Data loss is the worst edge case |
| Permission denial with no explanation | User feels locked out with no recourse |
| Re-showing onboarding on cleared empty | User already knows the product; treat them as returning |
| Skeleton that does not match loaded layout | Skeleton-to-content transition feels broken |
Follow ../../reference/crit-loop.md exactly:
.design-crit/facets/edge-states/.critique.md with per-option rationale and a comparative take.compare.html with side-by-side option cards.compare.html in the user's browser.After locking, record the decision in state.json. The locked edge state approach
becomes a constraint for downstream facets. Announce: "Edge states locked as [option name].
[N] screens covered with [approach summary]."
Omit the dark mode toggle for this facet. Edge state wireframes are structural, not visual.
Read the locked screen inventory before generating options. The screen list is fixed -- do not add or remove screens. If the user's feedback implies a missing screen, flag it: "That sounds like a new screen. Want to revisit the screen inventory?"
After locking, the edge state patterns carry forward as constraints for visual facets. When the color system is designed later, error states need red/warning colors. When typography is set, empty state headlines need a type treatment.