A redesign feels exciting inside the team. For the people who use the product every day, it often feels like someone moved the furniture in their office overnight.
That is the main risk when you redesign a SaaS product. Your new screens may be better. But users have habits, and habits cost them time to build. If you break those habits all at once, even a good change can look like a bad one.
Here is how we think about it when a product is already live.
Know what users rely on
Before you draw anything new, find out what people actually do in the product today. Not what the team thinks they do.
Three sources help most:
- Analytics. Which screens get visited every week? Which buttons get clicked? Which features have almost no traffic?
- Support tickets and sales calls. What do people ask for help with? What do they complain about? What do they say they would never give up?
- Short calls with real users. Five or six calls with long-time customers will teach you more than a month of guessing. Ask them to show you how they use the product on a normal Tuesday.
From this, make a short list of the paths people rely on. For most SaaS products it is five to ten things: log in, find a record, create a record, export, invite a teammate, change billing. Write them down. This list becomes your safety rail. Whatever you change, these paths must stay easy to find and quick to finish.
It also helps to list what nobody uses. Cutting a screen that gets no visits is usually safe. Cutting a screen that gets few visits from your biggest customers is not. Look at who uses a feature, not only how often.
If you are not sure where the problems are, a short review before the redesign can save weeks. That is the idea behind our UX audit: a fixed-price look at the key flows, with a ranked list of what to fix first.
Stage the change
A big-bang launch puts all the risk on one day. If something goes wrong, you cannot tell which change caused it, and you cannot roll back one piece without rolling back everything.
Staging is slower on paper and safer in practice. A simple order that works for many products:
- Visual foundation first. New type, colors, spacing and components. The layout stays the same. Users see a cleaner product, but every button is where they left it.
- Fix the worst flows next. Pick the one or two flows that hurt most, such as onboarding or checkout, and change them on their own.
- Change navigation last. Moving the main menu is the change users notice most. Do it once the rest is stable, and do it with care.
Each step ships alone, so you can see how users react before you take the next one. This is also how we run larger redesign work in our process: small releases, not one reveal.
Keep muscle memory
Daily users do not read your interface. They move through it by habit. They click the same spot, press the same keys, scan to the same corner for the same number.
So treat these things as expensive to change:
- The position of the main navigation
- The names of key features and menu items
- Keyboard shortcuts
- The place where the primary action lives on a screen
- Table columns and default sort order that people use every day
This does not mean nothing can move. It means every move needs a reason you can say out loud. "It looks nicer" is not enough. "New users could not find it, and we are putting a clear label on it and keeping the old shortcut" is a reason.
When you must change something big, give people a bridge. Keep the old name as a small hint for a while. Add a short tip the first time they hit the new screen. Let the old shortcut keep working next to the new one.
Beta and opt-in
Do not make everyone switch on the same day. Let some people try the new version first.
A common order:
- Internal team. Your own staff use the new version for real work first. They will find the embarrassing bugs.
- A small group of friendly customers. People who have told you they like talking to you. Ask them for honest feedback, and watch them use it if you can.
- Opt-in for everyone. Add a switch such as "Try the new version". Keep a way back to the old one for a set period.
- Default to new, with an opt-out. Once most people have moved and the complaints have slowed, make the new version the default.
- Retire the old version. Announce a date early, then keep it.
The "way back" matters more than it looks. People are much more willing to try something when they know they can leave. Keep a short feedback box on the switch, so you learn why people go back.
One honest cost: running two versions takes engineering time. Plan for it, and set an end date so the old version does not live forever.
Communicating changes
Surprise is what makes users angry. Most people accept a change they were told about. Few accept a change they discovered by accident.
Tell people early, and tell them in more than one place:
- An email before the change. Say what is changing, when, and why it helps them. Keep it short. Link to a page with details.
- An in-app note. A small banner or a one-time tooltip, shown where the change happens.
- A "what moved" page. A simple list: old place, new place. Screenshots help. Support will thank you.
- A short video. Two minutes of screen recording often does more than a long help article.
- A note for your support and sales team. They should hear about it before customers do.
Write like a person. Say "we moved Reports into the main menu because many of you could not find it". Do not write "we are excited to announce an enhanced experience".
Also tell people what is not changing. If their data, links and saved views all stay as they are, say so. That calms more worry than any promise about the new look.
Measuring the result
Decide before launch what success looks like, and what would make you pause. Pick a few measures tied to your must-keep paths:
- Do people still finish the key tasks, and how long do they take?
- Are support tickets about the changed area going up?
- Are users switching back to the old version, and what do they say when they do?
- Are active accounts staying active in the weeks after the change?
Expect a short dip. People slow down when something is new, even if it is better. What matters is whether the numbers recover, and whether the people you worry about most, your long-time and high-value users, recover too.
Look at the words as well as the charts. A handful of angry emails can point to a real problem that averages hide. Read them all in the first two weeks.
A short checklist
- List the paths users rely on, and protect them.
- Ship the visual layer first, navigation last.
- Offer opt-in with a way back.
- Tell users early, in more than one place.
- Set the success measures before you launch.
If you have a live product and want a second pair of eyes before you start, we do this kind of work for SaaS teams. The free design review is a good first step: send us one flow at /contact and we will record a short video review.
