Make Mobile UI Patterns Reachable: 5 Tap Test for UK Designers

Mobile UI patterns are the recurring navigation, input, and feedback structures (tab bars, bottom sheets, cards, skeleton screens) that give an app a predictable shape. The single most important priority when choosing between them is durable navigation paired with accessible touch targets: get those two right and most other pattern decisions become straightforward. The inventory below sets out the options we rely on most often, along with the principles and platform rules that decide whether each one works in practice.

TL;DR:

Using fixed, persistent navigation like tab bars for up to five top-level destinations improves discoverability and reduces user errors.

Target sizes should be at least 44 pixels, preferably 48 pixels for critical controls, with generous spacing to minimize mis-taps, especially for users with reduced dexterity.

Native system components ensure accessibility and familiarity, while custom patterns are best reserved for branding-critical screens to avoid performance and support issues.

Designing for various screen sizes and orientations requires early breakpoint decisions, with testing on actual devices to prevent layout issues during rotation or on foldables.

Skeleton screens and progress indicators promote perceived speed, but mismatch or incomplete loading states can erode trust faster than simple, honest feedback.

Pocketapp

pocketapp.co.uk

Build A More Reachable App

Pocket App designs and develops user-focused mobile applications, combining UX/UI design, strategic discovery, and cross-platform deployment.

Explore Pocket App

1. Common mobile navigation and layout patterns
2. Principles and accessibility rules that decide whether a pattern works
3. Platform differences and where to find reliable components
4. How to choose and validate a pattern quickly
5. How we apply these patterns across real projects
6. Responsive and adaptive patterns across screen sizes and orientations
7. Loading and placeholder patterns that keep people oriented
8. Error handling and empty state patterns
9. Form input patterns built for mobile keyboards and screens
10. Performance choices that shape which patterns survive contact with real devices
11. Internationalisation and localisation challenges in mobile UI
12. The trade-offs worth making deliberately
FAQ
Sources

Most mobile interfaces are built from a small set of recurring components. Choosing the right one depends on how many primary destinations the app has, how often a task repeats, and how reachable the control needs to be.

Tab bar / navigation bar: fixed, persistent destinations at the bottom of the screen, best for 3 to 5 top-level sections a person returns to repeatedly.
Hamburger or overflow menu: hides secondary or infrequent destinations behind an icon, useful for dense apps but weaker on discoverability since options stay invisible until tapped.
Navigation rail: a vertical strip of destinations suited to tablets and larger or foldable screens where horizontal space is available.
Bottom sheet: a panel that slides up over content for contextual actions or filters, letting someone stay oriented in the screen beneath it.
Gestures (swipe, long press, pull to refresh): fast for repeat users but poorly discoverable for newcomers unless paired with a visible affordance.
Cards and lists: the default containers for scannable content, from product grids to activity feeds.
Carousels: good for a handful of promotional or editorial items, weak for anything a person needs to compare or revisit.
Onboarding patterns: short walkthroughs or progressive disclosure that introduce features at the point of need rather than all at once.

The recurring pitfall across all of these is discoverability: a gesture or hidden menu that feels efficient to the person who built it often confuses a first-time user. Nielsen Norman Group's research on mobile usability recommends keeping navigation focused on primary tasks and limiting the number of visible primary controls, which is as much an argument against overloaded tab bars as it is against buried hamburger menus. The practical rule: default to visible, persistent navigation for anything used often, and reserve gestures and overflow menus for actions that are genuinely secondary.

2. Principles and accessibility rules that decide whether a pattern works

A pattern only succeeds if it respects a handful of rules that sit above individual component choice.

Simplicity and consistency keep a person's mental model intact: once someone learns where a destination lives, moving it between screens or renaming it breaks that model and forces them to relearn the app. Feedback matters just as much, visible states (pressed, loading, disabled) and non-visual cues such as haptics tell someone an action registered, which matters more on a six-inch screen than on a desktop where cursor position already gives a clue.

Touch target size is the rule with the least room for interpretation. WCAG 2.2 guidance on target size sets 44 by 44 CSS pixels as a usable minimum, and plenty of accessibility teams recommend 48 by 48 for coarse touch inputs such as a thumb on a moving train.

Treat 44px as the floor, not the target. Pushing frequent or critical controls to 48px and above reduces mis-taps, particularly for anyone with reduced dexterity or a larger finger.

Keep spacing between adjacent targets generous enough that a mis-tap lands on empty space rather than the wrong control.
Never strip keyboard or switch-control support just because a touchscreen is present; some people navigate with alternate input regardless of device type, a failure mode WAI's guidance on hidden controls specifically calls out.
Pair every visual feedback state with an accessible label so screen reader users get the same signal sighted users see.

