The Happy Path Is a Fifth of the Work

A designer presents a flow: four screens, everything clean, everything works. The room approves. It ships.

Then reality arrives. A person opens it with no data yet and sees a blank rectangle. Another loses signal halfway through and doesn't know whether the money left. A third uploads a file of the wrong type and gets a red line saying "Error: validation failed." A fourth comes back the next day and finds an expired session and an empty form where twenty minutes of typing used to be.

None of these were designed. They were all specified — by whichever developer had to make the screen not crash, at 6pm, alone.

Design the path, not the pages

The first shift is to stop thinking in screens and start thinking in flows: the ordered sequence of steps a person takes to finish something, including where they came from and where they go afterwards.

Three things a flow makes visible that a screen never does:

Entry points. People do not always start at your beginning. They arrive from a link in an email, a search result, a shared item, a notification, a bookmark from four months ago. Every one of those is a first screen for someone, and it has to work without whatever the previous step would have set up.

The return. Almost every real task is interrupted. Someone leaves in the middle and comes back — later that day, on a different device. What's preserved? Where do they land? Does the app remember or scold them?

The exit. What happens after success is the most under-designed moment in most products. The person achieved the thing; now they're staring at a confirmation. What's the next reasonable action, and did you offer it?

The cheapest way to make a flow visible is a boxes-and-arrows sketch with one box per decision, not per screen. Decisions are where flows break; screens are just where decisions get shown.

Every screen is five screens

Scott Hurff's "UI stack" is the most useful checklist in interface design, and it takes ninety seconds to apply.

Ideal state. Everything present, everything loaded. This is the one you designed and the one you showed.

Empty state. No data yet. The most wasted opportunity in software: it's the moment of maximum attention and minimum clutter, and most products fill it with a grey box.

Loading state. Data is coming. Skeleton screens (the shape of the content, greyed) beat spinners for anything with a predictable layout, because they tell you what's arriving. And under about a second, show nothing at all — a flashing spinner makes a fast thing feel broken.

Partial state. Some data, but not enough to be useful — one item in a list built for forty, half a profile, a dashboard with one chart. This is the state that quietly makes new users feel the product is worthless, and almost nobody designs it.

Error state. Something failed. Which of the many somethings, and what can they do about it, and did they lose anything.

Run this list against any screen you've built. Most teams find they have designed one state out of five and shipped a guess about the other four.

Three kinds of empty

They need completely different treatments, and conflating them is a common mistake.

First use — nothing here yet. Teach. This is the best onboarding surface you will ever get: one sentence on what goes here, one on why it's worth it, and one obvious action to create the first item. An empty state that says "No projects" wastes the moment; one that says "Projects hold your files and your team. Create the first one — it takes a minute." does the work of a tour.

Cleared by the user — you finished. Acknowledge. An empty inbox is an achievement, not an absence. And offer the exit: what now?

No results — search or filter found nothing. Rescue. Never a dead end: show what was searched, suggest the near-miss, offer to clear one filter at a time, and give a route to a human. A no-results screen with no way forward is where sessions end.

Prevent, then forgive

Nielsen's fifth heuristic puts prevention above good error messages, and the industrial version of this idea is older: Shigeo Shingo's poka-yoke — the mistake-proofing that means a part physically cannot be fitted the wrong way round.

The interface equivalents are unglamorous and effective: disable what can't be chosen instead of rejecting it afterwards; use a date picker where a date is wanted; accept whatever format they type and normalise it; separate destructive actions from frequent ones; ask for confirmation of consequences, not of intentions.

It also helps to know which kind of failure you're fixing. James Reason's distinction, adopted by Norman:

A slip — they knew what to do and their hand went wrong. Fix with constraints, spacing and undo.
A mistake — they did the wrong thing on purpose because their model was wrong. Fix with clearer labels, feedback and a better conceptual model. No amount of confirmation dialogue helps here; they'd confirm it, because they think it's right.

And when prevention fails, the recovery beats the warning. Confirmation dialogues are clicked through blind within a week — they train the exact reflex they were meant to interrupt. Undo is almost always better than "are you sure?": it costs the user nothing when they were right, and saves them completely when they weren't.

Ask less. Undo more.

Time is part of the design

Everything above assumes the screen is there. Often it isn't yet.

The thresholds from earlier still govern: instant under 0.1 s, thought survives to 1 s, attention ends at 10 s. Beyond that you need visible movement and, ideally, words about what's happening — "Uploading 3 of 12" is infinitely better than a bar, because it's checkable.

Two tricks worth knowing for multi-step flows:

Optimistic updates. Show the result immediately, reconcile with the server after, roll back loudly if it fails. This is why good apps feel instant on bad connections.

Endowed progress. Ran Kivetz and colleagues (2006) gave people coffee cards: one needing 10 stamps, another needing 12 but arriving with 2 already stamped. Identical work remaining — but the pre-stamped group completed far more often. Starting a multi-step flow at "step 1 of 4 complete" is not a trick if the first step really is done; it's an honest use of how motivation works.

Edge cases aren't the edge

The word "edge case" is how teams give themselves permission not to design something. Then it turns out that a third of real users are in one.

The list worth walking every time:

Zero, one, many, and 10,000. Lists designed for six items and given two thousand. Or one.
Long content. A name of forty characters, a product title that wraps to four lines, a language where words are 60% longer than English.
Slow and offline. The train tunnel, the hotel wifi, the 3G suburb.
Interrupted. Phone call mid-flow, tab closed, battery dead.
Time. Time zones, midnight boundaries, "yesterday" for someone eleven hours away.
The second device. Started on the phone, finished on the laptop.
Not the owner. A shared account, a colleague's screen, an admin acting on behalf of someone else.
Permissions. They can see it but not edit it. What does the disabled button say about why?

In practice

Draw the flow before the screens. Boxes for decisions, arrows for transitions, and mark every point where the person could leave.

Apply the five states to one screen today. Ideal, empty, loading, partial, error. Design the ones that are missing; it's usually three.

Rewrite one empty state into onboarding. What is this, why does it matter, one button. It's the highest-return hour in this whole article.

Replace a confirmation with an undo. Pick one "are you sure?" and turn it into an action with a five-second undo toast. Watch how much faster everything gets.

Audit your error messages for three parts. What happened, why, what to do next. Most have only the first, and phrase it in database language.

Test with a throttled connection. Set your browser to slow 3G for an hour of normal use. You'll find loading states you never knew existed.

Check yourself

Close the article and answer in your own words:

Why is designing screens instead of flows a problem, and what three things does a flow reveal?
Name the five states of any screen and say which one you most often skip.
What are the three kinds of empty state and what should each one do?
What is poka-yoke and how does it appear in an interface?
What's the difference between a slip and a mistake, and why does the fix differ?
Why is undo usually better than a confirmation dialogue?
What does the endowed progress study suggest about multi-step flows?

In short

Design flows, not screens: entry points, interruptions and returns, and what happens after success.
Every screen has five states — ideal, empty, loading, partial, error. Most teams design one and guess the rest.
Empty states come in three kinds: first use (teach), cleared (acknowledge), no results (rescue). Never a dead end.
Prevention beats error messages; poka-yoke means making the wrong action impossible rather than punished.
Slips need constraints and undo; mistakes need a better model. Confirmation dialogues fix neither and get clicked through blind.
Undo beats "are you sure?" — free when the user was right, complete rescue when they weren't.
Optimistic updates make slow networks feel fast; endowed progress makes multi-step flows finish more often.
Edge cases aren't the edge: zero and 10,000, long names, offline, interruption, time zones, second devices, borrowed accounts.