Design or improve empty states so blank areas become useful product moments that teach, orient, and move users toward the next step.
This skill is specifically for zero-data and no-content surfaces. Use onboard for broader activation strategy, aha moments, first-run education, tours, and adoption planning.
MANDATORY PREPARATION
Users start this workflow with /empty-state. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: the value users should reach from this surface.
Assess the Empty State
Understand what kind of absence you are dealing with:
State type:
- First use / never created content
- No results from search or filters
- Previously cleared content
- Permission/access restriction
- Error while loading content inside an existing surface
- Route-level or full-page failure such as 401, 403, 404, 429, 500, or 503
User question:
- What is this area for?
- Why should I care?
- What should I do next?
Dead chrome audit:
- Are tabs, filters, sidebars, sort controls, or empty toolbars visible even though they do nothing yet?
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
CRITICAL: An empty state is often the user's first impression of a feature. Treat it like a real screen, not a fallback.
Plan the Empty State
Consult the empty-state patterns for the main empty-state types, full-page error variants, CTA rules, and chrome-reduction guidance.
Design the state around this structure:
- What this area is for
- Why it’s useful
- Primary CTA
- Optional template/example
- What inactive chrome should disappear for now
Build Better Empty States
First-Use States
- Explain what will appear here
- Frame the value clearly
- Offer the clearest starting action
- Consider a starter template or sample data shortcut
No-Results States
- Explain that the current query/filter produced nothing
- Offer a recovery action like clearing filters or broadening search
- Preserve enough context so users understand what happened
Cleared-Content States
- Use a lighter tone than first use
- Offer a simple path back to creation
- Add undo or recovery when appropriate
Permission States
- Explain the access limitation plainly
- Say who can grant access or what role is needed
- Offer a request-access path when possible
Error States
- State what failed in simple language
- Match the recovery path to the failure type: retry for transient failures, sign-in for expired sessions, request access for 403, home/search for 404, and status/support for broader service failures
- Add support/help path when needed
Reduce Dead Chrome
- Hide tabs, filters, sidebars, or sort controls that provide no value before content exists
- Keep the screen focused on the message and the next step
Use Visual Interest Carefully
- Illustration or icon is optional, but helpful when it supports comprehension or attention
- The CTA should still be stronger than the decoration
NEVER:
- Leave users staring at “No items” with no next step
- Keep inactive controls visible just because the full UI normally has them
- Let the illustration overpower the message and CTA
- Use the same empty-state tone for first use, permissions, and errors
- Use a generic catch-all error page when a more specific recovery path is available
Verify Empty-State Quality
- Clarity: Does the state explain what belongs here?
- Value framing: Does it explain why the user should care?
- Next step: Is the CTA obvious?
- Chrome cleanup: Is inactive UI removed?
- Appropriate tone: Does the state match first use / no results / permission / error?
Remember: The best empty states feel like helpful product design, not like the app ran out of things to say.
1---
2name: empty-state
3description: Design focused empty states for zero-data, no-results, permission, and error situations with clear value framing, strong CTAs, and less dead chrome. Use when the user mentions blank pages, zero-data screens, no results, permission states, or dead controls—not broader onboarding strategy.
4metadata:
5 argument-hint: "[target]"
6---
7
8Design or improve empty states so blank areas become useful product moments that teach, orient, and move users toward the next step.
9
10This skill is specifically for zero-data and no-content surfaces. Use `onboard` for broader activation strategy, aha moments, first-run education, tours, and adoption planning.
11
12## MANDATORY PREPARATION
13
14Users start this workflow with `/empty-state`. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: the value users should reach from this surface.
15
16---
17
18## Assess the Empty State
19
20Understand what kind of absence you are dealing with:
21
221. **State type**:
23 - First use / never created content
24 - No results from search or filters
25 - Previously cleared content
26 - Permission/access restriction
27 - Error while loading content inside an existing surface
28 - Route-level or full-page failure such as 401, 403, 404, 429, 500, or 503
29
302. **User question**:
31 - What is this area for?
32 - Why should I care?
33 - What should I do next?
34
353. **Dead chrome audit**:
36 - Are tabs, filters, sidebars, sort controls, or empty toolbars visible even though they do nothing yet?
37
38If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
39
40**CRITICAL**: An empty state is often the user's first impression of a feature. Treat it like a real screen, not a fallback.
41
42## Plan the Empty State
43
44Consult the [empty-state patterns](../frontend-design/reference/empty-state-patterns.md) for the main empty-state types, full-page error variants, CTA rules, and chrome-reduction guidance.
45
46Design the state around this structure:
47- **What this area is for**
48- **Why it’s useful**
49- **Primary CTA**
50- **Optional template/example**
51- **What inactive chrome should disappear for now**
52
53## Build Better Empty States
54
55### First-Use States
56- Explain what will appear here
57- Frame the value clearly
58- Offer the clearest starting action
59- Consider a starter template or sample data shortcut
60
61### No-Results States
62- Explain that the current query/filter produced nothing
63- Offer a recovery action like clearing filters or broadening search
64- Preserve enough context so users understand what happened
65
66### Cleared-Content States
67- Use a lighter tone than first use
68- Offer a simple path back to creation
69- Add undo or recovery when appropriate
70
71### Permission States
72- Explain the access limitation plainly
73- Say who can grant access or what role is needed
74- Offer a request-access path when possible
75
76### Error States
77- State what failed in simple language
78- Match the recovery path to the failure type: retry for transient failures, sign-in for expired sessions, request access for 403, home/search for 404, and status/support for broader service failures
79- Add support/help path when needed
80
81### Reduce Dead Chrome
82- Hide tabs, filters, sidebars, or sort controls that provide no value before content exists
83- Keep the screen focused on the message and the next step
84
85### Use Visual Interest Carefully
86- Illustration or icon is optional, but helpful when it supports comprehension or attention
87- The CTA should still be stronger than the decoration
88
89**NEVER**:
90- Leave users staring at “No items” with no next step
91- Keep inactive controls visible just because the full UI normally has them
92- Let the illustration overpower the message and CTA
93- Use the same empty-state tone for first use, permissions, and errors
94- Use a generic catch-all error page when a more specific recovery path is available
95
96## Verify Empty-State Quality
97
98- **Clarity**: Does the state explain what belongs here?
99- **Value framing**: Does it explain why the user should care?
100- **Next step**: Is the CTA obvious?
101- **Chrome cleanup**: Is inactive UI removed?
102- **Appropriate tone**: Does the state match first use / no results / permission / error?
103
104Remember: The best empty states feel like helpful product design, not like the app ran out of things to say.