Why the “big redesign” mindset creates more problems than it solves, and how incremental, research-driven iteration delivers better results.
The Redesign Temptation
Every product team eventually reaches a moment where someone says: “We need to redesign this.” The current product has accumulated layers of inconsistency. The interface feels dated. The information architecture has grown unwieldy. Technical debt constrains what’s possible. The temptation to start fresh — to throw out the old and build something clean and modern — is powerful.
And sometimes it’s the right call. But far more often, the “big redesign” is a mirage that promises transformation and delivers disruption. It takes longer than expected, costs more than budgeted, alienates existing users, and frequently introduces as many problems as it solves. The dirty secret of product development is that most big redesigns don’t actually make the product better for users — they just make it different.
Why Big Redesigns Fail
The fundamental problem with big redesigns is scope. When you redesign everything at once, you’re making hundreds of design decisions simultaneously, each of which interacts with every other decision. The complexity is enormous, the timeline extends, and the feedback loop disappears.
In a normal iterative process, you make a change, ship it, observe the impact, and adjust. In a big redesign, you make all the changes, ship them at once, and then scramble to untangle which decisions were good and which were mistakes. If retention drops, was it the new navigation? The changed workflow? The unfamiliar layout? The removed feature? You can’t tell, because everything changed at once.
Big redesigns also carry enormous switching costs for existing users. People who have built habits and muscle memory with your current product are suddenly dropped into an unfamiliar interface. Even if the new design is objectively better, the disruption to their workflow feels like a regression. The “new YouTube layout” backlash that accompanies virtually every major redesign isn’t just resistance to change — it’s a genuine loss of efficiency for established users.
There’s also a political dimension. Big redesigns become organizational projects that take on lives of their own. They accumulate stakeholder requirements, scope expansions, and “while we’re at it” additions until the original vision is buried under compromises. The redesign becomes a vehicle for everyone’s wish list, not a focused improvement to the user experience.
The Power of Continuous Improvement
The alternative to the big redesign is continuous improvement: a steady cadence of small, measured changes that incrementally move the product forward. This isn’t as exciting as a dramatic reveal. It doesn’t generate launch-day press coverage. But it reliably produces better outcomes for users.
Continuous improvement works because it preserves the feedback loop. Each change is small enough that its impact can be measured. If something doesn’t work, it can be quickly reverted or adjusted. Users absorb changes gradually, and their habits adapt without disruption.
It also works because it forces prioritization. When you can’t change everything at once, you have to decide what matters most. This is healthy. It means the most impactful improvements get made first, and the team stays focused on user problems rather than aesthetic preferences.
Some of the most successful products in the world have evolved dramatically over the years through continuous improvement rather than periodic redesigns. Gmail, Google Maps, and Slack have all changed enormously since launch, but they’ve done it gradually enough that users barely noticed. The product they use today is far better than the one they started with, but there was never a jarring moment of “everything is different now.”
When a Redesign Is Actually Necessary
There are legitimate cases for a significant redesign: a fundamental shift in product strategy, a platform migration that requires rethinking the interface, or a product that has become so incoherent that incremental changes can’t fix the structural problems. If the foundation is broken, patching the walls won’t help.
But even in these cases, the execution should borrow from the continuous improvement playbook. Ship the redesign in phases rather than all at once. Run it alongside the existing product and let users transition gradually. Instrument everything so you can measure the impact of each change.
The question isn’t “should we redesign or iterate?” It’s “what specific problems are we solving, and what’s the lowest-risk way to solve them?” Almost always, the answer is smaller, faster, more measured changes — even if they’re less satisfying to announce.
The best product teams don’t ship redesigns. They ship improvements. Constantly, methodically, and always in service of the people using the product.