What a mobile UX audit covers
A mobile UX audit evaluates whether a product is genuinely usable on a phone — not merely visible on one. The distinction matters because most digital products in 2026 pass "responsive design" checks and still fail basic mobile usability: buttons too small to tap accurately, key actions parked in unreachable screen regions, gesture patterns invented without discoverability, checkout flows that require both hands, forms that keyboard-shift the layout out from under the user.
The audit evaluates six categories: touch and reachability, gesture design and discoverability, platform-convention alignment (iOS Human Interface Guidelines and Material Design), mobile performance under representative network conditions, mobile-specific accessibility (screen readers, voice control, keyboard alternatives on external keyboards, reduced motion), and mobile-specific journey friction (form input, authentication, navigation, back-behaviour). Each category has calibration checks that only reveal themselves on actual mobile hardware — not in a browser's device-emulator mode.
Scoping — web, native, hybrid
Mobile audits differ substantively based on the surface being audited. Get this scope agreement in writing before starting the engagement; the same word — "mobile" — means different work in different contexts.
Mobile web audits evaluate a responsive site on mobile viewports across iOS Safari, iOS Chrome (which uses WebKit), Android Chrome and Samsung Internet. The audit surface is the site as it renders on 375-430px viewports, with attention to touch-target sizing, hover-state alternatives (mobile has no hover), input-type appropriateness for mobile keyboards, and mobile-specific viewport quirks (100vh problems on Safari, address-bar layout shift, virtual-keyboard obscuring input fields).
Native app audits evaluate platform-native builds against iOS Human Interface Guidelines or Material Design 3 conventions. Native audits weigh conformance to platform convention heavily — a native iOS app that ignores navigation-bar back-buttons or the standard tab-bar pattern is fighting user expectations formed across every other app on the device. Cross-platform apps built with React Native, Flutter or SwiftUI/Jetpack Compose need to be audited on both platforms; the same code produces different UX outcomes on iOS and Android.
Hybrid or web-view apps (Ionic, Cordova, Capacitor) inherit both surfaces' failure modes. Audit the web view against mobile web heuristics and the shell against native heuristics. Web-view apps often fail at the seam — pull-to-refresh not implemented, deep links breaking navigation stack, native gestures fighting web-view scroll.
Touch targets and thumb-zone
The physical minimum touch target size is 24×24 CSS pixels (WCAG 2.5.8, added in WCAG 2.2). The recommended target is 44×44 CSS pixels (Apple HIG) or 48×48 dp (Material Design). Any interactive element below the WCAG minimum fails the audit. Any element between 24 and 44 CSS pixels passes WCAG conformance but should be flagged as usability risk in the report.
Spacing matters as much as size. Two 44×44 targets stacked with 2px between them are functionally one large mis-tap zone. The audit heuristic: any two adjacent interactive elements should have at least 8px of clear space between their bounding boxes. Tight clusters of small icons — social share bars, disclosure toggles, tag-clouds — are the most common violation.
Thumb-zone analysis divides the phone screen into three regions: easy reach (bottom third), stretched reach (middle third), and difficult reach (top third and screen corners). Primary actions should live in easy reach; secondary in stretched; destructive or infrequent in difficult. The heuristic bends on tablets, foldables and large-screen phones where two-handed operation is common, but for phones in the 6.1"-6.7" range that dominate 2026 UK usage, primary actions above the middle-of-screen line are actively fighting the user.
The audit measures: primary CTA position on every core screen, back-button reachability during one-handed use, form-submit-button position relative to the virtual keyboard, and destination distance of any user must-reach tap on the primary flow. Findings often cluster at the top of the screen where designers placed important actions during desktop-first design.
Gestures and affordance
Every custom gesture the app introduces is a discoverability tax. Swipe-to-delete, long-press context menus, pinch-to-preview, pull-to-refresh — each requires the user to already know it exists. The audit flags any critical action available only via undiscovered gesture; every gesture-driven action should have a tappable alternative unless the platform convention makes the gesture universally expected (pull-to-refresh in email apps, swipe-to-dismiss in notification stacks).
Discovery cues matter. A partial-visible-edge that hints at a swipeable carousel is a discovery cue. A completely-hidden drawer that opens only on a right-edge swipe is not. Audit each gesture for the presence of an affordance — a peek, a handle, a subtle animation on first load — that tells first-time users the gesture exists.
Gesture conflicts are the highest-severity finding in this category. Custom horizontal swipes that fight the platform's edge-swipe-back gesture (iOS) or bottom-swipe-navigation (Android). Long-press handlers that trigger the platform's text-selection UI. Pull-to-refresh implementations that fire on any scroll gesture. Each conflict produces predictable user frustration.
One-handed operation
Most mobile usage in 2026 is one-handed. Commute, kitchen, holding coffee, holding a child, holding a shopping bag. The one-handed test is diagnostic: complete the primary user flow with the phone in the dominant hand, thumb only, without adjusting grip. If grip-adjustment is required — reaching a top-of-screen menu, hitting a small back-button, scrolling to a bottom-half CTA that then requires a top-half confirmation — the flow fails.
Common one-handed failures: hamburger menus in top corners that require a hand-shift to open. Modal dismiss-buttons in top-right. Multi-step forms that require scrolling up to reference previous input. Confirmation dialogs with "Cancel" and "Confirm" buttons at the top of the screen. Destructive actions requiring precise mid-screen taps.
The audit records one-handed completion time and grip-shift count for each primary flow. A flow that requires two grip shifts is fixable via layout changes; a flow that requires four is architecturally broken and needs redesign, not remediation.
iOS vs Android divergence
Cross-platform apps and mobile-web audits both need to account for the ways iOS and Android users differ in expected behaviour. Auditing both surfaces to the same standard misses the failures that come from mismatched platform convention.
Navigation. iOS convention places the back-button top-left within the app's own UI, and supports edge-swipe-back from the left edge. Android places system back at the bottom (Android 10+) as a gesture and does not require in-app back buttons. An iOS app with no back-button top-left is fighting muscle memory; an Android app that duplicates the system back-button in-app is redundant and adds visual noise.
Tab bars. iOS places primary navigation in a bottom tab bar; Android has increasingly adopted this pattern since Material Design 3 but historically preferred navigation drawers. Both patterns are now accepted on both platforms in 2026, but the audit should flag inconsistency between platforms in a cross-platform app.
Sheets and modals. iOS uses swipe-down-to-dismiss on bottom sheets; Android uses tap-outside or hardware back. An iOS user expects swipe-to-dismiss to work on any bottom sheet; missing this fails the platform convention check.
Typography and spacing. iOS uses San Francisco with tighter letter-spacing; Android uses Roboto with more generous spacing. Cross-platform apps that use identical type scale on both platforms often look cramped on Android or airy on iOS.
Input and keyboards. iOS returns to previous input on keyboard dismiss; Android keyboard behaviour varies by manufacturer. Forms should be audited on Samsung, Pixel and Xiaomi devices at minimum — not just on a Pixel emulator.
Mobile performance
Mobile performance is where audits find silent conversion killers. Core Web Vitals thresholds apply universally, but mobile performance has additional constraints: slower CPUs, higher network latency variance, memory limits, and thermal throttling on sustained load.
The audit tests page load and interactivity across three network profiles: fast 4G (25 Mbps down, 100ms RTT), slow 4G (1.6 Mbps down, 300ms RTT), and 3G (400 Kbps down, 600ms RTT). Slow 4G approximates the median mobile experience in the UK once building interiors, transit, and rural coverage are factored in. Sites tested only on office wifi produce optimistic performance verdicts.
Key metrics: Largest Contentful Paint under 2.5 seconds on slow 4G. Interaction to Next Paint under 200ms. Cumulative Layout Shift under 0.1. Time to Interactive under 3.8 seconds. First Contentful Paint under 1.8 seconds. Mobile-specific: virtual-keyboard-open time (should not trigger layout shift), scroll performance at 60fps on mid-range Android (Pixel 6a as the baseline), and app-launch time to first meaningful interaction on native apps (under 2 seconds cold-start).
Mobile accessibility
Mobile accessibility is where audit template updates most often lag. The mobile-specific WCAG 2.2 additions (target size, dragging alternatives, focus not obscured) apply directly. Beyond WCAG, mobile audits should evaluate: VoiceOver navigation on iOS (rotor controls, custom actions, live regions), TalkBack navigation on Android (reading order, gesture nav, verbose mode), voice control (Voice Control on iOS, Voice Access on Android), external keyboard support (many AT users use Bluetooth keyboards), Dynamic Type support (iOS) and font-size respect (Android), reduce-motion setting compliance, and high-contrast mode compatibility.
The accessibility audit reference covers the WCAG methodology in depth; the mobile-specific layer above adds AT-on-mobile testing that desktop-focused accessibility audits often skip.
Device lab and real-user testing
Emulators are useful for automated testing and CI; they are insufficient for audit-quality findings. The audit's credibility depends on real devices representing the actual user base.
Minimum device lab for a UK-market audit: iPhone 12 (baseline iOS user), iPhone 15 (current-generation iOS), Pixel 6a (baseline mid-range Android), Samsung Galaxy S23 or S24 (majority Android in UK), Xiaomi Redmi (budget Android for network-constrained users), one Android tablet, one iPad. Older devices matter — iPhone 8 and older iOS baselines are still in circulation and represent users on strict budget constraints.
Real-user testing during the audit — even three moderated sessions on real hardware — often surfaces findings that manual heuristic review misses. Test on the user's own device where possible; unfamiliar hardware biases sessions.
Reporting mobile findings
Mobile audit reports follow the same five-section structure as any UX audit report — executive summary, verdict, prioritised findings, evidence appendix, remediation guidance — but with mobile-specific artefacts: screen recordings on real devices (not just screenshots), thumb-zone overlays annotated on each key screen, and platform-specific breakdown for cross-platform apps.
Findings are prioritised by user impact, business impact and effort to fix — same three-axis framework used in the core UX audit methodology. The mobile-specific weighting: touch and thumb-zone findings tend to be high-impact / low-effort (layout tweaks) and should surface at the top of the fix list. Gesture-conflict findings often turn out to be high-effort (interaction pattern rework) and land in the roadmap bucket.
Frequently asked questions
- How many screens should a mobile audit cover?
- 8 to 15 unique screen templates for a template-level audit. Fewer misses category coverage; more risks scope creep. For native apps, cover every tab-bar destination plus the primary onboarding flow and the primary conversion flow at minimum.
- Does mobile UX audit include native app store optimisation?
- Not by default. ASO (screenshot design, description copy, keyword targeting) is a marketing engagement rather than a UX audit. Some agencies bundle ASO as a light layer within native app audits; agree scope explicitly.
- Do I need a mobile audit if my site is already responsive?
- Almost certainly yes. Responsive design ensures the site displays on mobile viewports; it does not ensure the mobile experience is usable one-handed, discoverable via mobile gesture conventions, or performant under real mobile network conditions. Responsive audits and mobile UX audits are complementary, not substitutable.
- What tools do you use for mobile audits?
- Real devices in a device lab (never emulators only). Chrome DevTools for network throttling verification. Xcode Instruments and Android Studio Profiler for native performance. WebPageTest for mobile web performance under representative network conditions. Charles Proxy for network inspection on device. Real screen recording via QuickTime (iOS) or scrcpy (Android) for evidence.
- How does mobile UX audit relate to accessibility audit?
- Overlapping but distinct. Mobile UX audits evaluate usability heuristics on mobile; accessibility audits evaluate WCAG conformance across desktop and mobile. Mobile-specific accessibility criteria (target size, gesture alternatives, focus behaviour on virtual keyboard) sit in both. Run both if the site handles significant mobile traffic and has any accessibility exposure. The accessibility audit reference covers the WCAG methodology.