App UI/UX redesign

The complaint behind the brief

Three things bring an owner to a redesign, and they are not equally urgent. The app looks old, and new installs open it once and never return. Brand has moved on and the app no longer matches anything else the company puts out. Or — the expensive one — people cannot finish what they came to do. They reach the cart and do not buy. They abandon the form at the third field. They install, hit onboarding, and leave.

That third case is where the money is, and it is usually described in the first email as if it were the first case. "The app looks dated" is what people say. "People reach the basket and leave without ordering" is what they mean. The two need completely different work, and starting a redesign without separating them is how a project ends with a beautiful app that converts exactly as badly as the old one.

So the first thing this service does is establish which problem you actually have, evidence first. Where do people stop, on which screen, at which step. That question turns the conversation from taste — which has no correct answer and no end — into something that can be tested. It also usually changes the scope, because once the stalls are located it becomes obvious that four screens are doing the damage and the other twenty just need to stop looking like they came from different apps.

How the redesign runs

1. Use the app the way a customer does. Every screen captured on a real handset, not a simulator, including the states nobody screenshots — empty lists, errors, loading, no connection, first launch. Each point where a person could hesitate or leave is marked as we go. Three to five days.
2. Gather the evidence that already exists. Whatever analytics you have, read for drop-off between steps rather than for totals. Then App Store and Play Store reviews, which are free, unprompted and specific — users describe their own confusion better than most usability sessions do. Support tickets, if you have them, say the same thing again. Two to four days.
3. Fix the route before touching the surface. New screen order, fewer steps, decisions moved to where the user has enough information to make them, onboarding reconsidered around the first useful thing the app can do rather than a tour. Presented as flows, and agreed before any visual work starts. One to two weeks.
4. Design one or two screens and get a decision. The hardest screen and the most typical one, in full. Direction, type scale, colour roles, spacing rhythm, component behaviour — all visible and all argued about here, where changing them is cheap. Three to five days, plus your review time.
5. Draw the full set and build the system underneath it. Every screen and every state, assembled from real components rather than one-off layouts, so that spacing, colour and type are defined once. Two to three type sizes, a restricted colour set with defined roles, and named components — the thing that keeps the app consistent after we leave. One to three weeks.
6. Handoff, or implementation. Specifications, tokens, component documentation and a walkthrough for your developers — or, where implementation is in scope, the screens built and running in the app. Three days for handoff, longer if we are building.

Working tools are Figma for the design system and screens, the live app on real iOS and Android hardware, both stores' review pages as research, and whatever analytics is already installed.

What sets the number

$2,000–$12,000 over 4–8 weeks covers a genuinely wide set of jobs, and three things decide where a project lands.

How many screens, and how many states. Screen count is the honest unit for scoping mobile work — far more reliable than hours. Scope is written as a named list of screens with a fixed price agreed for any screen added later, so a request in week three is an arithmetic question instead of an argument. States multiply that count more than people expect; a list screen is really four screens.

Whether a design system is part of the deliverable. Redrawing screens is faster than building a reusable component set with tokens, documented states and naming. The system costs more up front and it is what stops the app drifting back into inconsistency the next time someone adds a feature in a hurry.

Design only, or design and implementation. Taking the work into code is the larger half. It is also the version clients most often want, because it removes the gap where a design is handed over and quietly rebuilt into something else.

Where redesigns fail

The redesign becomes a recolour. New palette, new icons, same tangled route through the app. It ships, it demos well, and three months later the original complaint returns unchanged — people still are not completing orders. The real damage is not the wasted money, it is that you come away believing design does not affect outcomes and will not fund the real fix. Route first, appearance second, in that order, every time.

The whole set is drawn before anything is approved. Forty screens designed in one pass, presented together, and you dislike the direction. Now every screen is wrong at once and the project restarts with the budget spent. Approving direction on one or two screens first costs a few days and protects the rest of the work.

Platform conventions are flattened for consistency. A design that insists both platforms look pixel-identical usually means one platform gets the other's habits — an iOS app with an Android back arrow and no swipe gesture, or an Android app with an iOS tab bar and a hijacked hardware back button. It photographs well in a deck and it makes the app feel subtly wrong to everyone on the platform whose conventions were dropped, who then blame the app rather than the design.