

Jul 11, 2026
By Victor Teran
Why Your Redesign Did Not Move the Numbers
A redesign that does not move a single metric is one of the most expensive purchases in software, and one of the most common. The new interface is objectively better: cleaner, more modern, easier on the eyes. The team celebrates the launch.
Design
UX
Data
And three months later, activation, retention, and conversion sit exactly where they were.
I started as a designer, and for years I built beautiful interfaces that rarely moved the numbers. The reason became clear after enough founders came to me with a retention problem and asked for a redesign: the redesign was answering a different question than the one the data was asking. This post explains why redesigns fail to move metrics, and what a data-first redesign looks like instead.
Key takeaways
Because they redistribute attention evenly across the product while the problem is concentrated in one or two specific places the data could have named.
Diagnosis first, surgery second. Find the screen where the metric breaks, understand the stumble on that screen, and redesign that screen alone.
When the brand is the problem, when debt makes targeted work impossible, or after the targeted fixes have already moved the core metrics.
Why do most redesigns fail to change any metric?
Because they redistribute attention evenly across the product while the problem is concentrated in one or two specific places the data could have named.
A classic redesign treats the whole product: new visual language, new navigation, every screen touched. None of it tested against the task a real user is trying to complete. That evenness is exactly the problem. Users do not churn evenly across your product; they churn at specific moments. One onboarding step. One paywall placement. One screen where the next action is unclear.
When you redesign everything, the broken screen gets the same share of attention as forty screens that were working fine. Worse, it often gets fixed by accident or made prettier without addressing the actual stumble, because nobody watched users fail on it before drawing the new version.
There is also a measurement casualty: change everything at once and you cannot attribute anything. If retention ticks up two points after a full redesign, which change did it? You have spent your budget and learned nothing about your own product.
Designing without data is just decoration. It can absolutely be beautiful decoration. It just should not be expected to move a retention curve.
What does a data-first redesign look like?
Diagnosis first, surgery second. Find the screen where the metric breaks, understand the stumble on that screen, and redesign that screen alone.
The sequence we run at On the User inverts the traditional project. Before any screen is touched, analytics goes in (we use PostHog), a funnel maps the new-user path, and the steepest drop gets identified. Session replays of users failing at that step show the stumble in the wild.
Only then does design start, and it starts narrow: the screens implicated by the evidence, redesigned specifically to remove the observed stumble. The rest of the product keeps its familiar face, which users quietly appreciate.
Then the part that makes it real: the before and after, measured cleanly on the same funnel step across comparable cohorts. When we ran this with Q.AI, the diagnosis pointed at onboarding, the redesign touched those key screens, and the numbers answered immediately: activation from 38% to 67%, onboarding completion up 68%, support tickets down 73%. Not because the design was more heroic than a full redesign, but because it was aimed.
When is a full redesign actually justified?
When the brand is the problem, when debt makes targeted work impossible, or after the targeted fixes have already moved the core metrics.
Sometimes the full redesign is right. If your product's credibility gap is costing you at the top of the funnel, where enterprise buyers judge the screenshot before the feature, brand-level design is the fix and metrics like demo requests will say so. If years of UI debt mean no single screen can be fixed without touching ten, a foundational pass may be the prerequisite for any targeted work.
But sequence matters. Fix the metric-critical screens first, bank the wins, then do the aesthetic overhaul from a position where the funnel already works. A prettier leaking bucket is still a leaking bucket; a working bucket that then gets prettier is compounding.
If you have a redesign on the roadmap and are not certain the data supports it, that is a 30-minute conversation worth having first. Book a free Growth Teardown and we will show you what your data says should be redesigned, live: Book your teardown.
Situation | The right move |
|---|---|
One metric is broken and the data names the screen | Targeted fix on that screen alone |
The brand itself is the problem | Full redesign |
Technical debt makes targeted work impossible | Full redesign |
Targeted fixes have already moved the core metrics | Full redesign |
One more possibility is worth ruling out before either: that nobody can find the pages at all. We audited our own site and found Google had never crawled 20 of our 27 pages.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
WHAT NEXT
Want this fixed in your product, not just explained?


