Mobile Interaction Patterns
Date: 2026-08-17
Touch is not a small mouse. The finger is imprecise, it covers what it touches, there is no hover, and the hand holding the device can only reach part of the screen — and most mobile usability problems are one of those four facts being ignored.
Mobile interaction differs from pointer interaction in kind, not scale. The four differences drive nearly everything.
The four facts
1 THE FINGER IS BLUNT
contact area far larger than a
cursor's hotspot
→ targets ~44px minimum, spaced
— Fitts's Law
2 THE FINGER OCCLUDES
it covers what it touches
→ feedback must appear ABOVE or
AWAY from the point of contact
→ tooltips under the thumb are
invisible
3 THERE IS NO HOVER
no intermediate state
→ anything revealed on hover is
unreachable, or fires on first
tap and confuses
4 REACH IS LIMITED
thumb arc covers the lower and
centre; top corners are a stretch
→ primary actions belong at the
BOTTOM
See: Fitts’s Law
Fact 3 causes the most bugs. A hover-revealed menu on a touch device produces a “tap once to reveal, tap again to activate” behaviour that nobody designed and everybody experiences.
The thumb zone
┌─────────────────┐
│ HARD HARD │ ← top corners:
│ │ back buttons,
│ OK OK │ close icons —
│ │ habit, not
│ EASY EASY │ ergonomics
│ EASY EASY │
└─────────────────┘
bottom = easiest
This inverts the desktop convention. Primary navigation and primary actions belong at the bottom on touch — which is why bottom tab bars and sticky bottom action bars work — Wayfinding.
Sticky bottom bars are the highest-value mobile pattern in retail: add-to-basket on a product page, “Show 23 results” on a filter panel, the total and continue button in checkout.
Gestures
EXPECTED, SAFE
vertical scroll
tap
pinch to zoom ← never disable
swipe back (system)
USE WITH A VISIBLE ALTERNATIVE
horizontal swipe in a carousel
swipe to delete
pull to refresh
AVOID
long-press as the only route
multi-finger gestures
custom gestures conflicting with
system ones
Gestures are invisible. Nothing on screen indicates a swipe is possible, so every gesture needs a visible equivalent — a discoverable control doing the same thing.
Never disable pinch-to-zoom. user-scalable=no breaks the primary accommodation for low vision, and it’s still present in a great many templates — Cognitive Accessibility.
Input
The cheapest mobile wins are attributes:
<input type="email" inputmode="email"
autocomplete="email">
<input type="tel" inputmode="tel"
autocomplete="tel">
<input inputmode="numeric"
autocomplete="postal-code">FONT SIZE ≥16px on inputs
→ below this, iOS zooms on focus and
the layout jumps
AUTOCOMPLETE attributes
→ the browser fills the form, faster
and more accurately than any UI
WALLET PAYMENT first
→ skips the form entirely
— Checkout Design
See: Checkout Design
The 16px rule is the most commonly-missed one-line fix on mobile checkouts.
Patterns that translate badly
DESKTOP MOBILE
hover menus → tap-to-open,
explicit close
wide tables → cards, or
horizontal scroll
with a visible cue
multi-column forms → one column, always
— Form Design
sidebar filters → full-screen panel
with an apply button
— Faceted Filtering
tooltips → inline text, or
a tap-to-reveal
detail
carousels → still poor, but at
least native-scroll
with a peeking next
item
See: Form Design · Faceted Filtering
A carousel showing exactly one full item gives no signal there are more. Showing a sliver of the next one is the whole fix — Affordances and Signifiers.
Context, not just screen size
Mobile use differs beyond the viewport:
INTERRUPTED short sessions, resumed
→ save state, don't
lose the basket
ONE-HANDED often, while doing
something else
VARIABLE NETWORK slower, lossier
— Latency and Bandwidth
CONSTRAINED CPU mid-range Android is the
realistic target, not
the newest phone
BRIGHT LIGHT contrast matters more
— Colour Contrast
See: Latency and Bandwidth · Colour Contrast
Test on a mid-range device with throttled network. A recent flagship on office wifi hides every problem in this note — Percentiles in Performance.