Be clear about why you are redesigning
A redesign of a live app differs from a new design in one important way: people already use it. They have learned where things are. Some of them open it every day. A change that looks like an improvement on a designer's screen can feel like a rearranged kitchen to the person who cooks in it.
Sound reasons
- Users abandon a key task partway through
- Support requests repeat the same confusion
- New features no longer fit the navigation
- The app fails accessibility or platform expectations
- The design cannot be extended without inconsistency
Weak reasons, alone
- The team is tired of how it looks
- A competitor changed theirs
- A new brand guideline arrived
- A stakeholder dislikes a colour
- It has simply been a while
The reasons decide the measure of success. Write down which number should move: completion of a task, time to do it, support volume, store rating, retention. Without one, nobody can say afterwards whether the redesign worked.
Gather evidence before any design work
- 01
Read the analytics
Find where people drop out of your main flows, which screens are rarely visited and which features carry most of the use. Record current figures as the baseline.
- 02
Read reviews and support requests
Group them by theme. What people complain about in their own words is often different from what the team assumes.
- 03
Watch people use the app
Five or six sessions with real users, performing real tasks, reveal more than any report. Include long-standing users and newcomers.
- 04
Review against platform guidance
Check the app against current design and accessibility expectations for each platform: text size settings, contrast, touch targets, screen readers.
- 05
Audit the interface
List every screen and component. Inconsistencies found here become the brief for a design system.
A UX audit packages this evidence with priorities, and it often shows that a smaller change than expected would solve the problem.
Decide how deep the change needs to go
| Depth | What changes | Fits when | Risk to users |
|---|---|---|---|
| Visual refresh | Colours, type, icons, spacing. Structure stays | The app works but looks dated or off-brand | Low |
| Flow redesign | One or more key journeys are restructured | Evidence points to specific tasks that fail | Moderate, contained to those flows |
| Navigation redesign | The overall structure and menus change | Features have outgrown the original layout | High. Everyone must relearn |
| Rebuild | New technology underneath, with a new design | The code blocks progress as well as the design | Highest. Old behaviour can be lost |
Choose the shallowest depth that addresses the evidence. If the technology is the real obstacle, be honest that the project is a rebuild, and plan it as one. Our comparison of a UX audit and a full product redesign may help with the decision.
Protect what existing users rely on
Before changing anything, list the tasks that frequent users perform most. These are habits. For each, decide deliberately whether the redesign keeps it the same, makes it shorter or moves it. Moving a daily action needs a strong reason and a visible signpost.
- Keep the fastest paths fast. Count taps for the top tasks before and after. A redesign that adds a step to the most common action will be resented, however attractive it is.
- Keep data and settings. Saved items, preferences, sign-in state and history must survive the update without action from the user.
- Keep behaviour people cannot see. Offline handling, notification links and deep links from emails are easy to forget and painful to lose.
- Respect the platform. Use the navigation patterns of each operating system, so that the app behaves the way the rest of the phone does.
- Design for every setting. Large text, dark mode, right-to-left languages and small screens should be part of the design, not corrections after it.
A worked example
Redesigning a gym chain's member app
This example is invented to show evidence shaping scope. A gym chain wants a complete redesign of its member app because management feels it looks old.
- EvidenceAnalytics show that class booking is used by most members and that 4 in 10 attempts are abandoned at the timetable screen. The entry barcode, used daily, works well. Reviews mention the timetable repeatedly.
- DepthThe team chooses a flow redesign of booking and a visual refresh of everything else. Navigation stays, because nothing shows that members are lost.
- ProtectionThe entry barcode stays one tap from launch, in the same position. Saved favourite classes carry over.
- ReleaseThe new booking flow goes to a tenth of members for two weeks. Abandonment in that group falls by half, with no rise in support requests, and it is released to everyone.
- Result measuredA month later, bookings made in the app are up and the store rating has improved. The visual refresh follows in the next release.
The project cost a fraction of the complete redesign first requested, and it fixed the one thing members were struggling with. The barcode, which a full redesign would probably have moved, was never touched.
Release in stages and keep a way back
A redesign released to every user on one day is a bet with no hedge. Both app stores offer ways to limit the bet, and the app itself can offer more.
- 01
A beta group
What it gives youVolunteers who see the new design first, through the stores' testing channels, and tell you what is wrong before the public does.
- 02
A phased store release
What it gives youBoth stores document options for releasing an update to a growing share of users, with the ability to pause.
- 03
Switches inside the app
What it gives youNew flows that can be turned on for a share of users, and off again from the server, without waiting for a store review.
- 04
A comparison group
What it gives youUsers still on the old design give you a fair measure of whether the new one is better.
- 05
An explanation
What it gives youA short, skippable note on first open that shows what moved. For large changes, tell users in advance.
Measure, listen and finish the job
In the first days after any visible change, some users will complain because it is different. That reaction fades. What matters is the measure you chose at the start, compared with the baseline, and compared with the group that did not receive the change. Watch support requests and reviews by theme, and be ready to correct quickly.
Then finish. Many redesigns ship the main screens and leave settings, error states and rarely visited corners in the old style. An app in two styles looks neglected. Building from a shared set of components, as described on our design systems page, makes it practical to bring every screen across.
App redesign checklist
Mobile app redesign checklist
0 of 11 checkedWhat to do next
Open your analytics and find the single task with the worst completion. Then read the last fifty store reviews. If both point the same way, you have your scope. If they do not, watch five people use the app before deciding anything.
Where the app's code is also holding you back, our mobile app modernization page covers redesign and rebuild together. Tell us what your users are struggling with and we will suggest how deep to go.
Common questions
How often should a mobile app be redesigned?
There is no schedule worth following. Redesign when evidence shows that users are failing at something, when new features no longer fit the structure, or when the platforms have moved on. Between those moments, small continuous improvements serve users better than periodic overhauls, and they avoid forcing everyone to relearn the app.
Will users be upset by a redesign?
Some will, briefly, because familiar things have changed. The reaction is smaller when daily actions stay where they were, when the change clearly makes a task easier and when it is explained. A staged release shows you the scale of the reaction early. Lasting complaints about a specific screen are evidence, and deserve a response.
Should we redesign and rebuild at the same time?
Only if the technology truly prevents the design you need. Combining both changes everything at once, which makes problems hard to trace and lengthens the project. Where possible, separate them: improve the design on the current code, or rebuild with the existing design and change it afterwards. If they must be combined, release flow by flow.
How do we know whether the redesign worked?
By comparing the measure you chose at the start with its baseline, ideally against a group of users who stayed on the old design for the same period. Task completion, time taken, support requests on the affected screens and retention are the usual candidates. Store ratings and opinions help, but they follow the numbers and are slower.
Do iOS and Android need separate designs?
They should share the structure, content and brand, and differ where the platforms differ: navigation patterns, system controls, typography and gestures. Users expect an app to behave like their phone. A single design forced identically onto both platforms usually feels foreign on at least one of them.
