Look at how most software projects are laid out and you’ll spot the same quiet assumption baked into the timeline. There’s a block at the front for design. Discovery, research, some sprints of wireframes and mockups. Then a handoff. Then a long stretch labeled “build.” The design block has a clear end to it, and the build picks up right where it stops.
I think that shape is fundamentally flawed.
Design isn’t a phase you finish and walk away from. The hardest design decisions on any real project don’t happen in that neat block at the front. They happen deep in the build, once actual data, edge cases and users show up and start poking holes in your assumptions. If you’ve already spent your design capacity up front, those decisions still get made. They just get made by whoever’s closest to the keyboard, on a deadline, with nobody asking whether it’s still the right call.
The alternative to phased design isn’t shipping slower. It’s shipping the wrong thing on time.
“We can’t design forever”
I’ll get the obvious objection out of the way first, because it’s a fair one. At some point you have to build. You can’t discover and iterate and polish forever. That’s its own way to sink a project down the drain, and we’ve all watched it happen. So if you’re reading this as “the designer wants unlimited runway,” I promise, I’m not saying that.
This is about the shape of the work, not the amount of it. A thin, steady line of design attention running through the whole build beats a fat block of design up front, followed by silence. That’s true even when that big ol’ block adds up to more hours. The goal isn’t to design more. It’s to stop designing everything before you know anything, and then going dark right when the real questions land.
The build is where the real questions live
Design done up front runs on assumptions. It has to. There’s no working software yet to push back on your designers instincts.You make your best guesses about the flows, the states, and the data, and you mock them up cleanly. Those guesses are useful. They’re still guesses.
Then the build starts and reality (a developer) shows up. The empty state nobody pictured, because in the mockups there was always data. The API that hands back a shape the design never planned for. The flow that reads fine on a whiteboard feels miserable by step four once you’re actually clicking through it. The “edge case” that turns out to be a third of real usage.
None of those are build problems. Every one of them is a design decision in a build costume. And they only become visible once the code meets the real world, which is well after the design phase has officially wrapped.
When design capacity runs out, the decisions don’t
These decisions don’t wait around for the designer to have capacity. They get made either way.
A developer hits the empty state you never specced at 4pm, needs to stay unblocked, and makes a call. Maybe it’s a good call. Maybe it isn’t. Either way it was a design decision, and it got made quietly, by someone who isn’t the designer, because the plan pretended the design work was already finished.
That is by no means a slight on the devs. Developers make sensible calls with the information in front of them. It’s a shot at a plan that pulled design out of the room and then acted surprised when design decisions kept happening anyway. Ending the phase didn’t end the work. It just removed the designer from doing it.
“Confidently wrong” costs more than “visibly unfinished”
The tempting thing about phased design is that it looks healthy. Design’s done, the build is humming, the burn-up chart is green. Everybody can see progress.
But under the hood, a phase-based project is piling up small wrong turns that nobody’s checking, because the person who’d catch them has already rolled onto the next assignment. It looks on track right up until the demo where the client says “oh, that’s not what I meant.” Or worse, until launch.
A continuous design thread trades that clean-looking progress for something better. It catches the drift while it’s still able to be fixed. Visibly unfinished is uncomfortable, I get that. Confidently wrong is a rewrite. I’ll take uncomfortable every time.
What to do instead
Budget design as a rate, not a lump. Instead of “four weeks of design, then build,” protect a steady slice of design capacity across the whole engagement. Smaller than the front-loaded block, sure. But never zero. Zero is the failure mode.
Put design inside the build loop. Designers in standups. Designers reviewing PRs for anything a user will touch. Designers in the room the second an edge case forces a call, there by default instead of getting summoned back as an escalation after the wrong thing already shipped.
Keep asking “who decides this?” The clearest sign that design has quietly ended is that interface decisions start getting made without anyone flagging them as decisions. Name a design owner for the whole build, not just for discovery. When a call gets made, someone should be able to say who made it and why.
Frame it to the client as risk reduction, not scope creep. This is the conversation that actually protects the capacity. Continuous design isn’t extra polish or gold-plating. It’s how you keep from building the wrong thing efficiently. That’s not a cost the client is eating. It’s insurance they’re buying. Put it that way and it’s a budget conversation most clients are happy to have.
The line worth holding
A phased plan looks great on a Gantt chart. Everything’s boxed and sequenced and the design box has a satisfying checkmark on it. But “looks clean on a chart” and “is actually the right software” are two different things, and when they fight, the chart usually wins. It’s easier to call design done and go chase throughput than to keep a designer in the mix asking annoying questions in week nine.
I get why that’s tempting. It’s also how you end up with a great-looking burndown and a product that missed.