Empty State / Error State / Loading State

These are three critical non-happy-path UI states. Empty states appear when there is no data to show. Error states handle failures. Loading states indicate that content is being fetched. Designing all three determines how resilient a product feels.

Category: Design (also: UX)

Author: Atomic Glue Editorial Team

## Definition

Empty states, error states, and loading states are the three most common non-ideal states in any interface. They are often called the UX unholy trinity because they receive the least design attention yet have the most impact on user trust. Empty states appear when a list has no items, a search returns no results, or a user first opens an app with no data. Error states occur when something goes wrong: a network failure, a form validation failure, a server error, or a permission issue. Loading states bridge the gap between an action and its result, using spinners, skeletons, progress bars, or shimmer placeholders. Getting these states right separates products that feel solid and trustworthy from products that feel fragile and frustrating.

## Empty States Are Opportunities

An empty state is not a blank area. It is a chance to guide the user. Good empty states answer three questions: What happened? Why is it empty? What should the user do next? They include an illustration or icon for context, a clear message explaining the emptiness, and a call to action directing the user to populate the content. For first-time users, the empty state should show them the value of the product and how to get started. For search with no results, suggest alternatives, correct spelling, or offer filters.

## Error States Must Be Helpful, Not Punishing

The worst error state is a generic red box saying "An error occurred." The user is already frustrated. Now they have no idea what went wrong or how to fix it. Good error states identify the problem specifically, explain it in human language, and offer a clear path to resolution. Network errors should offer a retry button. Form validation errors should highlight the specific field, explain the requirement, and let the user correct it without losing data already entered. 404 pages should guide users back to useful content rather than dead-ending them.

## Loading States Set Expectations

Loading states manage the user's perception of time. Skeleton screens (gray placeholder shapes that mirror the content layout) feel faster than spinners because they set expectations about what will appear. Progress bars work for determinate durations. Spinners work for indeterminate durations but should be avoided if the wait exceeds 10 seconds (use a progress bar or message instead). Never leave the user staring at a frozen screen. If the loading will take more than 2 seconds, show progress. If more than 5 seconds, show a message explaining the delay. If more than 10 seconds, offer an alternative or cancel option.

## In code

<!-- Skeleton loading state -->
<div class="skeleton-card" aria-busy="true" aria-label="Loading content">
  <div class="skeleton-image shimmer"></div>
  <div class="skeleton-line shimmer" style="width: 80%"></div>
  <div class="skeleton-line shimmer" style="width: 60%"></div>
</div>

<!-- Error state -->
<div class="error-state" role="alert">
  <img src="/icons/network-error.svg" alt="">
  <h2>Connection lost</h2>
  <p>We could not load your messages. Please check your internet connection.</p>
  <button onclick="retry()" class="btn-primary">Try again</button>
</div>

<!-- Empty state -->
<div class="empty-state">
  <img src="/icons/no-results.svg" alt="">
  <h3>No projects yet</h3>
  <p>Create your first project to get started with AtomicGlue.</p>
  <a href="/projects/new" class="btn-primary">Create project</a>
</div>

## Common questions

Q: Should loading states be designed in Figma or handled by developers?

A: They should be designed in Figma by the designer and handed off as part of the component specifications. Never assume developers will "figure out" the loading, empty, and error states without design input. These states need the same level of design attention as the happy path. Design them as Figma component variants.

Q: How many error messages should I design for?

A: At minimum: network error, authentication error, permission error, not-found (404), server error (500), form validation errors (per field type), and a generic fallback. Each should have a specific message, icon, and action. If you only design one generic error state, you have designed an unhelpful error state.

## Key takeaways

• Empty, error, and loading states are the three most critical non-happy-path UI states.
• Empty states should guide users with context, explanation, and a call to action.
• Error states must be specific, human-readable, and offer a clear fix.
• Loading states manage time perception: skeletons, progress bars, or thoughtful messages.
• Design all three states as Figma component variants. Do not leave them for developers to guess.

## Related entries

• [UI (User Interface)](atomicglue.co/glossary/ui-user-interface)
• [Animation / Motion Design](atomicglue.co/glossary/animation-motion-design)
• [Microinteractions](atomicglue.co/glossary/microinteractions)

Last updated July 2026. Permalink: atomicglue.co/glossary/empty-state-error-state-loading-state