Jul 11, 2026
By Victor Teran
Why Your Redesign Did Not Move the Numbers
A redesign that does not move a single metric is one of the most expensive purchases in software, and one of the most common. The new interface is objectively better: cleaner, more modern, easier on the eyes. The team celebrates the launch.
Design
UX
Data
And three months later, activation, retention, and conversion sit exactly where they were.
I started as a designer, and for years I built beautiful interfaces that rarely moved the numbers. The reason became clear after enough founders came to me with a retention problem and asked for a redesign: the redesign was answering a different question than the one the data was asking. This post explains why redesigns fail to move metrics, and what a data-first redesign looks like instead.
Key takeaways
Because they redistribute attention evenly across the product while the problem is concentrated in one or two specific places the data could have named.
Diagnosis first, surgery second. Find the screen where the metric breaks, understand the stumble on that screen, and redesign that screen alone.
When the brand is the problem, when debt makes targeted work impossible, or after the targeted fixes have already moved the core metrics.
Why do most redesigns fail to change any metric?
Because they redistribute attention evenly across the product while the problem is concentrated in one or two specific places the data could have named.
A classic redesign treats the whole product: new visual language, new navigation, every screen touched. None of it tested against the task a real user is trying to complete. That evenness is exactly the problem. Users do not churn evenly across your product; they churn at specific moments. One onboarding step. One paywall placement. One screen where the next action is unclear.
When you redesign everything, the broken screen gets the same share of attention as forty screens that were working fine. Worse, it often gets fixed by accident or made prettier without addressing the actual stumble, because nobody watched users fail on it before drawing the new version.
There is also a measurement casualty: change everything at once and you cannot attribute anything. If retention ticks up two points after a full redesign, which change did it? You have spent your budget and learned nothing about your own product.
Designing without data is just decoration. It can absolutely be beautiful decoration. It just should not be expected to move a retention curve.
What does a data-first redesign look like?
Diagnosis first, surgery second. Find the screen where the metric breaks, understand the stumble on that screen, and redesign that screen alone.
The sequence we run at On the User inverts the traditional project. Before any screen is touched, analytics goes in (we use PostHog), a funnel maps the new-user path, and the steepest drop gets identified. Session replays of users failing at that step show the stumble in the wild.
Only then does design start, and it starts narrow: the screens implicated by the evidence, redesigned specifically to remove the observed stumble. The rest of the product keeps its familiar face, which users quietly appreciate.
Then the part that makes it real: the before and after, measured cleanly on the same funnel step across comparable cohorts. When we ran this with Q.AI, the diagnosis pointed at onboarding, the redesign touched those key screens, and the numbers answered immediately: activation from 38% to 67%, onboarding completion up 68%, support tickets down 73%. Not because the design was more heroic than a full redesign, but because it was aimed.
When is a full redesign actually justified?
When the brand is the problem, when debt makes targeted work impossible, or after the targeted fixes have already moved the core metrics.
Sometimes the full redesign is right. If your product's credibility gap is costing you at the top of the funnel, where enterprise buyers judge the screenshot before the feature, brand-level design is the fix and metrics like demo requests will say so. If years of UI debt mean no single screen can be fixed without touching ten, a foundational pass may be the prerequisite for any targeted work.
But sequence matters. Fix the metric-critical screens first, bank the wins, then do the aesthetic overhaul from a position where the funnel already works. A prettier leaking bucket is still a leaking bucket; a working bucket that then gets prettier is compounding.
If you have a redesign on the roadmap and are not certain the data supports it, that is a 30-minute conversation worth having first. Book a free Growth Teardown and we will show you what your data says should be redesigned, live: Book your teardown.
Situation | The right move |
|---|---|
One metric is broken and the data names the screen | Targeted fix on that screen alone |
The brand itself is the problem | Full redesign |
Technical debt makes targeted work impossible | Full redesign |
Targeted fixes have already moved the core metrics | Full redesign |
One more possibility is worth ruling out before either: that nobody can find the pages at all. We audited our own site and found Google had never crawled 20 of our 27 pages.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
WHAT NEXT
Want this fixed in your product, not just explained?


