Summary: Most designers underestimate redesigns and feature additions not because they’re bad at scoping, but because their estimates don’t account for what the work is being built on top of. This article argues that the real problem isn’t the estimate — it’s the unexamined assumption that the existing product is stable enough to build on. When that assumption goes unchecked, designers don’t just create delivery risk. They create compounding design debt that gets harder and more expensive to unwind with every sprint that passes.
There is a pattern that shows up often enough in design work that it stops feeling like a coincidence. A redesign gets scoped, estimated, and kicked off. Partway through, the team starts running into things that were not in the brief — usability problems in nearby flows that the new work makes more visible, navigation structures that clash with the new direction, interaction patterns that were already broken and now need to be worked around. The timeline starts to slip. Scope conversations happen. Some problems get patched. Some get deferred. The work ships, but it ships on top of a foundation that was never properly looked at.
Then six months later, the same cycle starts again.
The instinct is to treat this as an estimation problem. The team didn’t account for the complexity. They should have added a buffer. Next time, build in more room. But that framing misses what is actually happening. The real problem is not that the estimate was too small. The real problem is that the estimate was built on an assumption nobody checked: that the existing design was a stable enough base to build on.
Most of the time, it isn’t.
Why the foundation gets skipped
When a designer starts scoping a redesign or a new feature, the natural focus is on the new work — what needs to change, what needs to be created, what the flow should look like when it’s done. That is where the brief points. That is where stakeholder attention sits. That is what gets estimated.
What rarely gets estimated is the condition of what already exists.
This happens for a few reasons. Nobody wants to be the person who adds two weeks to a timeline for work that is technically out of scope. It is hard to argue for fixing existing problems when the business is asking for something new. And most scoping happens before the work has been explored deeply enough to know what’s underneath it — so the assumption of a clean foundation gets built into the estimate by default.
Not because anyone decided it was safe. Because nobody stopped to check.
What you are actually building on
Not all inherited problems are equal, and treating them as if they are is where most of the trouble starts.
Some problems are surface-level. Inconsistent button styles, outdated components, small gaps in interaction behaviour. These can usually be absorbed into the work as you go. You fix them, flag the bigger ones, and move on. They rarely change the scope in a meaningful way.
Then there are structural problems. These sit deeper — in the navigation logic, in how screens are organised, in the mental model the product expects users to have. They do not announce themselves in a brief. But they shape everything around them. If the flow you are redesigning sits inside a navigation structure that users already struggle with, improving the flow in isolation does not solve the problem. It just makes the confusing part look better.
And then there are wrong solutions. Not rough solutions. Not solutions that need polish. Solutions that were designed for the wrong problem to begin with. A checkout flow built around an internal processing model instead of how users actually think about completing a purchase. A settings screen that answers a question nobody is asking. An onboarding sequence that assumes context users do not have when they arrive.
These are the ones that matter most for estimation. You cannot absorb them into the work, and you cannot design around them cleanly. Every screen you add on top of a wrong solution makes the wrong solution harder to undo. Every sprint that passes raises the cost of the correction that never happened.
That is the risk nobody prices into the estimate.
When to stop and fix the foundation first
Not every underlying problem is worth pausing for. The judgment is not whether problems exist — they almost always do. The judgment is whether the new work can actually succeed if the underlying problem stays unresolved.
A useful question to ask is: what does the new work depend on? If the redesign depends on users being able to find a section they currently cannot locate, the navigation problem is not separate from the scope. It is the scope. If the new feature assumes a mental model that the current product actively contradicts, adding the feature without resolving that contradiction does not reduce friction. It increases it.
The test is roughly this: will the new work succeed on its own terms if the foundation stays as it is? If the answer is no, the foundation work was always part of the scope. It just was not in the estimate.
The harder situation is when the foundation is wrong, but the new work can technically move forward anyway. A navigation problem that slows users down but does not prevent completion. A structural inconsistency that creates confusion but does not break the flow entirely. In those cases, the decision to fix now or defer is a real trade-off — and it should be made as a real decision, with the risk named clearly, not by whoever has the least resistance to moving forward.
That is where design judgment matters. Not in pushing for perfection, but in making sure the decision about the foundation is actually made, rather than defaulting to whatever keeps the timeline intact.
How to change the estimate
If a foundation review needs to happen before the estimate can be trusted, then the foundation review needs to be a visible part of the process — not a step that disappears because nobody budgeted for it.
In practice, this means treating the early phase of any significant redesign or feature addition as its own piece of work. Not a full audit, not a research project. A focused review of what the new work will sit on top of. What usability problems already exist in and around the scope? Which of them will the new work expose, depend on, or make worse? Which ones are structural? Which ones are wrong solutions that need to be resolved before anything new can work properly?
This kind of review does not take long if it is done with clear intent. A few days of analysis against a defined set of questions. But it changes what comes out of it, because instead of an estimate built on an untested assumption, you get an estimate that reflects what is actually there.
The output is not a perfect scope. It is a scope with known conditions. Some problems get absorbed into the work. Some get explicitly deferred, with the risk written down. Some get flagged as things that need to be addressed before the planned work can succeed. And the estimate reflects all of that, instead of treating the foundation as if it does not exist.
This is a small change to how scoping works. But it shifts where the risk sits. Right now, the risk of an unexamined foundation lands on the people doing the work — designers who discover mid-sprint that the ground underneath them is not what they thought. Moving foundation assessment into the planning conversation makes that risk visible early enough to actually manage it.
The cost of building on the wrong solution
There is a version of this problem that plays out over a longer timeline than most estimation conversations account for, and it is worth naming directly.
When a team adds a redesign or a new feature on top of a fundamentally wrong solution, the immediate cost looks manageable. The work ships. Users adopt it. The metrics move. But the wrong solution is still underneath, and now it has more on top of it. The next feature has to fit around it. The next redesign has to work with it or fight it. The debt does not sit still.
At some point, the cost of undoing the wrong solution becomes larger than the combined cost of everything that was built on top of it. That is when teams reach for the full platform redesign, the complete architectural rethink, the initiative that takes a year and touches everything. These projects are almost never caused by one bad decision. They are caused by many small decisions to keep building without fixing what was already wrong — each one of which seemed reasonable at the time.
The estimate that skips the foundation is one of those small decisions. It feels efficient in the moment. It is expensive over time.
What this asks of designers
Designers are usually the people best placed to see foundation problems early. Design work happens at the layer where structural issues become real — where a navigation problem becomes a user who cannot find what they need, where a wrong solution becomes a flow that users abandon, where an inconsistency becomes the kind of confusion that quietly erodes trust.
But seeing the problem and being able to surface it in a scoping conversation are two different skills. Usability findings do not travel well into planning discussions. They get acknowledged and set aside, because the conversation is about timelines and scope, not about experience quality.
The shift is in how the finding is framed. A navigation problem that will cause a new feature to underperform is not just a usability issue — it is a delivery risk. A wrong solution that will need to be rebuilt within two years is not a design concern — it is a cost projection. When foundation problems are framed in terms of what they will cost if they are not addressed, they land differently in the conversations where scope and timelines are actually decided.
That is the work. Not only identifying what is broken, but being specific enough about what it will cost to leave it broken — so the decision about whether to fix it is an actual decision, not a silent assumption baked into an estimate that nobody questioned.
Because the assumption that the existing design is stable enough to build on is almost never true. And teams that keep making it are not bad at estimating. They just haven’t built the habit of checking what they are building on top of.
More articles on Medium
More articles on Linkedin