Our own guidance on app accessibility goes into more depth on building these checks into a standard design review.

3. Platform differences and where to find reliable components

Native feel comes from following each platform's own rules rather than porting one platform's conventions onto the other.

Material Design 3's navigation bar guidance recommends using a bottom navigation bar on compact window widths (under 600dp), limited to 3 to 5 destinations that stay consistent across screens, with a navigation rail or drawer taking over on larger widths. Android's UI design documentation extends this with window size classes (compact, medium, expanded) that let a layout adapt rather than simply stretch.

On iOS, tab bars follow their own placement and behaviour conventions, and Apple's SF Symbols guidance sets out rendering modes (monochrome, hierarchical, palette, multicolour) that keep iconography consistent with the rest of the system. Safe-area insets need checking on every notch, dynamic island, and home indicator variant still in circulation.

Default to system components (tab bars, navigation bars, standard icon sets) wherever the task is generic; they inherit accessibility support and platform familiarity for free.
Reserve custom components for genuinely brand-critical moments, where the cost of building and testing a bespoke pattern is justified.
Lean on official documentation and matching Figma kits rather than recreating components from screenshots, which drifts out of date within a release cycle or two.

4. How to choose and validate a pattern quickly

A short checklist beats a long debate for most pattern decisions.

Identify the primary task the screen serves and how often someone repeats it.
Check reachability: can the control sit within comfortable thumb range on a one-handed grip?
Decide whether the action is undoable; irreversible actions need more friction and a confirmation step, not less.
Confirm accessibility needs: screen reader labels, keyboard operability, and target size above the 48px line for anything frequent.
Prototype the pattern and run a five-tap test, asking someone unfamiliar with the app to complete the core task within five taps.

Pro Tip: Run a one-handed reach test on the actual device size you are shipping for, not a desktop simulator; thumb reach varies enough between a compact phone and a large-screen device to change which zone counts as comfortable.

Red flags worth stopping for: a task that takes more taps each time you test it, a control that testers consistently miss, or an action someone cannot undo without contacting support. Our piece on thumb zone design and our guide to usability testing both work through these checks in more detail, including how to run them without a full research cycle.

5. How we apply these patterns across real projects

We have found that the patterns holding up longest are the plainest ones: stable tab bars, generous touch targets, and feedback states that never leave someone guessing whether a tap registered. Our blog posts on thumb zone design, accessibility, and iOS design reflect the checks our design team runs on every build. When a navigation pattern needs validating before full development starts, our app design work folds that testing into the discovery stage rather than leaving it until after launch.

6. Responsive and adaptive patterns across screen sizes and orientations

A layout that only works at one width breaks the moment someone rotates their phone or opens the app on a tablet or foldable. Responsive design scales the same layout fluidly, while adaptive design swaps in a distinct layout at defined breakpoints, and most production apps use a mix of both.

Window size classes, compact, medium, and expanded, give a consistent way to decide when a bottom tab bar should become a navigation rail, or when a single-column list should split into a grid. Orientation changes deserve their own check: a form that works in portrait can lose its primary action below the fold in landscape if the layout does not reflow. Foldable and split-screen states add a further variable, since an app can be resized mid-session rather than only at launch.

Mobile layouts adapting across screen sizes

The safest approach treats breakpoints as design decisions made early, not a late-stage patch. Testing on an actual range of device widths, rather than a single simulator size, catches the awkward middle ground where a two-column layout looks cramped but a single column wastes space.

7. Loading and placeholder patterns that keep people oriented

A blank screen during a data fetch reads as broken, even when the app is working fine. Skeleton screens, grey placeholder shapes that mirror the eventual layout, reduce that perceived wait by showing structure before content arrives, which tends to feel faster than a spinner even when the actual load time is identical.

Spinners still have their place for short, unpredictable waits where no layout preview is possible, such as a background sync. Progress bars suit longer operations with a known duration, like a file upload, because they give a sense of how much longer the wait will last.

The failure mode to avoid is mismatched expectation: a skeleton screen that never resolves into content, or a spinner that spins well past the point someone expects a result, erodes trust faster than a plain loading message would. Pairing the placeholder with a timeout and a fallback error state covers the case where the data never arrives.

8. Error handling and empty state patterns

An error message that only says something went wrong gives someone nothing to act on. A workable error state names what failed in plain language, offers a next step (retry, go back, contact support), and avoids blaming the user for a problem the system caused.

Empty states deserve the same care as error states, since a blank screen with no explanation reads as broken rather than simply unused. A good empty state explains why the screen is empty and, where relevant, gives a direct action to fill it, such as inviting a first contact or creating a first item.

