For a long time, the industry consensus on empty state UX design has been dominated by the “delight” mandate. The narrative was simple: a blank screen is a dead end, and to prevent user churn, we must transform that void into a brand moment. This led to the proliferation of the “Empty State Starter Pack”—a centered, whimsical illustration, a playful headline like “Oops, nothing here!”, and a primary CTA to get the user started.
This approach originated largely in consumer-facing apps where the stakes are low and the primary goal is rapid onboarding. In those contexts, a little personality can bridge the gap between a first-time user and their first “aha!” moment. But as products have grown in complexity—and as we’ve moved toward high-trust environments like fintech, healthcare, and complex operational tools—this delight-first paradigm is starting to crack.
When a user is managing a million-dollar portfolio or checking for critical medical alerts, a “cute” illustration isn’t just unnecessary; it’s a cognitive distraction. In high-stakes contexts, the void isn’t an opportunity for branding—it’s a request for situational clarity. We are seeing a growing tension between the desire for personality and the requirement for restraint, suggesting that it’s time to move away from a one-size-fits-all “delight” model toward a context-aware architectural approach.
Empty State UX Design: Myth 1 — Delight universally drives engagement
The prevailing theory is that adding “personality” to an empty state reduces friction and makes the product feel more human. While this holds true for a social media app or a casual task tracker, the evidence suggests a diminishing return—and even a negative impact—in professional or high-stakes environments. For a “serious brand,” the most valuable thing an empty state can provide is not delight, but certainty.
In sectors like travel technology or fintech, an empty state is often a trust signal. If a user navigates to their “Pending Transactions” and sees a whimsical drawing of a sleeping cat, the immediate emotional response isn’t “How cute,” but “Is my data missing?” or “Is the system failing to load my money?” In these moments, illustration-heavy states increase cognitive load by forcing the user to filter out decorative noise to find the actual status of their account.
The risk is compounded when the tone of the microcopy misfires. Humorous copy that works in a consumer app can feel dismissive or unprofessional when the user is in a state of anxiety. When the goal is rapid orientation, the most effective experience is actually the one that confirms the system is working exactly as intended, with the least amount of friction possible. In these cases, restraint is the highest form of UX polish.
Myth 2: Empty states and error states are interchangeable patterns
One of the most persistent failures in modern design systems is the conflation of “no data” (an empty state) and “failed to load data” (an error state). Because both result in a blank screen, designers frequently use the same component for both, varying only the text. This structural conflation creates distinct user harms.
An empty state is a statement of fact: “There is currently nothing here.” The required user behavior is typically proactive—creating the first item or adjusting a filter. An error state is a statement of failure: “Something went wrong while trying to find your things.” The required behavior here is reactive—retrying the request, checking the connection, or contacting support.
When these two are merged into a single “Blank State” component, the guidance becomes muddy. If a user sees a generic “Nothing here” message during a server timeout, they may spend minutes trying to “create” data that already exists, unaware that the system is simply broken. As noted by practitioners in the Kompassify guide, the distinction between action guidance (empty) and reassurance/retry (error) is fundamental to the user’s mental model of the system’s health.
This conflation also creates significant empty state accessibility hurdles. Screen reader users rely on clear semantic markers to understand why a page is blank. If the markup for an empty state and an error state is identical, the assistive technology may fail to communicate the urgency or the nature of the failure, leaving the user in a state of ambiguity. A “no results” state should be announced as a status update, whereas a “system error” should be announced as an alert. Treating them as the same UI pattern is a failure of information architecture, as emphasized in the Toptal analysis of empty state UX.
Myth 3: Personality-driven microcopy scales across brand contexts
Many design systems treat “Voice and Tone” as a global layer that sits on top of components. They define a brand voice—say, “Friendly and Energetic”—and apply it across all empty states. However, tone is not a global constant; it is a variable that must change based on the user’s intent and the stakes of the interaction.
The Emplifi Soul Design System highlights that empty states are functional components that should inform the user about what data would be displayed. This suggests that the copy’s primary job is architectural, not emotional. When we prioritize “personality” over “function,” we often sacrifice the precision required for professional tools.
Consider the difference between an exploratory state (searching for a new hotel) and a task-critical state (checking a flight itinerary). In the former, a playful “No matches found—try widening your search!” is appropriate. In the latter, a stark “No itineraries found for these dates” is more effective. The latter provides a definitive answer without the fluff, which is exactly what a user in a rush needs.
The “mastery level” of an empty state, as explored by Pencil & Paper, suggests a hierarchy where “not broken” is the baseline, “informed” is the middle, and “delight” is the ceiling. The industry error has been treating the ceiling as the baseline. For most professional products, the “informed” level—where the user understands exactly why the screen is empty and how to fix it—is the optimal state. Pushing for “delight” often pushes the design past the point of utility into the realm of decoration.
A context-aware model: Four empty state archetypes
To move beyond the delight-versus-functional binary, we should treat empty states as distinct architectural archetypes. Each requires a different “design contract” regarding information density, tone, and visual weight.
1. The First-Use Onboarding Empty
This is the only state where the “delight” paradigm truly thrives. The user is curious, the stakes are low, and the goal is activation. In this context, we can use a higher tolerance for illustrations that mimic the intended action to provide a visual metaphor. The copy should be encouraging and instructional, driving the user toward a single, prominent “Get Started” or “Create First [Item]” CTA.
2. The Recurring Operational Empty
These occur in established workflows—for example, an empty “Notifications” tab or a cleared “Shopping Cart.” The user is already familiar with the product and doesn’t need an onboarding lesson. Visuals should be minimal to non-existent, as a small icon or simple whitespace is usually sufficient. Copy remains brief and factual (e.g., “You’re all caught up”), with actions kept proximate to the main navigation.
3. The Search/Filter Null Result
This is a high-friction state where the user expected to find something and didn’t. Any hint of “playfulness” here can be perceived as mocking the user’s failed attempt. Restrained visuals are key; avoid “Oops!” imagery in favor of cues that suggest “searching.” Copy must be context-preserving—using “No results for ‘[Query]'” instead of a generic “No results”—to confirm the system processed the request. The primary action should be to suggest alternative queries or clear filters.
4. The Error-Induced Empty
As established, this is not a true empty state, but it often looks like one. The primary goal is the preservation of trust. Instead of brand illustrations, use system-level alert icons, such as a warning triangle. Copy must explicitly acknowledge the failure (e.g., “We couldn’t load your data right now”) without humor. The only priority is a “Retry” button and a link to system status or support.
Implementation guardrails for design systems
Translating this model into a design system requires moving away from a generic EmptyState component and toward a more typed API. If you are building or maintaining a library, consider the following constraints to prevent “delight creep.”
Component API Design: Instead of a single component with optional props, create variants based on the archetypes above. For example, EmptyState variant="onboarding" would allow for large illustrations, while EmptyState variant="null-result" would restrict illustration size and enforce the inclusion of the user’s search query in the copy.
Content Design Tokens: Stop using a global “Voice” guideline for empty states. Implement tone tokens. A tone="neutral" token for operational empties prevents designers from adding unnecessary adjectives or puns to a simple “No data” message. This aligns with broader efforts to stop design system drift by codifying constraints at the token level.
The QA Boundary Test: During the hand-off and testing phase, explicitly test the boundary between the empty state and the error state. If the UI for “No results found” looks identical to “Server 500 Error,” the design has failed. This is closely related to the challenge of designing trustworthy interfaces; clarity and predictability are the only ways to maintain user trust when the system isn’t delivering the expected content. For further guidance on these distinctions, the UX Writing Hub examples provide a strong baseline for separating functional clarity from brand flair.
Ultimately, the goal of empty state UX design is not to fill a void with art, but to provide a bridge to the next action. When we stop treating blank screens as branding opportunities and start treating them as information architecture decisions, we create products that feel professional, accessible, and—most importantly—reliable.
