How to improve the user experience of an app
The short answer
To improve the user experience of an app, first find where people struggle using funnels, session recordings, support tickets and usability tests. Then fix the steps where the most people drop off, remove steps that add nothing, make states and errors clear, and measure the same tasks before and after each change.
Where should you start when improving an app's user experience?
Start with evidence of where people struggle, not with a redesign. Most apps, SaaS platforms and dashboards have a few specific points where users hesitate, make mistakes or leave. Finding those points first means the work goes where it changes behaviour, and it gives you a baseline to measure against later.
We use four sources together, because each one shows a different part of the problem:
- Analytics funnels show where people drop out of a key task, such as sign-up, checkout, creating a record or finishing onboarding.
- Session recordings show what people did right before they left: repeated taps, scrolling back and forth, rage clicks, or long pauses on one field.
- Support tickets and reviews show what people could not work out on their own, in their own words.
- Usability tests show why. Watching a handful of real users try a task explains what the numbers only hint at.
Funnels and recordings tell you where. Tickets and tests tell you why. You need both before you change anything. If you want help setting this up, our UX research work starts with exactly this review.
How do you decide which UX problems to fix first?
Fix the problems that sit on your most important task and affect the most people first. A confusing settings page matters less than a sign-up step that loses a large share of new users. Rank each problem by how many people it touches, how close it is to the action that matters to the business, and how hard it is to fix.
| Problem | Signal | Typical fix |
|---|---|---|
| Too many steps in a key task | Steady drop at each step of the funnel | Merge or remove steps, ask for less data, fill in what you already know |
| Unclear next action | Long pauses and scrolling in recordings, users asking what to do next | One primary action per screen, clearer button labels |
| Vague or late errors | Repeated form submits, tickets about failed actions | Inline validation, error messages that say what went wrong and how to fix it |
| Empty or loading screens that look broken | Exits on first use, tickets saying data is missing | Designed empty, loading and error states with a next step |
| Slow screens | Drop-off rises on slower devices and networks | Load the essential content first, show progress, cut heavy assets |
| Hard to use for some people | Complaints about small text, low contrast or controls that cannot be reached | Fix contrast, touch targets, labels and keyboard access |
How do you reduce the number of steps in an app?
Reduce steps by removing anything that does not help the user finish the task they came for. Map the current flow screen by screen, then ask of each screen and field whether it is needed now, needed later, or not needed at all.
- Move optional questions out of sign-up and ask them when they become relevant.
- Pre-fill fields from data you already have, such as location, previous choices or account details.
- Combine screens that each ask for one small thing.
- Use sensible defaults so most people can accept and continue.
- Let people finish the core task before asking them to set up extras.
Fewer steps is not always better if each remaining step becomes crowded. The aim is that every screen has one clear job.
Why do states and error messages matter so much?
States and errors matter because they are where users decide whether the product works. A screen that shows nothing while loading looks broken. An empty dashboard with no guidance looks like a bug. An error that says "Something went wrong" leaves the user with nowhere to go.
For every screen, design the full set of states: empty, loading, partial, error, success and no permission. Error messages should say what happened, why, and what to do next, in plain language, next to the field or action that caused them. In SaaS and dashboard products, this is often the fastest improvement available, because these states are usually left to engineering defaults. We cover this in detail in our SaaS and dashboard design work.
How much does speed affect user experience?
Speed affects user experience directly, because people read a slow response as a broken product. Part of speed is engineering and part is design. Designers decide what loads first, what can wait, and what the user sees while they wait.
- Show the content the user needs first and load secondary panels after.
- Use skeleton screens or progress indicators for anything that takes more than a moment.
- Update the interface immediately when a user acts, then confirm with the server in the background where it is safe to do so.
- Test on mid-range phones and slower networks, not only on the team's own devices.
Is accessibility part of improving user experience?
Yes, accessibility is part of user experience, not a separate task. Readable text, sufficient contrast, touch targets large enough to hit, labels that screen readers can announce and full keyboard access make the product easier for everyone, including people using it one-handed, in sunlight or in a hurry. The WCAG 2.2 guidelines are the reference we check against.
How do you know if a UX change worked?
You know a change worked when the same task, measured the same way, gets better after the change. That means measuring before you design, not only after launch.
- Pick the tasks that matter and record the current funnel numbers for each.
- Run a usability test on the current version to get a baseline for task completion, misclicks and abandonment.
- Design the change and test it as a prototype with real users before building it. We use Maze for this.
- Ship the change, or A/B test two versions when the choice is unclear.
- Compare the funnel and the test results with the baseline.
This is the same order we follow on every project: understand, design, test, then build and measure. You can read how it works on our process page.