Validation errors on forms work best close to the field that caused them, not bundled into a single banner at the top of the screen, since that forces someone to scroll back and forth to match the error to the field. Keeping error copy specific and the recovery action one tap away reduces abandonment at exactly the point where someone was about to give up.

9. Form input patterns built for mobile keyboards and screens

A form designed for a desktop keyboard tends to fight a mobile one. Matching the keyboard type to the expected input, numeric for a phone number, email layout for an address, reduces the taps needed to switch keyboards mid-form.

Inline validation that checks a field as someone fills it in, rather than only on submission, catches mistakes earlier and avoids the frustration of returning to a long form to fix one field after submitting. Showing which requirement a password still needs, rather than a generic "invalid password" message, keeps the correction specific.

Autofill and platform-level suggestions for addresses, cards, and one-time codes cut form length considerably, and input masks (for dates or phone numbers) reduce formatting errors without adding extra fields. Grouping related fields and keeping the primary action visible above the keyboard, rather than pushed off-screen when it opens, avoids one of the most common mobile form complaints: not being able to see the submit button.

10. Performance choices that shape which patterns survive contact with real devices

A pattern that looks smooth in a prototype can stutter on a mid-range device with a weak connection, and performance constraints often decide which pattern actually ships. Animation is the clearest example: a transition that takes 300 milliseconds on a flagship phone can lag noticeably on older hardware, so testing on representative devices rather than only the newest model matters more than it tends to get credit for.

Lazy loading, fetching images and off-screen content only as someone scrolls toward it, keeps initial load times down on long lists and carousels, which matters directly for the loading patterns covered earlier. Pairing lazy loading with a skeleton placeholder, rather than a blank gap, keeps the scroll feeling continuous instead of jumpy.

Heavy use of transparency, blur, or parallax effects can also drain battery and add visible jank on lower-powered devices, so reserving those effects for moments that earn their cost, a key transition or a celebratory confirmation, protects performance where it matters most: the everyday screens someone uses dozens of times a day.

10. Performance choices that shape which patterns survive contact with real devices — overview diagram

11. Internationalisation and localisation challenges in mobile UI

Text length varies substantially between languages, and a label that fits comfortably in English can overflow a button or wrap awkwardly in German or Finnish. Designing layouts with flexible text containers, rather than fixed-width labels, avoids most of this without extra engineering work later.

Right-to-left languages such as Arabic and Hebrew need more than mirrored text: navigation order, icon direction (back arrows, progress indicators), and even swipe gesture direction should mirror as well, or the interface will feel inconsistent even to someone who cannot articulate why.

Date formats, currency symbols, and number separators differ by locale and need handling at the data layer rather than hardcoded in the interface. Icons also carry cultural weight: a gesture or symbol that reads clearly in one market can carry an unintended meaning elsewhere, which is worth a sense check before an icon ships globally rather than after.

12. The trade-offs worth making deliberately

Native components win on performance and platform familiarity, but they cost development time to implement twice across iOS and Android. Custom patterns buy brand differentiation at the cost of losing free accessibility support and platform convention, so the trade-off usually comes down to how much a given screen genuinely needs to stand out versus simply needs to work. The heuristic we keep coming back to: spend the custom-build budget on the one or two screens that define the brand, and let the system handle everything else, benefiting from AI technology in web app development.

— Paul

FAQ

What are mobile UI patterns?

Mobile UI patterns are recurring, reusable solutions to common interface problems, such as tab bars for navigation or skeleton screens for loading states. Designers use them because they are already familiar to users, which reduces the learning curve for a new app.

What is the minimum touch target size for mobile apps?

WCAG 2.2 guidance sets 44 by 44 CSS pixels as a usable minimum touch target, with many accessibility practitioners recommending 48 by 48 pixels for frequent or critical controls. Spacing between adjacent targets matters as much as the size itself, since tight spacing increases mis-taps even when each target meets the minimum.

Material Design 3 guidance recommends 3 to 5 destinations in a bottom navigation bar, kept consistent across every screen. Fewer destinations stay scannable, while more than five tends to push people toward the overflow menu they were meant to avoid.

A tab bar suits 3 to 5 destinations someone returns to often, since it keeps them visible and reachable at all times. A hamburger menu works better for secondary or infrequent actions, though it trades away discoverability, so reserve it for options people search for rather than stumble across.

How does Pocket App help teams choose the right UI patterns?

Our app design service folds pattern selection and accessibility checks into the discovery and design stages of a project, rather than leaving them for a later review. For teams that want a fast second opinion on an existing design, our Mobile App Clinics offer a short, practical review session.