Dana Reyes runs a payroll startup called Northbranch, eleven people, based out of a shared office in Providence. Last spring she hired me to redesign the flow where employers submit hours for contract workers. I did what I always did: I opened Figma, drew the ideal screen, the one where every field is filled correctly and the submission goes through in four seconds. It looked great in the first review call. Then we got to what happens when a contractor’s bank details are wrong, and I had nothing. I sketched something on the spot, Dana frowned, and we spent the next two weeks redoing it three more times.
Starting at the Wrong End
The happy path is seductive because it’s the version of the product that makes you look good. It’s clean, it’s fast, it photographs well in a pitch deck. But almost nobody lives there. In Northbranch’s own usage logs, 34 percent of submissions had at least one validation error on first try. The happy path was, statistically, the unusual case.
I’d been designing the exception as an afterthought, bolted onto a flow that was never built to hold it. That’s why the error screen took four passes. The layout, the copy, the button placement, all of it had been optimized for a scenario that barely happened.
The Backward Sequence
So on the next project, a scheduling tool for a physical therapy clinic chain called Birchwell, I flipped the order. Before I touched the main flow, I listed every way it could fail or come up empty, and designed those screens first.
Error states first
What does it look like when a patient’s insurance ID doesn’t validate. What does it look like when two appointments collide. I wrote the copy for each one before I drew a single ideal-case screen, because copy written under constraint tends to be more honest than copy written to sound polished.
Then the empty states
Next came the states with nothing in them yet: a new clinic with no appointments booked, a therapist with an empty caseload. These forced decisions about hierarchy and tone that the happy path never would have surfaced on its own.
Only after those were solid did I design the sequence an engineer could put in a demo. By then, most of the hard calls about spacing, error density and tone had already been made under worse conditions, which meant the ideal screen was easy by comparison.
What the Numbers Actually Showed
Birchwell shipped in three weeks instead of the five we’d scoped. Revision rounds with their product lead, Marcus Chen, dropped from what had typically been four cycles to one. I don’t think this was luck. Designing the hard cases first meant fewer surprises showed up during build, because the edge cases had already been argued over on a static screen instead of discovered live in a sprint review.
Here’s roughly the order I now follow on every flow, before any visual polish happens:
- What does total failure look like, system down, request rejected
- What does partial failure look like, one field wrong, one record missing
- What does nothing look like, zero results, first use, empty inbox
- What does loading or waiting look like, and how long is too long
- Only then, what does success look like
By the time I reach that last item, the constraints are already set. The ideal screen just has to be the best version of a system I already understand.
Where It Breaks Down
This sequence is slower to show a client in week one, and that’s its real cost. Nobody gets excited looking at a validation error on a Monday morning call. If a founder needs something to put in front of investors by Friday, I’ll still mock up the happy path first and backfill the rest, because showing nothing isn’t an option either.
Teams that need a demo fast
With Northbranch, in hindsight, the mistake wasn’t designing the happy path first. It was treating the error states as something to squeeze in afterward instead of budgeting real time for them from the start. Dana and I talked about this months later, after the redesign had shipped and stabilized.
You don’t actually know a product until you’ve watched it fail in six different ways, Dana said. Everything before that is just a mockup of a mockup.
I’ve started saying something similar to clients at kickoff now, partly to set expectations and partly because I believe it. The flow that matters most is rarely the one in the deck.
