Skip to content
UX Atlas
Plate PAT·027 · PatternGrid E1 · Rev. 2026-09-14

Mobile Interaction Patterns

The conventions phones have settled on, what each one is actually for, and where they break.

PatternCraft conventionIntermediate

Definition

Mobile patterns are the structures people already know from the platform: tab bars, sheets, swipe actions, pull to refresh. Their value is recognition, so deviating from them costs more here than on the web.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2Patterns and their conditions
  3. 3The physical constraints
  4. 4Adapting from desktop
  5. 5Gestures, and the visible control each one needs
  6. 6What a thumb can actually reach
  7. 7In practice
  8. 8Local chart
  9. 9Sources
  10. 10Continue from here

Reach for this when

  • Designing a mobile app or a mobile web experience.
  • Adapting a desktop interface for small screens.

Common mistakes

  • Gesture-only actions.
  • Content under the home indicator or the notch.
  • Tab bars carrying sub-navigation.
  • Desktop tables shrunk rather than reshaped.
  • Designing at a desktop-sized artboard scaled down, which hides both the reach problem and the keyboard problem.

Patterns and their conditions

PatternUse whenBreaks when
Bottom tab barThree to five top-level destinations of equal standingIt carries sub-navigation, or the count grows past five.
Bottom sheetA focused task that keeps the context visible behind itIt stacks, or it holds a form longer than the visible area.
Swipe actions on a rowA frequent action on a list itemIt is the only route to the action, or the affordance is invisible.
Pull to refreshA feed whose freshness mattersThe content updates automatically anyway, or the list is not the top scroll region.
Long pressSecondary actions for experienced usersIt hides something people need on their first day.

The physical constraints

  • Reach: the top corners of a large phone are hard to hit one-handed, so primary actions belong low.
  • Target size: at least 44 by 44 points on iOS, 48 by 48 density-independent pixels on Android, with spacing between adjacent targets.
  • Safe areas: the notch, the status bar and the home indicator all overlap content that ignores them.
  • Interruption: mobile sessions are short and interrupted, so state must survive backgrounding.
  • Connectivity: the network is worse than your office. Design the offline and slow paths deliberately.

Adapting from desktop

Do

  • Give every gesture a visible equivalent.
  • Replace wide tables with a per-record layout rather than a horizontally scrolling grid.
  • Use the platform's own controls for dates, selection and sharing.
  • Keep the primary action reachable with a thumb.

Do not

  • Do not stack a desktop layout and call it responsive.
  • Do not disable zoom, or set a font size that triggers automatic zoom on focus.
  • Do not put destructive actions where a swipe can reach them by accident.
  • Do not block system gestures with your own.

Gestures, and the visible control each one needs

A gesture is an accelerator for people who know it. Every row here needs a route that does not depend on knowing.

GestureVisible alternative
Swipe a row to delete or archiveThe same actions in a row menu
Pull to refreshA refresh control, or automatic refresh on return
Long press for a context menuA visible overflow control
Pinch to zoom an imageZoom controls, and a full-screen view
Swipe between tabsTapping the tabs themselves
Drag to reorderMove up and move down actions, reachable by keyboard

What a thumb can actually reach

hardstretcheasystatus, titles,rarely used actionscontentprimary actions,navigation, searchanything used oftendoes not belong herereachable one-handed,so keep delete out of itRight hand on a large phone. Mirror it for the left, and assume both.
Designs are reviewed on a desktop screen where every part of the layout is equally easy to click. On a phone held in one hand, it is not.

In practice

  1. i.

    Table to list on a phone

    A twelve-column table cannot be read on a 375 pixel screen. Showing the two identifying columns plus the one the reader sorted by, with the rest on a detail view, keeps the task possible without a horizontal scrollbar.

  2. ii.

    Submit behind the keyboard

    A layout that only fails on device

    A form whose submit button sat at the bottom of the viewport was covered by the keyboard on every phone. It looked correct in every design tool, and the failure only exists in the hand.

Local chart

PAT·027 · Region III · Grid E1

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Fitts's LawLAW·002 · PRINCIPLES BEHIND THISAdaptive LayoutFND·044 · PRINCIPLES BEHIND THISResponsive LayoutFND·043 · PRINCIPLES BEHIND THISTarget SizeA11Y·011 · DEPENDS ONDrawer and SheetCMP·011 · OFTEN USED WITHNavigationPAT·001 · OFTEN USED WITHPutting a Data Table on a PhoneCASE·005 · PRACTICAL EXAMPLEMobile UX ChecklistCHK·003 · CHECK YOUR WORK

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

  1. [1]

    Human Interface Guidelines

    Apple

    Source of the 44 point target minimum and of platform gesture conventions.

  2. [2]

    Material Design Guidelines

    Google

    Source of the 48 dp target minimum and of bottom navigation limits.

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Principles behind this

The reasoning this solution is an application of.

Depends on

Get these right first, or this one will not hold.

Often used with

These usually appear in the same screen or the same decision.

Practical example

A worked decision where this was the deciding factor.

Check your work

Review passes that test whether this was done properly.