A mobile UX audit is a structured review of how people actually use your app on a phone: where they hesitate, where they get stuck and where they give up. It covers navigation, key journeys, touch interaction, accessibility, performance and the awkward moments real life throws at an app, such as a dropped signal or an incoming call. Done well, it ends with a prioritised list of fixes, not a vague report. This guide explains what to include, how to run it on real devices, and how to turn findings into work your team can ship.
TL;DR
- A mobile UX audit judges usability on a phone, not just whether a layout looks right on a small screen. Test on physical devices, not only emulators.
- Start with goals and key journeys, then review screen by screen against platform guidelines, accessibility standards and real user behaviour.
- Check the edge cases: poor connections, interruptions, authentication, error recovery and keyboard behaviour in forms.
- UK public sector apps must meet WCAG 2.2 AA and publish an accessibility statement. Private-sector apps are well advised to treat that as the benchmark.
- The output that matters is a ranked list of fixes with an owner and a re-test date.
Table of Contents
- What a mobile UX audit actually is
- When you need one
- Set goals before you open a single screen
- The audit, step by step
- What to check on every screen
- Accessibility in a UK audit
- What a good audit report contains
- Turning findings into fixes
- Our perspective
- Working with us on your audit
- FAQ
- Sources
What a mobile UX audit actually is
A UX audit evaluates an existing product against usability principles, platform conventions and evidence from users, then recommends what to change. The "mobile" part matters. Many products pass a responsive design check and still frustrate people in the hand, because a phone brings thumbs, interruptions, patchy networks and operating system gestures that a desktop browser never meets.
It helps to separate an audit from two things it is often confused with:
- Usability testing watches real people attempt tasks. It is one input to an audit, and we cover it in our guide to app usability testing.
- Analytics review tells you where users drop off, but not why. An audit supplies the likely reasons.
Industry practice treats an audit as benchmarking and optimisation, not only bug-hunting. Automated checks give a baseline, but the most telling insights usually come from watching people use the app on real hardware, as Make it Clear's audit guidance argues.
When you need one
You do not need to wait for a crisis. The usual triggers are:
- Falling retention or conversion. Analytics show a drop at a specific step, such as registration or checkout, and nobody agrees why.
- Poor store reviews or support tickets that repeat the same complaints.
- Before a redesign or major release. An audit stops you rebuilding problems you already have.
- After a platform change. New iOS or Android versions, or a move to a cross-platform build, can quietly break interactions.
- An accessibility obligation. Public sector bodies and their suppliers need evidence of compliance.
- Inheriting an app from another team or agency and needing an honest picture of its condition.
Set goals before you open a single screen
The most common mistake is starting with the screens. Start with what the app is for. Agree these first:
- Business goals: orders placed, appointments booked, forms completed, donations made, repeat sessions.
- User groups: new users, returning users, staff using a B2B tool in the field. Each has different priorities.
- Critical journeys: the five or six paths that matter most, such as onboarding, search, purchase, account recovery and support.
- Success measures: task completion rate, time on task, error rate, store rating, support contacts per thousand users.
Write these on one page. Every finding later gets scored against it, which keeps the audit from drifting into personal taste.
The audit, step by step
1. Gather what you already know
Collect analytics funnels, crash reports, store reviews, support logs and any earlier research. Patterns here point you to the screens that deserve the closest look. If you have no data at all, that is itself a finding.
2. Walk the key journeys on real devices
Run each critical journey from a cold start, as a first-time user would. Note every point of friction, confusion or delay. Use a small device lab: a recent iPhone, an older iPhone, a mid-range Android and, if your audience uses them, a budget Android handset. Practitioners warn that emulators cannot reproduce gesture conflicts with system zones, such as the iOS swipe-back or Android navigation gestures, nor true touch accuracy or load failures on a weak connection, a point made in UX Companion's mobile audit checklist.
3. Review screen by screen
Work through each screen against a consistent checklist (below). Capture a screenshot, the issue, why it matters, how severe it is and a suggested fix. A spreadsheet or a shared board is enough.
4. Test the edge cases
This is where mobile audits earn their keep. Try the app with airplane mode switched on mid-task, with the app sent to the background and returned to, with a notification interrupting a form, with a wrong password, and with a payment failure. Check that the app explains what happened and lets the user recover without losing their work.
5. Check accessibility
Combine automated scans, manual checks with VoiceOver and TalkBack, dynamic text sizes and colour contrast. More on this below.
6. Add real user evidence
Heuristic review finds likely problems. Five to eight people completing tasks will tell you which ones actually hurt. Even a small round of sessions will reorder your priorities.
7. Prioritise and report
Score every issue by severity and by effort. Present the quick wins first, then the structural problems. A good report is short enough that someone will read it and specific enough that a developer can pick up an item without a meeting.
What to check on every screen
| Area | What to look for |
|---|---|
| Navigation | Can users tell where they are and how to go back? Are the main destinations reachable in one or two taps? |
| Touch targets | Are buttons large enough and spaced so people do not mis-tap? |
| Thumb reach | Are primary actions within comfortable reach on large phones, or stranded at the top corners? |
| Typography | Is text legible at default and enlarged sizes, without clipping or overlap? |
| Forms | Does the keyboard cover the field being filled in? Does the right keyboard type appear? Is autofill supported? |
| Feedback | Does every tap produce a visible response? Are loading and empty states designed? |
| Errors | Are messages specific, polite and actionable? Is entered data kept? |
| Authentication | Is sign-in quick, with biometrics where suitable? Is recovery simple? |
| Consistency | Do patterns, labels and icons behave the same way across the app? |
| Platform fit | Does the app respect iOS and Android conventions rather than forcing one design onto both? |
| Performance | Does it feel fast on older devices and slow connections? |
| Accessibility | Does it work with screen readers, large text, reduced motion and sufficient contrast? |
Touch, type and platform guidelines
Platform owners publish concrete thresholds, and an audit should measure against them. Apple's interface guidance recommends a minimum tappable area of 44 by 44 points and sets out minimum text sizes for legibility on iOS. Android has its own equivalent guidance in Material Design. Neither is a matter of taste: small targets and tiny text are among the quickest ways to lose older users and anyone using a phone on a train.
Also check that selection or status is never signalled by colour alone, and that important controls do not sit where system gestures will compete with them. If you are working on iPhone specifically, our iOS app design guide goes deeper on the conventions to hold your screens against.
The "responsive design trap"
Organisations often believe a responsive check equals a mobile audit. It does not. An app can look right in a browser emulator and still fail in the hand: the keyboard pushes a field out of view, a swipe triggers the wrong action, or a network drop leaves a spinner turning forever. The reachable-by-thumb question, the interrupted-state question and the offline question rarely show up in a web-style review, which is why they belong in yours.
Accessibility in a UK audit
Accessibility is part of usability, not an add-on. In the UK it also has legal weight for some organisations.
Public sector websites and mobile apps must meet accessibility standards and publish an accessibility statement under regulations that came into force on 23 September 2018. The Government Digital Service monitors compliance and tests against WCAG 2.2 levels A and AA. If you build for councils, the NHS, universities or other public bodies, this is the baseline your audit should measure against. GDS has also published a candid write-up of auditing a public sector app, which shows how findings are reported in practice.
If you are a private-sector business, those regulations do not apply to you directly, but the same standard is the sensible benchmark. Accessibility also overlaps heavily with general good UX: larger targets, clearer labels and better contrast help everyone, including people using a phone in bright sunlight.
A few practical points:
- Automated scanners catch only part of the problems. Manual testing with a screen reader and with large text settings is essential.
- WCAG 2.2 was written for the web, and applying it to native and hybrid builds takes interpretation. We set out how in WCAG for mobile apps.
- Meeting the criteria is a floor. GDS accessibility specialists describe the aim as going further through research with disabled users, covering things like motor and cognitive difficulties that a checklist can miss.
For background reading, see our pieces on app accessibility explained and designing accessible mobile apps. If your audit also covers web content, a general overview such as this explainer on web accessibility and compliance can help your marketing team see why it matters beyond the app.
What a good audit report contains
Whether you commission one or run it in-house, expect these elements:
- Scope and method: which journeys, devices, operating system versions and standards were covered.
- Executive summary: the five or six findings that matter most, in plain language.
- Detailed findings: each with a screenshot, the evidence, severity, the affected user group and a recommended fix.
- Prioritised roadmap: quick wins, medium changes and structural work, with rough effort.
- Benchmarks: how the app compares to expectations in its sector and to your own past performance.
- A walkthrough session with the team, so the findings land with the people who will fix them.
Large specialist audits can run to many pages. Length is not the measure. A twenty-page report that gets acted on beats a hundred-page one that sits in a shared drive. For more on structuring audit deliverables, this consultant's approach to UX audits and workflows is a useful reference point, particularly for SaaS-style products.
Turning findings into fixes
An audit has value only when it changes the product. Some habits that help:
- Fix the journey, not the screen. If registration loses people, look at the whole flow before polishing one button.
- Batch quick wins into the next release so the team sees momentum.
- Prototype big changes before building them. Testing an interactive prototype is far cheaper than rebuilding a shipped feature.
- Measure again. Re-run the same journeys and compare completion rates and ratings after release.
- Make it routine. A light review each quarter, plus a full one before major releases, keeps debt from building up.
Our step-by-step UX and UI improvement guide and our guide to improving app UX for retention walk through that stage in more detail, and the user experience optimisation guide covers engagement.
Our perspective
We have built more than 300 apps, and the same pattern turns up in most audits: the biggest problems are rarely visual. They are in the moments between screens. A user returns to the app after a call and finds their form wiped. A sign-in step asks for too much. A key action sits where a thumb cannot comfortably reach.
That is why we favour audits that begin with strategy, not with a screen checklist. Our process starts with discovery, because you cannot judge whether an experience works until you know what it is meant to achieve and for whom. We are also technology-agnostic, so when a finding points to a platform limitation, we can recommend the right approach for that project rather than defend a favourite framework.
Our advice to any business commissioning or running an audit: insist on real devices, insist on real users, and insist on a ranked list of actions. If a report cannot tell your developers what to do on Monday morning, it is not finished.
— Paul
Working with us on your audit
If you would like an expert view on your app, our Mobile App Clinics are a good place to start the conversation. If the audit points to a bigger redesign or rebuild, our discover, design, develop and deploy process covers the full journey, from workshops and prototypes through to launch and post-launch support.
FAQ
How long does a mobile UX audit take?
It depends on the size of the app and the depth of review. A focused review of a handful of key journeys can be done in days, while a comprehensive audit with user sessions and accessibility testing is usually a multi-week exercise. Agree the scope and the journeys first, because that decides the timeline more than the number of screens.
What is the difference between a UX audit and usability testing?
An audit is an expert evaluation of the product against heuristics, platform guidelines and data. Usability testing observes real people completing tasks. The strongest audits combine both, because the expert review finds likely problems and the sessions show which ones genuinely hurt users.
Do I need to test on real phones?
Yes. Emulators miss gesture conflicts, true touch accuracy and network-related failures. A small set of physical devices, including an older iPhone and a mid-range Android handset, will reveal issues that never appear in a browser.
Is a mobile UX audit a legal requirement in the UK?
Not as such. However, public sector bodies must make their apps meet the accessibility standard and publish an accessibility statement, so an accessibility audit is how they evidence that. Private businesses are not covered by those specific regulations, but an accessibility review is still sensible good practice.
How often should I audit my app?
Run a full audit before a redesign, after major platform changes and whenever retention or conversion drops without explanation. Between those, a lighter quarterly check of your critical journeys keeps problems from piling up.
Sources
- Make it Clear: UX audit best practices for mobile app design
- UX Companion: Mobile UX audit
- Apple Developer: UI design dos and don'ts
- GOV.UK: Make your website or app accessible and publish an accessibility statement
- GOV.UK: Accessibility monitoring, how we test
- Accessibility in government: Accessibility audit of the Met Office app
- Accessibility in government: GOV.UK ID Check app