Wireframing Empty, Error & Loading States

The screens most teams forget to wireframe are the ones users see most often: empty states, loading states, and errors. A product with a beautiful happy path but an undesigned error screen or a blank first-run empty state is judged by its worst moment, not its best one — and that worst moment usually ships un-reviewed.

Quick Answer: Wireframe six states for every screen — empty, first-run, loading, error, no-results, and success — not just the happy path. The first-run empty state matters most of all: it's often a new user's first real interaction, and it can double as onboarding if you design it on purpose.

Why States Are Features, Not Afterthoughts

States are features because most of a product's lifetime is spent inside one, not passing through the happy path. A returning user hits loading on every session. A new user's first screen is almost always empty. Every integration eventually throws an error. Treating these as engineering fallbacks instead of designed moments is exactly why bug trackers fill up with "unhandled state" tickets.

Jakob Nielsen's usability heuristics — still the reference point for interaction design decades after Nielsen Norman Group first published them — name two of these states directly: visibility of system status, where loading indicators live, and help users recognize, diagnose, and recover from errors. Neither is framed as polish. Both are baseline requirements in NN/g's research, sitting alongside heuristics for navigation and consistency.

An error message is also an emotional event, not just an information problem. Plotting these moments against a customer journey emotion curve shows why a bad error screen does more damage than a bland empty one: it lands exactly when a user's frustration is already climbing, not at a neutral moment. A generic "Something went wrong" compounds that spike instead of absorbing it.

Baymard Institute's long-running e-commerce checkout research has repeatedly flagged confusing validation and error messaging as a recurring, significant contributor to checkout abandonment — directionally on par with cost surprises and account-creation friction, even though the exact share shifts study to study. If a missing error state can cost a retailer a completed purchase, it can just as easily cost a B2B tool an activated trial.

Google's Material Design guidelines treat empty states as a named, documented pattern rather than a fallback, specifying that an empty screen should communicate what the space is for and offer a way to fill it — and, critically, that it should never look identical to a loading or error state by accident. That last point catches a real mistake: a spinner stuck mid-fetch and a permanently empty list can render nearly the same on screen.

That's exactly why the two need visually distinct treatments, not just different copy tucked underneath a shared layout. If your team hasn't locked down the fundamentals of frame-and-flow thinking yet, a wireframing complete guide is the right place to start before layering in state design on top.

The Six States Worth Wireframing on Every Screen

