# When a redesign is the wrong answer > A full redesign resets everything you know about your product, including the things that were working. Here is when that trade is worth it. *Published 2026-05-19 · 8 min read · Strategy, Product* Source: https://www.linesandframes.com/blog/when-a-redesign-is-the-wrong-answer ## The short version - A redesign buys coherence: it lowers the cost of the next decision. It does not reliably move a specific number. - If the complaint is a metric, the fix is usually local — a screen, a sentence, a removed field. - Redesign when new features have no obvious home, or the interface contradicts the positioning. - Sequence it: foundations first, then surfaces by risk, tolerating old and new side by side. A redesign is the most satisfying project to sell and the easiest to justify internally. It is also the one most likely to destroy information. Every metric baseline, every learned behaviour, every support answer that starts with "click the third tab" becomes invalid on launch day. ## What a redesign actually buys It buys coherence. When a product has accreted five years of features in three visual languages, the cost of every new decision rises: nothing has an obvious home, and each addition makes the next one harder. A redesign resets that cost. That is a real and sometimes urgent benefit, and it is a different benefit from "improve conversion". Being precise about which benefit you are buying determines how you should measure success. Coherence shows up as design and engineering velocity, and as fewer arguments per launch. It does not reliably show up in next quarter's signup rate, and promising that it will is how redesigns get judged a failure despite working. ## Signals that it is the right call - New features have no obvious place to live, and every launch triggers a layout argument. - The interface contradicts the positioning you now sell — enterprise pricing, prototype polish. - Multiple design languages coexist and nobody can say which one is current. - The underlying model changed: what was one object is now three, and the navigation still pretends otherwise. - Onboarding has to explain the interface before it can explain the value. Notice that all five are structural. They describe a product whose shape no longer matches what it does — which is exactly the problem a redesign is good at. ## Signals that something smaller will do If the complaint is a number — signups, activation, churn on a specific plan — the fix is almost always local. Numbers move in response to a specific screen, a specific sentence, a specific removed field. A redesign changes all of them at once, which means it also destroys your ability to know which change did the work. > Redesign when the cost of the next decision is too high. Iterate when a number is too low. The uncomfortable version of this: a redesign is often chosen because it is easier to get funded than a quarter of unglamorous local fixes. That is an organisational problem wearing a design brief, and it usually ends with a beautiful product and the same metrics. ## If you do it, sequence it The version that goes badly ships everything at once behind a flag and a launch date. The version that goes well establishes the new foundations first, then migrates surfaces in an order set by risk, keeping the old and new comprehensible side by side for longer than feels elegant. 1. Foundations: tokens, type scale, spacing, layout primitives. Nothing user-visible ships yet. 2. One low-risk, high-traffic surface, to prove the foundations under real conditions. 3. The surfaces where the old model actively hurts — usually navigation and the object that changed. 4. Everything else, in whatever order suits the roadmap. 5. Removal: delete the old system, or you now maintain two. Step five is the one teams skip, and skipping it converts a redesign into permanent duplication — the exact condition the redesign was meant to end. ## Protecting what already worked Before anything changes, write down the behaviours you must not break: the shortcut power users rely on, the URL people bookmark, the report someone exports every Monday. Redesigns rarely fail on aesthetics. They fail because something small and unglamorous disappeared, and the people who depended on it were the ones paying you. ## Questions we get asked ### How do you know when a product needs a redesign? When the cost of the next decision is too high: new features have no obvious home, multiple design languages coexist, or the interface contradicts what you now sell. If instead a specific metric is too low, a local change will teach you more and risk less. ### How long does a product redesign take? The honest answer depends on whether you sequence it. Establishing foundations and migrating surfaces by risk takes longer on the calendar but ships value earlier and keeps your metrics interpretable. A single big-bang release is faster to plan and far more expensive to be wrong about. ### Should we redesign all at once or incrementally? Incrementally, in this order: foundations first with nothing user-visible, then one high-traffic low-risk surface to prove them, then the surfaces where the old model actively hurts, then everything else, then delete the old system. Skipping that last step turns a redesign into permanent duplication. ### How do you avoid losing conversion after a redesign? Write down the behaviours you must not break before anything changes — the shortcut power users rely on, the bookmarked URL, the Monday report — and keep instrumentation on those specifically. Redesigns rarely fail on aesthetics; they fail because something small disappeared. --- © Lines & Frames — https://www.linesandframes.com