Mobile App Redesign in New Zealand

Look at the data before anyone draws anything

An established app has something a new one does not: months of evidence about what people actually do. Ignoring it in favour of a fresh design is the most expensive mistake available here.

Before any design work, find out:

• Which screens are used most, and which are effectively dead.
• Where people abandon the main task, and at which step.
• How long the common journey takes, and how many taps.
• What the one-star reviews say. They are free research and they are specific.
• What your support inbox is asked most often.

Then watch five people use it. Not a focus group — five actual users, doing a real task, while somebody stays quiet and takes notes. It reliably finds something no analytics package will show.

Ask each firm whether this is in their proposal. A design engagement that starts with wireframes is guessing with your install base.

Usually the problem is not how it looks

"The app looks dated" is what gets the project funded. It is rarely what is actually costing you.

What normally turns out to be wrong:

• The thing people came to do takes six taps and should take two.
• Five years of features have been added to a navigation designed for three.
• Signing in is harder than it needs to be, and that is where new users vanish.
• Errors are unhelpful, so people give up rather than correct something.
• It is slow on a mid-range Android, which is most of the market.

A visual refresh fixes none of that and costs $30,000. Establish which problem you have before choosing what to buy.

Move things deliberately, not enthusiastically

Your regular users have muscle memory. They tap where the button is without reading. A redesign that relocates everything at once produces a wave of one-star reviews from people who used the app daily and can no longer find what they used it for.

The disciplined approach:

• Keep frequently used actions where they are unless there is a specific reason to move them.
• Change one area at a time across successive releases where you can.
• Where something has moved, say so in the app once — briefly.
• Accept that a design which is objectively better can still cost you users in the short term, and plan for that.

Insist on a staged release

This is the most important line in the quote and it is often absent.

Both stores support phased rollouts: release to a small percentage first, then increase. That gives you a fortnight to watch retention, crash rates, reviews and support volume before everyone has it — and a way back if something is wrong.

Agree in advance what would cause you to halt: retention falling by more than an agreed amount, crashes rising, or a specific complaint appearing repeatedly. Deciding that beforehand is far easier than deciding it while reading angry reviews.

Design for each platform, even from one codebase

A design created once and applied identically to both platforms usually satisfies neither.

The differences that matter:

• Where navigation lives, and whether the edge swipe goes back.
• Date and time pickers, which look quite different.
• The share sheet and system dialogs.
• Typography and spacing conventions.
• Scroll behaviour, which iPhone users notice without being able to name it.

Ask to see the design applied to both platforms before it is built, on a real device rather than in a presentation.

Redesign, or rebuild?

Redesign when the app works and the technology underneath is still supported.

Rebuild when the framework has been abandoned, when the app cannot meet current store requirements, when every small change is disproportionately expensive, or when it was built for one platform and you now need both.

Ask each firm to look at the code before quoting a redesign. Sometimes the honest answer is that appearance is the smaller problem and you would be putting new paint on something that is about to fail store review anyway.

Agree the measures before it ships

Make these deliverables, measured before and after on the same basis:

• Completion rate for the main task.
• Retention at seven and thirty days.
• Store rating trend, and the content of new reviews.
• Support contacts about the app, per thousand users.
• Crash-free session rate.

"It looks better" is not a result. Numbers also tell you quickly when something has gone wrong, which is exactly when you need to know.

Update the store listing too

Easily forgotten and cheap. New screenshots, a revised description, and a release note that tells people what changed. If the icon changes, expect a short-term dip while people fail to find it on their home screen — which is a good reason to change an icon rarely and deliberately.

Comparing five quotes

Read for:

• Who asked to see your analytics before designing?
• Who proposed watching real users?
• Who included a staged rollout and a halt condition?
• Who designed for both platforms rather than once?
• Who agreed measures for whether it worked?

Describe what the app does, how many active users you have, where people give up, and what the reviews complain about. Firms who have redesigned live apps will ask for your retention numbers before they ask about your brand.