1 Empty State Fundamentals
1.1 Definition and purpose
An empty state is a user interface moment displayed when there is no meaningful content available to present. Rather than showing a blank surface or an unhelpful spinner, it communicates the current situation (for example, “nothing has been added yet” or “no matching results”) and steers the user toward an appropriate next step. The primary purpose is to reduce confusion, set expectations, and maintain progress toward a goal.
1.2 Where empty states appear in products
Empty states occur across many interface areas, including content feeds, dashboards, lists, collections, search results pages, settings screens, and onboarding flows. They may also appear when a user’s data has not yet been created, imported, or granted by system permissions, as well as when filtering yields no matches.
1.3 Common empty-state triggers
Common triggers include first-run experiences for new users, newly created workspaces with no entries, filters or queries returning zero items, users navigating to features they have not configured, and situations where optional data sources are disabled. Triggers can be deterministic (e.g., a new account) or dynamic (e.g., a search query with no results).
2 Types of Empty States
2.1 New-user / first-run empty states
First-run empty states appear before a user has generated data or completed setup. They often include onboarding prompts, suggested actions, and guidance that helps users understand what can be done in the product. Because users have not yet formed mental models, messaging tends to be more explanatory than in other empty-state types.
2.2 No-data empty states
No-data empty states indicate that a feature is functioning, but there are simply no items to show. Examples include an empty project list, an unpopulated library, or a newly created collection with no entries. Typically, the content area is stable and only the data list is absent.
2.3 Search and filter empty states
When a search query or filter combination produces no results, the UI presents an empty state that contextualizes the query and offers remediation. Useful elements include suggestions for alternative terms, guidance to broaden filters, and shortcuts to common searches or categories.
2.4 Error-like empty states (non-error context)
Some empty states resemble errors but are not failures. For instance, a “No results” view can look like an error screen if it lacks explanation, even though the system is working correctly. These states benefit from careful labeling that distinguishes “no matching content” from “something went wrong.”
2.5 Loading-adjacent empty states vs true empty states
A key distinction is between true empty states and those adjacent to loading. A true empty state reflects completed logic with zero items, while a loading-adjacent state appears while data is being fetched. Blending these concepts can mislead users; clear state transitions help users understand whether the system is waiting, has failed, or genuinely has nothing to show.
3 UX Writing and Messaging
3.1 Tone, clarity, and reading level
Effective messaging is direct, readable, and aligned with the product’s voice. It should avoid jargon, match the expected reading level of the target audience, and remain comprehensible at a glance. Clarity matters most when the user is likely frustrated or uncertain.
3.2 Microcopy patterns (title, description, hint)
Many empty states use a small set of text elements:
- A title that names the situation (e.g., “No items yet” or “Nothing matched your search”).
- A description that provides context (what the user can do, or what the system checked).
- A hint that suggests a next move, such as trying a different query or completing setup.
These elements can be condensed for small screens while retaining the same logical structure.
3.3 Avoiding blame and ambiguity
Empty-state copy should not imply user fault unless there is a specific, user-controlled cause. Ambiguity can be reduced by referencing the relevant action or input (“Your filters removed all results” or “You haven’t added any projects yet”). When an issue is caused by configuration or permissions, phrasing should emphasize resolution steps rather than judgment.
3.4 Internationalization and localization considerations
Localization affects length, grammar, and reading order, so empty-state layouts should be flexible. Translators may require different phrasing for titles versus descriptions, and some languages demand gender, pluralization rules, or case changes. Character limits and text truncation should be tested to prevent key guidance from disappearing.
4 Visual Design and Layout
4.1 Illustration and icon choices
Lightweight illustration or icons can convey meaning quickly, particularly in first-run and no-data contexts. The chosen visual should correspond to the concept of emptiness (such as an open container, a blank page, or a magnifying glass with no matches) without becoming distracting or suggesting an error. Consistency with the brand style is important.
4.2 Spacing, hierarchy, and alignment
Layout should prioritize readability and visual balance. Common approaches include centering a message block, using ample whitespace to signal intentional absence, and applying typographic hierarchy so the title stands out from the description. Alignment to the product grid helps the empty state feel integrated rather than appended.
4.3 Accessibility considerations (contrast, alt text)
Accessible empty states use sufficient contrast for text and ensure that icons or illustrations are not the only source of information. If a decorative graphic is present, it should be marked appropriately; if meaningful, it requires alternative text or a text-equivalent. Focus outlines and keyboard navigation should work normally, especially when a call to action is present.
4.4 Animation and motion guidelines
Motion can clarify transitions (for example, a gentle layout entrance when results become empty) but should not distract from the message. If animations are used, they should be subtle, respect user preferences for reduced motion, and avoid reflow that destabilizes the interface.
5 Calls to Action (CTAs)
5.1 Choosing the primary action
A primary call to action should match the user’s likely objective in context. In a cart, the primary action might be “Add items” or “Browse products.” In an empty project list, it might be “Create your first project.” The CTA should be visually prominent and directly connected to the empty state’s meaning.
5.2 Secondary actions and navigation options
Secondary actions provide alternate paths without overwhelming the user. Examples include links to templates, documentation, or browsing options. Secondary navigation is especially helpful when there are multiple ways to proceed, such as importing data versus creating from scratch.
5.3 “Try again” vs “create” vs “learn more”
Different CTA types serve different causes:
- “Try again” fits situations where the user’s input may be incorrect or changeable (e.g., search).
- “Create” suits first-run or no-data contexts where new content can be generated.
- “Learn more” can be appropriate when the user needs conceptual guidance rather than immediate action.
Selecting among them depends on whether the user can quickly correct the situation or requires explanation.
5.4 When to use links, buttons, or guided flows
Buttons are suitable for prominent actions with a clear outcome, while links may work well for supportive navigation. Guided flows, such as setup wizards or multi-step onboarding, are appropriate when a single tap is insufficient. The choice should reflect effort level, frequency of use, and how confident the system is about the user’s next best step.
6 Behavioral Logic and Personalization
6.1 Tailoring messages to user context
Empty-state content improves when it reflects what the system knows about the user’s situation. Contextual cues can include the current filter settings, recent actions, or whether setup steps are incomplete. Personalization should remain transparent and avoid suggesting capabilities the user does not have.
6.2 Segmenting by device and role
Different platforms and user roles can require distinct empty-state patterns. Mobile interfaces may need shorter copy and larger touch targets, while desktop can accommodate more detailed guidance. Roles such as admin versus member can also change the recommended CTA, particularly when permissions limit actions.
6.3 Respecting user permissions and capabilities
When access is restricted, the empty state should communicate the reason in neutral terms and guide toward resolution where possible (for example, requesting access or switching to allowed features). Copy should distinguish between “no items exist” and “items exist but you cannot view them,” because these states lead to different next actions.
6.4 Empty states in multi-step journeys
In multi-step journeys, empty states should integrate with progress indicators and preserve navigation expectations. If the user is moving through a setup sequence, empty views should reinforce what step they are on, what is missing, and what happens after they complete the relevant action. Avoiding full resets and maintaining continuity reduces friction.
7 Data and System Integration
7.1 Distinguishing empty vs loading vs failure
A robust system classifies states so the UI can render the correct view. Empty state indicates successful completion of the data query with zero results. Loading represents ongoing retrieval. Failure represents an inability to fetch or compute results. Misclassification can lead to misplaced CTAs or incorrect user assumptions.
7.2 Edge cases (partial data, pagination)
Edge cases include partially available data sources, paginated lists where only later pages are empty, and asynchronous updates where content appears shortly after the empty view renders. Systems should decide whether to briefly show an empty state or hold the UI until the response is confirmed. For pagination, the UI might show “no more results” at the end rather than treating the list as globally empty.
7.3 Consistent behavior across screens
Consistency reduces cognitive load. The same empty-state concepts should behave similarly across screens—consistent placement of titles, consistent button styling, and consistent transitions when data appears. A shared understanding of what “empty” means helps users trust the interface and predict outcomes.
8 Testing and Evaluation
8.1 Usability testing for comprehension
Usability tests can evaluate whether users interpret the empty state correctly and know what to do next. Researchers often look for confusion points such as users attempting to refresh unnecessarily, asking support questions, or failing to notice the CTA due to poor hierarchy.
8.2 Metrics (engagement, conversions, task completion)
Quantitative evaluation may include engagement rates with the CTA, conversion into the intended action (e.g., creating the first item), and task completion time. Comparing these metrics to control experiences helps determine whether the empty state improves outcomes or merely changes visual impressions.
8.3 A/B testing message and CTA variants
A/B testing can validate different messaging structures, such as shorter titles versus longer descriptions, or “create” versus “browse.” Experiments should be designed to isolate variables like CTA label, placement, and copy tone. Results should be interpreted with attention to segment differences, since users at first-run may respond differently than returning users.
8.4 Monitoring user drop-off and support tickets
Monitoring supports long-term improvement. If users abandon after viewing empty states, it suggests missing guidance or an incorrect CTA. Support ticket trends can reveal whether the copy clarifies the situation or whether users assume the product is broken. Tracking these signals helps teams iterate.
9 Design Systems for Empty States
9.1 Reusable components and templates
Design systems benefit from reusable empty-state templates that standardize spacing, typography, and button styles. Templates can cover common variants such as “no data yet,” “no results,” and “needs setup,” allowing product teams to implement consistent experiences without redesigning from scratch.
9.2 Styling rules and content guidelines
Rules typically include minimum contrast requirements, icon sizing, text truncation behavior, and safe area constraints across device sizes. Content guidelines cover what to include in the title and description, how to avoid blame, and how to align the CTA with the user’s context. A well-documented system reduces variation and improves maintainability.
9.3 Documentation and governance
Governance ensures empty-state patterns evolve coherently. Documentation often includes example content, do/don’t lists, and guidance for localization. Review processes can verify that teams apply templates correctly and that new variants follow established principles.
10 Examples and Patterns
10.1 E-commerce: empty cart
An e-commerce empty cart typically shows a clear statement that no items are present and offers immediate browsing options. A common pattern is a primary button such as “Start shopping,” supported by categories or recommended products. The empty cart should not imply payment issues; it communicates absence of chosen goods.
10.2 Productivity: empty project list
For productivity tools, the empty project list often functions as a launchpad. The empty view may include a “Create project” CTA, optional templates, and examples of common project types. When projects are created via forms or wizards, the empty state can link directly into that flow to minimize extra steps.
10.3 Social: no posts yet
A social feed with no posts yet benefits from an inviting message and a clear path to generate content. CTAs might include “Write your first post” or “Follow accounts,” depending on whether users must create or discover content. Lightweight humor can be used carefully to make the wait feel less like a problem.
10.4 Settings: first configuration
Empty settings screens should reflect what has not been configured and how to complete setup. A first configuration empty state often includes a small checklist-like description or guided entry points for key preferences. The goal is to turn uncertainty into a sequence of straightforward actions.
10.5 Internet culture-friendly variants (light humor and tasteful memes)
Some products use gentle, non-offensive humor or tasteful meme-like visuals to reduce tension around empty screens. Effective variants keep the message respectful, align the joke with the user’s situation (rather than blaming the user), and ensure the CTA remains primary. Humor should never interfere with comprehension, accessibility, or clarity for international audiences.