Every screen that displays data needs six state wireframes, not one: empty (no data yet), first-run (a new user's first look), loading (data in transit), error (something broke), no-results (a search or filter came up dry), and success (the action worked). Skip any one of them and the decision quietly passes to whichever engineer implements it fastest, on whatever afternoon they get to it.

Here's what each one is actually protecting against:

empty — a list, dashboard, or feed with genuinely zero records, distinct from a first-run screen because the user has already been active.
first-run — the very first time this specific user sees this specific screen, before they've created anything at all.
loading — the gap between a request firing and data arriving, including slow-network and partial-load variants.
error — a request failed: server error, permission denial, validation failure, or a dependency timing out.
no-results — the request succeeded, but a search, filter, or query legitimately matched nothing.
success — an action completed, and the user needs confirmation, a next step, or both.

Laid out side by side, the risk of skipping each state and what "good" looks like becomes concrete rather than abstract:

State	When it appears	Risk if left undesigned	What "good" includes
`empty`	Zero records exist yet	Reads as broken or buggy	Explains why it's empty and what fills it
`first-run`	User's very first visit	Missed activation moment	Doubles as a guided first task
`loading`	Request in flight	Feels frozen past ~1 second	Skeleton or progress cue, not a blank flash
`error`	Request fails	User blames the product, not the network	Plain-language cause plus a recovery action
`no-results`	Valid query, no matches	Looks identical to a bug	Confirms the search worked and suggests a next step
`success`	Action completes	User re-submits or leaves unsure	Clear confirmation plus a logical next step

Notice that every entry in the last column is an active design decision — a sentence, an icon, a button label — not simply "handle it" left for whoever writes the code. Sketch each state using the same wireframe layout blocks vocabulary you already use for the happy path. Most of the time you're swapping one content block for another — a table becomes an illustration-plus-message block — not redrawing the whole grid from scratch.

Loading States Deserve More Than a Spinner

A generic spinner is the easiest loading state to ship and the least informative one: it confirms something is happening without any sense of what, or how long. Nielsen Norman Group's response-time guidance, grounded in human-computer interaction research going back decades, sets useful thresholds — roughly a tenth of a second reads as instantaneous, about one second keeps a user's train of thought unbroken, and past roughly ten seconds attention drifts elsewhere entirely.

A loading wireframe should specify which of these bands it's designed for. A skeleton screen and a full-page progress bar solve different bands of that scale, not the same problem at different fidelities.

Luke Wroblewski's widely cited case against the generic spinner argued for replacing it with a skeleton screen — a low-fidelity outline of the content about to arrive, like a shaded rectangle where a headline will sit. It sets a layout expectation before data confirms it, which users tend to perceive as faster even when the actual wait is unchanged.

Wireframing a loading state means choosing deliberately between three options: a bare spinner for sub-second waits with nothing to preview, a skeleton screen for anything with a predictable layout, and a real progress indicator whenever the wait has a knowable duration, such as a file upload. Defaulting to a spinner for all three is the loading-state version of defaulting to a generic banner for every error — the path of least design effort, not the best fit for the moment.

The Empty State That Doubles as Onboarding

A first-run empty state is the single highest-leverage wireframe in a product, because it's often the first — and sometimes the only — thing a new user reads before deciding whether to keep going. Treat it as a blank canvas and you waste that attention. Treat it as the user's first job to be done and it becomes free onboarding.

The weak version says "No projects yet." The strong version tells the user what a project is, why they'd want one, and puts the exact next action in front of them — often pre-filled with a sample so the interface never looks like it's malfunctioning.

Two well-documented, publicly visible patterns show the range:

Trello's classic first board ships pre-populated with a sample checklist, a card or two already marked done, and inline hints pointing at the controls that created them — the empty state teaches the mechanic instead of describing it.
Notion's first workspace offers a gallery of starter templates rather than a blank page, so the "empty" moment is really a curated choice, not a void.
Slack's first channel seeds a welcome message from a bot along with a short list of suggested first actions, so a brand-new workspace never presents a truly silent screen.

Those examples share the same handful of design levers, worth checking against your own first-run screen one at a time:

Design lever	Weak empty state	Strong empty state
Copy	"No items found."	Explains what belongs here and why
Visual	Blank white space	Illustration or sample content that sets expectation
Primary action	Buried or absent	One obvious, labeled call to action
Data	Truly zero content	Often seeded with a dismissible example
Job served	None	Doubles as first-run onboarding

Every "strong" cell in that table costs a wireframing decision, not an engineering one — which is exactly why it needs to exist as a frame before a ticket, not as a comment on one.

A blank screen with no explanation isn't neutral — it's a silent bet that the user already knows what to do. Most of the time, that bet is wrong.

A Per-Screen State Checklist You Can Actually Run

A per-screen checklist works better than a general reminder to "handle edge cases," because it forces a yes/no decision for each state before a ticket gets marked ready. Run it during wireframing, not during QA, and most of these questions get answered in minutes instead of becoming rework later.

Before data exists: `empty`, `first-run`, `no-results`

Does the copy explain why the screen is empty, not just that it is?
Is there one clear, labeled action the user can take from here?
Is first-run visually distinct from a returning user's empty state, or are they the same screen?
Does no-results confirm the search actually ran, so it doesn't read as a bug?
Is there a way to clear filters or broaden the search directly from the no-results screen?

While something is happening or broken: `loading`, `error`

Is there a skeleton, spinner, or progress indicator for anything that takes longer than roughly a second?
Does the error message name the actual problem in plain language, not a stack trace or generic banner?
Does every error screen offer a recovery action — retry, go back, or contact support — not just an apology?
Are permission-denied, not-found, and server-error states visually distinguishable from each other?
Does a slow or flaky network get a distinct treatment from a hard failure?

After the action works: `success`

Is the confirmation visible without requiring the user to scroll or guess?
Does it suggest a logical next step instead of leaving the user stranded on a static confirmation?
Would a user landing here from a deep link or notification understand what just happened?

Designing States Without Turning Wireframing Into a Second Project

You don't need six full mockups per screen to cover this — one baseline frame plus targeted state variants is enough, and deciding which states get a real wireframe versus a one-line spec note is itself a judgment call. That's the same call this site's guide on when a PM should wireframe versus write walks through: wireframe when the layout itself is the decision (an error banner competing with a form for attention), write when only the copy or logic is in question.

A simple triage keeps this from ballooning into a second design project: wireframe every state in full on high-traffic, high-first-impression screens — onboarding, primary dashboards, checkout, the core workflow a user touches daily — and settle for a one-line spec note on low-traffic admin or configuration screens, where a generic default is an acceptable risk rather than a real one. The point isn't to design everything; it's to make the decision to skip a state a deliberate one instead of an accidental one.

Fidelity matters here more than volume. A rough box-and-label sketch of the error state, with the message text and the recovery button named, gives a designer everything they need without dictating pixels — which is exactly the handoff line between a PM and a designer this kind of artifact should respect. Hand over intent and content; leave visual polish to the person whose job that is.

Key Takeaways

States are features, not fallbacks — loading, error, and empty occupy more of a user's actual time in the product than the happy path does.
Wireframe six states per screen: empty, first-run, loading, error, no-results, and success — each protects against a different failure mode.
The first-run empty state is free onboarding if it explains what belongs on the screen and offers one clear next action, as shown by patterns like Trello's pre-seeded first board.
Error states are emotional, not just informational — plain-language causes and a recovery action matter more than apologetic copy.
Run a per-screen checklist during wireframing, not QA, so state gaps get caught while they're still cheap to fix.
Match fidelity to the decision — sketch layout and copy intent, then hand off to a designer for the visual system rather than dictating pixels.

Frequently Asked Questions

What is an empty state in UX design?

An empty state is the screen shown when a list, dashboard, or feed has no data to display yet — before a user has created content or before a query returns anything. Designed well, it explains why the screen is empty and gives the user one clear action to take next, rather than reading as a broken page.

How many states should a single screen actually have?

Most data-driven screens need six: empty, first-run, loading, error, no-results, and success. Not every screen needs all six drawn out in full detail — a static settings page may only need error and success — but each one should be a deliberate decision, not a default left to whoever builds it.

Should error states be wireframed, or can engineering just use a default banner?

Error states should be wireframed whenever the message content or recovery action is decided by the PM, because a generic default banner treats every failure the same way regardless of cause. Nielsen Norman Group's usability heuristics specifically call for helping users recognize, diagnose, and recover from errors — a one-size banner does none of the three.

What's the difference between an empty state and a no-results state?

An empty state means no data exists at all yet, usually for a new user or a fresh feature; a no-results state means a search or filter query ran successfully but matched nothing. They look similar but need different copy — one invites creation, the other confirms the search worked and offers a way to broaden it.

Do loading states need a real wireframe if they're just a spinner?

A basic spinner rarely needs its own wireframe, but any loading state longer than roughly a second benefits from one, especially skeleton screens that hint at the layout underneath. Wireframing it also forces the decision of what a slow or partially-loaded state looks like, which a generic spinner doesn't address at all.