Jul 11, 2026
By Victor Teran
Why Your Redesign Did Not Move the Numbers
A redesign that does not move a single metric is one of the most expensive purchases in software, and one of the most common. The new interface is objectively better: cleaner, more modern, easier on the eyes. The team celebrates the launch.
Design
UX
Data
And three months later, activation, retention, and conversion sit exactly where they were.
I started as a designer, and for years I built beautiful interfaces that rarely moved the numbers. The reason became clear after enough founders came to me with a retention problem and asked for a redesign: the redesign was answering a different question than the one the data was asking. This post explains why redesigns fail to move metrics, and what a data-first redesign looks like instead.
Key takeaways
Because they redistribute attention evenly across the product while the problem is concentrated in one or two specific places the data could have named.
Diagnosis first, surgery second. Find the screen where the metric breaks, understand the stumble on that screen, and redesign that screen alone.
When the brand is the problem, when debt makes targeted work impossible, or after the targeted fixes have already moved the core metrics.
Why do most redesigns fail to change any metric?
Because they redistribute attention evenly across the product while the problem is concentrated in one or two specific places the data could have named.
A classic redesign treats the whole product: new visual language, new navigation, every screen touched. None of it tested against the task a real user is trying to complete. That evenness is exactly the problem. Users do not churn evenly across your product; they churn at specific moments. One onboarding step. One paywall placement. One screen where the next action is unclear.
When you redesign everything, the broken screen gets the same share of attention as forty screens that were working fine. Worse, it often gets fixed by accident or made prettier without addressing the actual stumble, because nobody watched users fail on it before drawing the new version.
There is also a measurement casualty: change everything at once and you cannot attribute anything. If retention ticks up two points after a full redesign, which change did it? You have spent your budget and learned nothing about your own product.
Designing without data is just decoration. It can absolutely be beautiful decoration. It just should not be expected to move a retention curve.
What does a data-first redesign look like?
Diagnosis first, surgery second. Find the screen where the metric breaks, understand the stumble on that screen, and redesign that screen alone.
The sequence we run at On the User inverts the traditional project. Before any screen is touched, analytics goes in (we use PostHog), a funnel maps the new-user path, and the steepest drop gets identified. Session replays of users failing at that step show the stumble in the wild.
Only then does design start, and it starts narrow: the screens implicated by the evidence, redesigned specifically to remove the observed stumble. The rest of the product keeps its familiar face, which users quietly appreciate.
Then the part that makes it real: the before and after, measured cleanly on the same funnel step across comparable cohorts. When we ran this with Q.AI, the diagnosis pointed at onboarding, the redesign touched those key screens, and the numbers answered immediately: activation from 38% to 67%, onboarding completion up 68%, support tickets down 73%. Not because the design was more heroic than a full redesign, but because it was aimed.
When is a full redesign actually justified?
When the brand is the problem, when debt makes targeted work impossible, or after the targeted fixes have already moved the core metrics.
Sometimes the full redesign is right. If your product's credibility gap is costing you at the top of the funnel, where enterprise buyers judge the screenshot before the feature, brand-level design is the fix and metrics like demo requests will say so. If years of UI debt mean no single screen can be fixed without touching ten, a foundational pass may be the prerequisite for any targeted work.
But sequence matters. Fix the metric-critical screens first, bank the wins, then do the aesthetic overhaul from a position where the funnel already works. A prettier leaking bucket is still a leaking bucket; a working bucket that then gets prettier is compounding.
If you have a redesign on the roadmap and are not certain the data supports it, that is a 30-minute conversation worth having first. Book a free Growth Teardown and we will show you what your data says should be redesigned, live: Book your teardown.
Situation | The right move |
|---|---|
One metric is broken and the data names the screen | Targeted fix on that screen alone |
The brand itself is the problem | Full redesign |
Technical debt makes targeted work impossible | Full redesign |
Targeted fixes have already moved the core metrics | Full redesign |
One more possibility is worth ruling out before either: that nobody can find the pages at all. We audited our own site and found Google had never crawled 20 of our 27 pages.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
WHAT NEXT


