Sevginur Ak Parlak
Aug 12, 2026
12 min read
SaaS Product Redesign: How I Rebuild an Existing Product Without Losing Users
In May 2024 Sonos shipped a rebuilt app. The company had promised that all existing functionality would stay the same. What shipped was missing sleep timers, local library management, queue editing and accessibility support for blind users. Between 6 May and 1 August the share price went from $17.88 to $13.09, a fall of about 25 percent, and the company delayed hardware launches to repair the app.
I bring this up in almost every redesign kickoff, not to scare anyone, but because it is the clearest public example of the thing that actually goes wrong. The new interface was not ugly. The team did not lack talent. They shipped a replacement for a product people already depended on, all at once, with holes in it.
Most SaaS redesigns I inherit carry the same risk in a smaller form. So this post is how I run a redesign of an existing product with real users on it: when I think you are ready, how I scope it, how we ship it in stages, what it costs in 2026, and the 6 things that reliably cost you users.
First, the word redesign means 4 different projects
When a founder writes to me asking for a redesign, my first job is finding out which of these they mean, because the price and the risk differ by a factor of 10.
Visual refresh.
Colours, typography, spacing, icons, component styling. The information architecture and the flows stay exactly as they are. Nothing moves, so nothing has to be relearned. This is the lowest risk work in the list and it is often enough when the complaint is that the product looks like it was built in 2019.
Interface redesign
The screens are reorganised, the navigation changes, the components are rebuilt on a proper token layer, but the underlying product model stays. Users still do the same jobs with the same objects, just faster. This is the scope most teams need when they ask me for a rebuild.
Experience redesign
The flows change. Steps get removed, merged or resequenced, and the way people accomplish a job is different afterwards. This one requires research before design, because you are changing behaviour, not appearance.
Rebuild
The product model itself changes. New objects, new permissions, new mental model. This is a new product wearing the old name, and it deserves the process I use for new products rather than a redesign process.
I have seen teams buy a visual refresh and expect an experience redesign, and I have seen the opposite, which is more expensive. Deciding this in week 1 is the single most useful hour of the project.
Signs you are actually ready for a SaaS redesign
I look for evidence, not opinions. A redesign that starts because a new VP does not like the interface tends to end badly. These are the signals I trust.
Support tickets cluster on the same 3 screens
When 40% of your tickets come from 3 places in the product, that is a design problem with a measurable size. I ask for a tag export before I quote anything.
Activation is fine and retention is not
People sign up, complete setup, and stop returning in week 2 or 3. That pattern usually means the daily use case is harder than it needs to be, which is exactly what an interface redesign fixes. If activation itself is broken, the smaller project is onboarding.
Your sales team is losing deals on the demo
In B2B this is a hard signal. If prospects say the product looks dated or complicated during the call, and the same objection comes back 5 times in a quarter, the interface is now a revenue problem.
The product grew by addition for 2 or more years
Every feature got a tab, every tab got a settings page, and nobody removed anything. This is the most common reason a healthy company needs a redesign. The product is not bad, it is 30 good decisions that never got reconciled.
Engineering slows down on interface work
When a small UI change takes 3 days because there are 4 versions of the same table, the cost is now in your roadmap. That is usually a design system problem sitting inside a redesign project, and it changes the scope: you are not only redrawing screens, you are rebuilding the component layer underneath them.
When I tell teams not to redesign
I say this more often than people expect from a design studio.
If you cannot name the metric that should move, do not start. A redesign without a target is a taste project, and taste projects have no end condition.
If the product model is about to change, wait. Redesigning the interface of a product whose object model changes in 2 months means paying for the same screens twice.
If churn is caused by pricing, missing integrations or a weak core value, a redesign will not fix it and it will consume the quarter you needed for the real fix. I ask to see cancellation reasons before I agree that design is the constraint.
If you have never run a UX audit, do that first. It costs a fraction of a redesign, it takes 1 to 2 weeks, and in maybe 1 case out of 3 the finding is that 6 targeted fixes will get most of the value. You do not need a large study to find the first problems, as I argued in you don't need a huge study to find the first UX problems.
Baseline first, or you will never know if it worked
This is the step teams skip, and skipping it is how a redesign becomes an argument about opinions 6 months later.
Before I touch a single screen, I want numbers written down and dated. Not perfect analytics, just the honest current state.
I collect activation rate, week 4 retention, the completion rate and time on task for the top 3 workflows, ticket volume per screen, and 1 qualitative baseline: 5 recorded sessions of real users doing their real work. 5 sessions is not statistically significant and it is not supposed to be. It is the reference material I return to in week 6 when someone claims users will not understand the new navigation.
I also record the parts people love. This matters more than it sounds. Every product has 2 or 3 behaviours that power users depend on, often ugly ones, like a keyboard shortcut or a bulk edit that lives in a weird place. Those are the features that generate the loudest anger when they disappear. In the Sonos case the missing pieces were exactly this category: alarms, local libraries, queue editing. Boring, unglamorous, load bearing.
So my rule is simple. Anything that appears in the top 20 percent of usage does not get removed in a redesign. It can move, it can look different, it cannot vanish.
How I run a redesign, phase by phase
This is a 10 to 14 week shape for a mid size B2B SaaS product. Smaller products compress it, enterprise products with 5 user roles extend it.
Weeks 1 to 2: baseline, audit, and scope
I inventory the product screen by screen, count the components in Figma and in code, read the support tags, watch the sessions, and interview 4 or 5 internal people who talk to customers daily. The output is a problem list ranked by frequency and cost, plus a scope decision from the 4 options above.
I also write the deprecation list here: what we intend to remove, and the evidence for each removal. Founders often want this list longer than the data supports. Negotiating it in week 2 is much cheaper than in week 11.
Weeks 3 to 5: structure and flows
Information architecture, navigation model, and the 3 or 4 core flows redrawn at low fidelity. No colour, no final components. I test the navigation model with 5 users, including at least 2 existing customers, because existing users and new users fail in completely different places. New users get lost, existing users get frustrated that a known thing moved.
This phase is where an experience redesign either earns its budget or reveals that the interface redesign scope was correct all along.
Weeks 6 to 10: interface and system
Now the components, the tokens, the states, and the real screens. I build against real data, not placeholder text, because the tables in a B2B product break on the customer with 400 line items and 60 character names, never on the tidy example. If you are setting up the token layer at the same time, our case study on using variables in Figma covers how I structure that.
I also design the states most redesigns forget: empty, loading, error, permission denied, and the migration state where old data meets the new interface.
Week 11 onward: staged rollout
Design does not end at handover. This is where the redesign either keeps your users or does not, and it is the part I insist on staying involved in.
Shipping a redesign without losing users
Every redesign that hurt a company badly shared 1 property: it replaced the old product for everybody on the same day. The fix is not better design. It is a slower release.
Stage 1: internal
Your own team uses the new interface for their daily work for at least 1 week. Support and sales find things designers never will, because they use the product under time pressure.
Stage 2: opt in beta
A visible switch, roughly 5% of active accounts, with a real feedback path and, critically, a way back to the old interface. The switch back is not a failure, it is your instrumentation. When 30% of beta users switch back within 2 days, you have a specific problem and 2 weeks to find it. When 5% switch back, you are close.
I look for volunteers among engaged users first, not the loudest complainers and not the dormant accounts. Engaged users notice missing details fastest.
Stage 3: staged default
New signups get the new interface by default, existing accounts move in cohorts, smallest first. Enterprise accounts with training material and internal documentation move last and get notice, usually 30 days. In B2B, the person who has to rewrite their internal onboarding deck because of your redesign is the person who will complain to your account manager.
Stage 4: deprecate
The old interface stays available for a defined period, then it goes. Announce the date once, remind twice, do not extend it repeatedly, because a permanent 2 version state doubles your maintenance and your QA forever.
Across all 4 stages, 2 practical rules. Never bundle a pricing change or a big feature removal with a redesign, because users will attribute both to the redesign and the anger compounds. And communicate what stayed the same, not only what improved. Users of an existing product mainly want reassurance that their work still works.
The 6 things that break retention in a redesign
From projects I have run and ones I have been asked to repair afterwards, in the order I see them.
A load bearing feature disappeared.
Almost always something small used by 10 to 20 percent of users daily. This is cause number 1 by a wide margin.
Muscle memory was reset for no gain.
Moving a frequently used control is a real cost to every existing user. It has to buy something measurable. Moving things because the new layout is tidier is not a reason.
Speed regressed.
New interfaces are often heavier. If the main screen loads 400 milliseconds slower, some users will describe the redesign as worse and never mention loading times.
The migration state was never designed.
Existing data in the new interface looks wrong: legacy fields, long names, empty new columns, defaults nobody chose. Users conclude their data broke.
Nobody was told.
A product that changes overnight with no announcement, no what is new, and no help content reads as a bug.
Integrations and shortcuts silently changed.
Keyboard shortcuts, saved views, browser bookmarks to deep links, API shaped expectations. These break quietly and generate tickets that never say the word redesign.
What I measure after launch
The baseline from week 1 is what makes this possible. I compare at 2 weeks and at 8 weeks, because the first 2 weeks always look slightly worse. Existing users are relearning, and a small dip is a relearning curve, not a failure. What matters is whether it recovers and passes the old line by week 8.
I track task completion rate and time on task for the top 3 workflows, week 4 retention for cohorts on the new interface versus the old, ticket volume per screen, and the beta switch back rate while it is still available.
1 warning about the dip. Teams panic in week 2 and start reverting decisions individually, which produces an interface that is half old and half new and worse than both. I agree in advance what counts as a real regression: a metric that is worse at week 4 than baseline and is not improving week over week. Everything else waits.
FAQ
What is a SaaS product redesign?
It is the rework of an existing software product's interface, and sometimes its flows and structure, while real users continue to use it. It differs from designing a new product because the main constraint is not the blank page, it is not breaking the work of people who already depend on the product.
How do I redesign a product without losing users?
Baseline your metrics before starting, never remove features used by more than 20 percent of users, and release in stages: internal use, opt in beta with a way back to the old interface, cohort by cohort default, then deprecation with a fixed date. Keep the frequently used controls where people expect them unless moving them buys something measurable.
How long does a product redesign take?
1 to 2 weeks for an audit and plan, 3 to 5 weeks for a visual refresh, 8 to 14 weeks for an interface redesign, and 14 to 22 weeks for a full experience redesign with research. Staged rollout runs after that and typically adds 4 to 8 weeks.
Should we redesign or run a UX audit first?
Run the audit first in almost every case. It takes 1 to 2 weeks, it costs a fraction of a redesign, and it tells you which of the 4 redesign scopes you actually need. In about 1 case out of 3 the audit finds that a set of targeted fixes gets most of the value without a redesign.
Is it normal for metrics to drop after a redesign?
A small dip in the first 2 weeks is normal, because existing users are relearning the interface. Define in advance what counts as a real regression, for example a metric that is still below baseline at week 4 and not improving. Reverting individual decisions in week 2 usually produces something worse than either version.
Should we redesign and rebrand at the same time?
Only if the rebrand is already decided and finished. Bundling a rebrand, a pricing change and a redesign into 1 release means you cannot tell which change caused which reaction, and users attribute all of it to the redesign.
Can we redesign in parts instead of all at once?
Yes, and I recommend it for products with paying users. Pick 1 self contained area, redesign and ship it, learn from the reaction, then continue. The token layer and component system make the parts consistent even though they arrive months apart.
Working with us
We redesign SaaS and B2B products that already have users, which is a different job from designing a new one. We start with a 1 to 2 week audit and baseline so there is a number to compare against, we agree the scope out of the 4 above before any screen is drawn, and we design against your real data instead of sample content.
We stay involved through the staged rollout, because that is where redesigns succeed or fail, and we hand over with the component system, the migration states and the deprecation plan documented rather than a folder of screens.
Sometimes our recommendation after the audit is smaller than the project you came to buy. That is worth knowing before you commit a quarter to it. Book a free 15 minute intro call, show us the 3 screens your support tickets talk about most, and we will tell you which scope we think you need. If you are still comparing partners, we also wrote about how to choose the best UX/UI design studio for your startup, and about our product design process for early stage startups.
