How do you redesign a live SaaS product without losing users?

Insights · Guide

Redesign in slices, not one switch. List what current users have learned and built around the product, decide per capability whether to keep, adapt, replace or leave it alone, test with current users as well as new ones, then release to a small group first with a way back and a written pass rule.

This guide is about software people use to do their jobs and that you intend to keep running while you change it. It is not about a first version of a product, and it is not about a rebuild on a new foundation. For the second case, start with preserve, redesign, replatform or retire, which decides what happens to each capability before anyone picks a technical route.

Why existing users are the risk, not the design

A redesign is judged by people who already know how the old product works. That is a central difficulty.

Two pieces of research describe the cost to them. In a study of new system acceptance in MIS Quarterly, Polites and Karahanna reported in 2012 that habitual use of the incumbent system, perceived transition costs and perceived sunk costs build inertia. That inertia lowered how easy and how advantageous people judged the new system to be, and it lowered their intention to use it. A 2022 laboratory study from HEC Montréal, Wang and colleagues, had current users of a mobile banking app do tasks on the existing and an updated version. Where the update disrupted familiar steps, they showed greater cognitive load, perceived effort and task time, and judged navigation worse for familiar tasks.

Treat that second study as a neighbouring result, not direct proof. It is one lab experiment, in consumer banking, reported as a conference paper. Our inference is that the same mechanism applies, and likely more strongly, to a work product where customers have also built saved views, reports, integrations, shortcuts and internal procedures around the current behaviour. We have not seen a study that measures that directly.

The practical consequence is a change of question. Do not ask whether the new design is better in a vacuum. Ask whether it is better by enough to be worth what each existing user must relearn, capability by capability.

Decide how deep the redesign goes

"Redesign" covers very different amounts of change. Match the depth to what is actually wrong, and leave alone what is not.

This is the scale Tcules uses on its product redesign page. The last row matters for retention. Every screen you do not touch is a screen no user has to relearn.

A way to find the right row is to follow the work before redrawing anything. Repeated data entry can come from disconnected records. A crowded dashboard can be compensating for unclear task status. A spreadsheet export can be standing in for a comparison the product cannot show. If the cause is structural, a visual refresh will keep the fragmented behaviour and add relearning on top.

Write down what users have built around the product

Before design starts, record what existing users depend on, one capability at a time. Tcules calls this a continuity ledger. In our view, a plain spreadsheet is enough. For each capability, write down five things: what existing users have learned, what is failing for them today, what will change, how people and data will move from one to the other, and what evidence must be in before the next rollout stage.

Then assign each capability one of five dispositions: preserve, adapt, replace, retire or leave unchanged. Use this checklist to find what belongs in the ledger.

Two rules keep the ledger honest. Anything marked "replace" needs a reason that a customer would accept, not only a reason the team prefers. And the person who owns the ledger should be someone who talks to support, because support sees the exceptions that design files omit.

Test with the people who stand to lose something

Test changed tasks with two groups, because they answer different questions. Existing users show what the change disrupts: the habit that no longer works, the saved view that no longer opens. People new to the product show whether the new structure is understandable without learned workarounds. A test with only one group tells you only part of what you need.

Add a third source: the people who handle failures. Support and customer-success teams know the recovery paths and the exceptions, and a redesign that handles the normal route well can still strand someone on the abnormal one.

For a B2B product, there is a stronger version of the test, which is a pilot with real customers using the new design in their real work. Slack's team described this for its 2020 redesign. Slack designers worked with about 100 users from its champion network, across dozens of organisations, in a shared channel, and could ship a revised version within a day of hearing feedback. The pilot and a separate benchmarking study with people who had never used Slack changed the design. In that benchmark, participants ignored a compose button placed at the bottom of the sidebar, so it moved to the top. The team had tucked channel member counts behind a click, then found that people use them to judge how to behave in a channel. Right-click actions were made more comprehensive after testing and pilot feedback. Views such as the people directory that started collapsed were opened by default after people unfamiliar with the product missed them.

These findings came from people using working prototypes, not from reviewing screens: pilot customers over weeks and months, and first-time users doing set tasks.

Release in stages with a way back

