The Redesign Fallacy

Here is what a redesign pitch sounds like. The product has gotten messy. The flows feel bolted together. The codebase is a nightmare. A proper redesign would fix everything in one go, clean slate, right architecture from the start. It sounds decisive. It sounds like the kind of call that a serious designer makes when things have gotten bad enough.

It is almost never the right call. And the reason you reach for it anyway has more to do with your own psychology than with the state of the product.

How Products Get Complicated

Products do not get messy because someone decided to make them messy. Nobody sits down and plans a confusing checkout flow or a settings screen that takes four taps to find. It happens in layers. A button gets added because a stakeholder asked for it. A modal appears because someone needed to surface an edge case. A new feature lands on a screen that was never designed to hold it. Each individual decision was small. Each one felt reasonable at the time. And nobody was ever in the room whose whole job was to say no to the accumulation.

C. Northcote Parkinson described this in 1957, and the observation still stings: “The time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved.” Teams spend two hours arguing about a button label. Nobody questions the architecture that button sits on. The small stuff gets debated because it is easy to see and easy to have opinions about. The big stuff grows in the background because no single person can hold all of it in their head at once, and so each person only ever touches their corner of it.

This is UX debt. Not a catastrophe you can point to, just compound interest on a thousand small shortcuts. The Nielsen Norman Group has tracked this pattern across product teams and found a consistent result: the longer you wait to address it, the more it costs to fix, and not only because the problems get worse. Users adapt to the broken version. By the time you fix it, you are also managing the change itself on top of the repair.

Why Starting Over Feels So Good

When a product reaches a certain level of mess, designers start thinking about escape. The pitch writes itself: the problems are too tangled to fix one by one, a real redesign would let the team do it right for once, and staying in the current system is just digging the hole deeper. What this pitch leaves out is the planning fallacy.

Kahneman and Tversky identified the planning fallacy in 1979, and Buehler, Griffin, and Ross confirmed it in 1994: people consistently underestimate how long their own future projects will take, even knowing their past projects ran over. Psychology students in Buehler’s study predicted finishing their senior theses in 34 days on average. The actual average was 56. They had seen their own estimates fail. They underestimated anyway. A redesign looks clean in the planning stage because everything is still imaginary there. The current product is real, with real constraints and edge cases you have already mapped. The new one exists only as a concept, and concepts do not have bugs or legacy integrations that turn out to be load-bearing. The comparison is never fair.

There is also the Not-Invented-Here problem. Once a team builds ownership over a codebase or design system, they start to distrust work they did not create. Katz and Allen documented this in research on engineering teams: groups rated internally developed solutions as superior to outside alternatives, not because they were, but because of the psychological distance from the external source. Redesigns often start here. The existing system was built by the previous team, and somewhere in the background there is an instinct that says we would not have built it this way. That instinct is not design thinking. It is ego with a Figma file attached.

Then there is what Fred Brooks called the second-system effect. Engineers and designers who have shipped one product carry into their second one all the ideas they had to leave out the first time. The second system becomes the place where every constraint they accepted the first time finally gets overridden. The result is almost always overengineered, overscoped, and slower to ship than anyone expected.

What Digg Lost

In 2010, Digg launched version 4. The product had been struggling, growth was flat, Facebook and Twitter were pulling attention away, and the team had real architectural problems to fix. They decided a complete overhaul was the answer. New features, new interface, new publisher partnerships, shipped simultaneously.

The people who used Digg had spent years building habits around it. They knew where things were. They had learned the system. Version 4 replaced all of that with an interface that prioritized publisher content over user-submitted links, rearranged navigation people had memorized, and launched with enough bugs to make basic functions unreliable. Users did not wait around to see if it would improve. They left. Traffic dropped 26 percent the month after launch. Most of the people who left went to Reddit and stayed there. Digg sold in 2012 for $500,000. The company had been valued at $175 million at its peak.

Nobody at Digg wanted to destroy their product. They were trying to fix it. But they tried to fix everything at once, in one public launch, with no ability to roll back to something users already trusted. The scale of the redesign was the mistake, not the intention behind it.

The Five Problems Test

Before any redesign conversation gets traction, there is one thing worth doing. Write down the five specific problems the redesign is meant to solve. Not general frustrations. Specific, nameable problems. “Users abandon the checkout flow at the confirmation step at a rate of 38 percent” is a specific problem. “The product feels dated” is not. “First-time users cannot locate the core feature without assistance in 60 percent of sessions” is a specific problem. “The codebase is messy” is a complaint about working conditions, not a user problem.

If you can name five specific problems with evidence behind them, and you can show that they share a common structural root that cannot be fixed without rebuilding, then a redesign conversation is worth having seriously. If you cannot name five, you do not have a redesign problem. You have boredom, or frustration, or the specific discomfort of inheriting a system you did not build and would not have designed this way yourself. That discomfort is real. It is also not a brief.

The alternative is less exciting to present in a meeting. Pick the worst problem on your list. Fix it. Measure whether it improved. Pick the next one. This is slower, it never feels like enough, and it does not make for a good stakeholder slide. But the planning fallacy guarantees that the scope of any redesign will be larger than you estimated and the timeline longer. Fixing one real problem is a project you can finish. Fixing everything is a project that will still be running two years from now while the people who use your product keep working around whatever is broken.

The Product Is Not the Problem

The instinct to redesign is not irrational. When a product has been getting messier for two years, the desire to fix it for real is not wrong. What is wrong is the assumption that a clean slate is available. Every constraint that pushed the current product toward complexity will still be there when you start the new one. The stakeholders will ask for the same things. The edge cases will still exist. The timeline will still compress. The new product will accumulate its own version of everything you just escaped, and now you also have to manage the transition for every user who had adapted to the old one.

The product is not the problem. The belief that starting over would be different is.