Where to Start Improving an Existing App

"We want to rebuild the app" is a common opening, and in most of those conversations it turns out a rebuild is not needed.

The problems are usually concentrated in a few places. A full rebuild breaks something that currently works, with no guarantee that what replaces it is better.

Find where you are losing people first

Locate the problem with numbers before changing anything. Not impressions, locations.

Three things to look at.

Where people drop out. Which screen loses them. This is the most direct signal there is.

Repeated actions. Moving back and forth between the same two screens, pressing the same button several times. That is evidence that something is not being communicated.

Support enquiries. The questions your support team receives are a list of interface failures. If the same question has arrived three times, that screen is not answering it.

The third one needs no tooling and is the most specific. Categorising six months of enquiries usually reveals most of what needs fixing.

Four fixes that work almost everywhere

The first thirty seconds. What a new user sees. Existing users never see it, so nobody internally is looking at it. Sign up with a fresh account rather than testing from your own.

The empty state. The screens with no data in them. Also invisible internally. Every single user passes through it, and it is routinely undesigned.

Error messages. What happened, whether their work is safe, and what to do next. An error missing those three has already stopped the user.

How waiting is presented. You do not have to make the operation faster. Responding the instant something is pressed changes the perceived speed substantially on its own.

All four are local changes rather than rebuilds, and all four produce results quickly.

When a rebuild is the right call

Sometimes local fixes cannot reach it. Any of these justifies considering a rebuild.

The information structure itself is wrong. If where things live does not match how users think about them, fixing individual screens will not solve it.

It cannot technically be fixed. Old construction where changing one thing breaks another. That is a debt problem rather than a UX problem, and it is a legitimate reason.

The users changed. The people using it now are not the people it was built for. The premise has moved, and local fixes cannot catch up.

Rebuilding because it "looks dated" generally does not move the numbers. Appearance is a weak reason on its own.

If you do rebuild

Do not replace everything at once.

The best approach is shipping one function in the new construction and running it alongside the old one. Compare the numbers. If it is better, continue. If it is worse, you can stop.

A full cutover leaves no way back when something gets worse, and new things are rarely better on the first attempt.

What to agree if you are commissioning it

Make the deliverable a specific number that has to move, not a set of design files.

Whether that number moved is only knowable after release. So the contract needs to include the measurement period after launch and what happens depending on the result.

Improvement projects without that end at launch. And the next conversation, a year later, starts with "we want to rebuild the app".

The cheapest thing that works

Sit five real users in front of the app and watch. Do not talk, do not help. Count how long it takes them to do the main thing.

Five is enough. If three of them get stuck in the same place, that is what to fix. The problems this finds are usually ones nobody internally had noticed, and they are usually easy to fix once seen.