A redesign that is finished and tested still carries some risk that only live use reveals. Reduce it by controlling who sees the change and by deciding in advance what would stop it.

Start small and compare. Google's Site Reliability Workbook defines canarying as a partial, time-limited deployment of a change together with its evaluation, against a control that does not get the change. Two of its points transfer to a redesign. The canary has to be large enough and last long enough to be representative. And metrics should be broken out by version, because a serious problem that affects a small share of traffic can be diluted in a system-wide average. For a redesign, the same logic says to compare the group with the new design to the group without it, not to watch a single total.

Widen in rings, with a pass rule for each. A 2019 Microsoft case study describes what its authors call controlled rollout, which treats each ring of a phased rollout as a measured experiment and defines the criteria to pass before the rollout widens. Write the rule before launch, so the decision to widen is not made by whoever is most excited or most anxious on the day.

Read early numbers carefully. Effects in a controlled test are not always stable over time. Sadeghi and colleagues at Microsoft describe novelty, an initial interest in something new that fades, and primacy, a growing engagement as people adopt it. For a redesign, our inference is that a first-week dip or lift is not a verdict. An opt-in group can also differ from your whole customer base, so a good result in a beta does not carry over by itself to customers who did not choose to try it.

Give people a way back, and learn from who takes it. When Figma released its redesigned interface, it ran an open beta first, gave users a way to revert, and tracked feature adoption, performance and feedback. The team reversed one of its own design choices before full release: floating panels, which it found cramped the canvas and slowed people down, became fixed panels that can still be resized. Our inference is that a revert option can show where the design fails, as long as you read it as evidence and not as a loyalty vote.

What to watch. A starting set for each ring:

In a B2B product, also decide who controls the timing. Giving account administrators notice and a choice of when their workspace switches is our recommendation, not a finding from the sources above, but it follows from the ledger: they are the people who own the saved views, training material and procedures.

One design that changed one branch

Selective change is easier to see in a small case. In Dealpath, institutional real estate software, adding a listing to the pipeline opened a new-deal flow before checking whether the deal already existed. In Tcules' Dealpath work, that order was reversed in the proposed design: the user searches existing records first and creates a new deal only when there is no suitable match. The other listing actions, which are viewing details, marking comparables and passing, were left substantially intact, because the structural problem sat in the pipeline path. Dense listing information also got a clearer reading order.

The case shows the shape of the argument in this guide: one structural fix, with the rest of what users knew left alone. It is not evidence of a rollout method or of a business result, and the case page claims neither and does not confirm which version shipped.

When a redesign is the wrong tool

Hold the redesign back when any of these is true.

• The foundations block the change. If the behaviour you want cannot exist on the current data model or platform, a redesign is likely to stall in development. Decide the modernisation question first.
• There are no established users yet. Without existing habits to protect, this is a product design problem, and the continuity work above has nothing to record.
• Stakeholders disagree about the cause. Settle whether the problem is the screen, the workflow or the product model before choosing a depth. A written diagnosis from an audit is one way to settle that before committing to a redesign.
• The pain is small and the area is stable. Leaving it unchanged is a legitimate result of the ledger.

What to ask a design partner before you hire one

Buyers may also ask which agencies to hire for a product redesign. A list of names will not tell you whether a partner can protect your existing users. These questions will.

1. What did you leave alone on a comparable project, and why? A partner who redesigned everything may not have made the preserve-or-replace decision.
2. How do you test with existing users, not only new ones? Look for a plan that includes both groups and support staff.
3. What goes in the continuity record, and who keeps it? There should be an artefact, with an owner on your side.
4. Who owns implementation and rollout? Design only, design carried through to code, and an agreed software scope are different engagements. The answer should be settled before the redesign reaches production.
5. What would make you advise against a redesign? A credible partner has an answer, such as the cases in the section above.
6. What will we have at each decision point? You want evidence for the next commitment, not a deliverable list.

Tcules works on this kind of change for established B2B SaaS products. The product redesign page sets out the depth options, the continuity ledger and the rollout reasoning in more detail, and a good first step is to bring one part of the product customers have built work around, one part that now creates sales, support or operating cost, and the change the business needs to make.