Happy Path

There's an argument that repeated itself for years between the people who draw screens and the people who build them. A mockup shows the case where things work out. Code has to decide what happens in every case where they don't, or it won't run at all.

Pagedeck had this exact argument. Noa handed over a file-attachment flow in three frames: pick a file, watch the progress bar fill, see it land in the document. Theo started building and came back with questions. What shows up when the file is over 50 megabytes? If the connection drops mid-upload, does it start over? What happens when someone with view-only access lands on this screen? None of the three were in the mockup, and none of them were in the estimate either.

As this kept happening, the route in the mockup got a name of its own. Naming it changed the shape of the conversation. Finding what was missing used to mean hunting for it one gap at a time. Now the first question asked of any mockup is whether it is only the happy path, which is a much easier question to answer than listing everything absent from it.

A happy path is what you get by walking one task from start to finish and taking the favorable branch at every fork. The user is logged in, has permission, enters input that fits the format, gets a response from the server, and reaches the end.

Drawing one takes four steps.

1. Pick a single task and define the state that counts as finished. For sharing a document, finished is the moment the other person has the link and can open it.
2. Lay out the screens and actions in between as one line. Open document, hit share, pick a recipient, pick a permission level, send — five slots.
3. Write down what has to be true at each slot. Logged in. Owner of this document. Recipient already uses the product. Plan allows external sharing.
4. Invert each of those conditions one at a time. What comes out is the rest of the flow, and a single happy path usually sprouts six or seven branches this way.

Step 4 is where the term earns its keep. The happy path itself is easy to draw and nobody forgets it, because nobody forgets the case where things work. The value is in using that one line as a baseline for counting the cases that leave it. An edge case is a rare situation that still needs a defined answer, and without a baseline there is no way to count them, because there is nothing to say they deviate from.

Turning those deviations into screens is the job of UI state, the term for how one element looks different depending on the situation. When a condition breaks, what fills the screen is usually an error state or an empty state. For the attachment flow above, that means three more frames: file too large, connection lost, permission denied. None of them are hard to design. They are simply invisible until something names the line they fall outside of.

The phrase surfaces most often in design handoff. The receiving side asks whether this is only the happy path, and the handing-off side says how far they drew. Next it shows up in estimation, where branches get counted before work starts, and in acceptance criteria, the conditions a piece of work has to meet to be called done. Criteria written against the happy path alone can pass review and still leave the incident unaddressed.

In quality assurance (QA) it works as a threshold. A feature with a broken happy path cannot ship. A feature that passes only the happy path is not ready to ship either — it's ready to start being tested. Test cases are usually written by following the branches that come off that one line, which is why a handoff that lists those branches shortens the test-writing work as much as it shortens the build.

There's a trap on the demo side. Sales demos run the happy path and nothing else, which makes sense when you have fifteen minutes to show value, except the audience reads that route as the whole product. A customer who follows along with Sofia's demo and then hits a permission-denied screen in week one feels like they bought something other than what they saw. That's why demo scripts sometimes include a step or two off the happy path on purpose, like showing what a viewer without access actually sees. The demo runs longer and the first-week questions run shorter.

"This mockup is just the happy path. What shows up if someone uploads a file over 50 megabytes?"

Only the favorable case has been drawn, so the rest of the screens are being asked for.

"Let's get the happy path working first and add the error handling next sprint."

A scheduling proposal: make the main route run, fill in the branches later.

"The demo will only run the happy path, so let's take permission questions afterward."

The walkthrough will stay on the route where nothing goes wrong.

When Noa hands off a flow, the first frame carries the happy path as a single line, with the deviations pinned underneath slot by slot. Some of those slots are finished screens. Others are just labels — file too large, connection lost, permission denied. Leaving the labeled ones unfinished is the point of the method. It puts the fact that a screen is missing in front of Theo rather than hiding it.

Before that, those slots didn't exist at all, and Theo decided the missing screens himself while building. The wording he invented came out different on every screen, and all of it had to be rewritten later in one pass.

Drawing the happy path first sometimes gets read as laziness, as if it proves nobody thought about exceptions. As an order of operations it's actually correct: you need a baseline before you can count deviations, and drawing every branch at once blurs which route is the main one. The problem isn't drawing it, it's stopping there. A mockup that stops says nothing about what's missing, so the developer fills the gaps alone and those decisions end up recorded in neither the mockup nor the spec.

The other misread is treating a passed happy path as proof the feature works. The route that was tested did pass, so the conclusion feels earned. But nearly every incident a user hits happens off that route. Collect the support questions from the first week and they cluster around permissions, size limits, duplicates, and dropped connections. Teams that ship on happy-path-passes receive those questions as screen design work after launch.