UX Patterns Guide
UI + UX Cross-Device And Physical Interaction standard

Touch gesture

Design a gesture contract that uses familiar platform gestures, exposes large enough targets, shows start/move/commit/cancel feedback, separates scroll from action gestures, and provides single-pointer and control-based alternatives for path-based or multipoint functions.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A touchscreen interaction needs deliberate design for gesture vocabulary, thresholds, feedback, target sizing, cancellation, and equivalent controls.
  • The product supports direct manipulation such as zooming, panning, moving, rotating, selecting, dismissing, or navigating by touch.
  • The same feature must work across touch, pointer, keyboard, assistive technology, and platform conventions.

Avoid when

  • The gesture is only an implementation detail inside a more specific pattern such as swipe action, pull to refresh, long press, drag and drop, bottom sheet, carousel, or map view.
  • The action can be better expressed as a visible button, menu, segmented control, slider, stepper, or form control.
  • The gesture conflicts with system navigation, browser behavior, or assistive technology and cannot be safely resolved.
  • The product cannot provide equivalent controls for non-essential multipoint or path-based functions.

Problem it prevents

Touch gestures can make interfaces feel direct and efficient, but hidden, path-based, multipoint, undersized, or scroll-conflicting gestures exclude users and cause accidental activation when the product does not provide equivalent controls, clear thresholds, cancellation, or feedback.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Touch gesture in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The interface supports touch input on phones, tablets, kiosks, touch laptops, drawing surfaces, maps, media viewers, carousels, boards, canvases, or spatial controllers.

Pattern promise

Design a gesture contract that uses familiar platform gestures, exposes large enough targets, shows start/move/commit/cancel feedback, separates scroll from action gestures, and provides single-pointer and control-based alternatives for path-based or multipoint functions.

Required state

Idle state with visible touch targets, gesture hints when needed, and no reliance on hover.

Recovery path

A map can only zoom with a two-finger pinch.

Access contract

Provide a simple single-pointer alternative for multipoint or path-based gestures unless the gesture is essential.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A photo viewer supports pinch to zoom, double tap to zoom, plus and minus buttons, a reset button, zoom percent feedback, and a clear pan boundary after zoom.
  • A card carousel supports horizontal swipe but also shows previous and next buttons, page position, touch target spacing, and a drag preview that cancels when released before threshold.
  • A user pinches a diagram to zoom, sees the scale change, releases outside the threshold without committing a rotate gesture, then uses visible Zoom in and Reset controls with one finger.
  • A user starts swiping a gallery card, sees the next-card preview, changes their mind by moving back under the threshold, and the card snaps back with position unchanged.
Weak implementation

Vague, hidden, hard to recover from

  • A map can only be zoomed with a two-finger pinch and has no plus, minus, or reset controls.
  • A hidden edge swipe deletes a message while the user is trying to scroll the list.
  • A user with a head pointer cannot trigger a two-finger gesture and has no single-pointer alternative.
  • A user tries to scroll a feed but the product interprets a short diagonal movement as a destructive swipe action.
UI guidance
  • Render touch gesture affordances with visible targets, enough spacing, state feedback, and non-gesture controls for the same outcome when a gesture is path-based, multipoint, hidden, or easy to misfire.
  • Use platform-standard gesture meanings for tap, double tap, swipe, drag, pinch, spread, rotate, and edge gestures, and show inline hints or handles only where users need to discover a custom gesture.
UX guidance
  • Use touch gesture when the product needs direct manipulation on a touchscreen, but treat gestures as part of a larger interaction contract rather than the only way to act.
  • Make gesture recognition predictable by defining start target, movement threshold, direction, velocity, cancellation, conflict with scroll, feedback while moving, commit boundary, and equivalent tap or button path.
Implementation contract

What the implementation must handle

States

  • Idle state with visible touch targets, gesture hints when needed, and no reliance on hover.
  • Touch down or gesture start state that identifies the active target.
  • Move or preview state showing direction, distance, scale, rotation, selected object, or next outcome.
  • Threshold-not-met cancellation state that snaps back or leaves content unchanged.

Interaction

  • The gesture starts only from the intended target or gesture region, not from unrelated content.
  • Movement thresholds, velocity thresholds, direction locks, and edge zones are defined before implementation.
  • Feedback begins early enough for users to know whether they are scrolling, panning, dragging, swiping, zooming, rotating, selecting, or dismissing.
  • Users can cancel before the commit boundary by reversing, releasing outside, pressing cancel, or using a visible reset where the platform supports it.

Accessibility

  • Provide a simple single-pointer alternative for multipoint or path-based gestures unless the gesture is essential.
  • Provide keyboard and assistive-technology alternatives for gesture outcomes.
  • Use visible target size and spacing that reduce accidental activation for touch and other pointer users.
  • Do not rely on hover-only hints to explain touch gestures.

Review

  • Which exact function depends on touch, path, velocity, pointer count, or contact duration?
  • What visible control performs the same function for users who cannot do the gesture?
  • How do users know when the gesture has started, crossed threshold, canceled, or committed?
  • What prevents scroll, pan, swipe, pull-to-refresh, drag, and system back gestures from fighting each other?
Evidence trail

Source-backed claims behind this guidance

Android Developers: Use touch gestures

Android Developers - checked

Supports platform gesture conventions, common gesture detection, multi-touch, drag, scale, touch dispatch, and the warning not to depend on gestures for basic behavior.

Full agent/debug reference

Problem Context

  • The interface supports touch input on phones, tablets, kiosks, touch laptops, drawing surfaces, maps, media viewers, carousels, boards, canvases, or spatial controllers.
  • The same feature may also be used with mouse, stylus, keyboard, switch control, screen reader touch exploration, head pointer, or assistive pointer devices.
  • Gestures can be basic single-pointer actions such as tap and drag, or more demanding path-based and multipoint actions such as swipe, pinch, spread, rotate, two-finger tap, and edge gestures.
  • Gesture conflicts often occur between scrolling, panning, selection, reordering, dismissal, navigation, refresh, zoom, drawing, and destructive actions.

Selection Rules

  • Choose touch gesture when the design question is the recognition, feedback, fallback, and cancellation behavior of touch input itself.
  • Use swipe action when the pattern is specifically a horizontal or directional item action such as archive, delete, complete, or reveal action buttons.
  • Use pull to refresh when the vertical drag from scroll top refreshes content.
  • Use long press when sustained contact reveals context menus, selection, preview, or drag pickup.
  • Use drag and drop when the core task is moving an object from a source to a destination.
  • Use bottom sheet when the gesture changes a detented bottom overlay; document the sheet-specific scroll-versus-drag priority there.
  • Use carousel, map view, data visualization, or calendar view when the primary pattern is the content surface and gestures are only one input method inside it.
  • Provide simple single-pointer controls for any function that otherwise requires a multipoint or path-based gesture unless the gesture is essential to the task.
  • Do not hide critical, destructive, security, payment, consent, or account actions behind an undiscoverable gesture-only shortcut.

Required States

  • Idle state with visible touch targets, gesture hints when needed, and no reliance on hover.
  • Touch down or gesture start state that identifies the active target.
  • Move or preview state showing direction, distance, scale, rotation, selected object, or next outcome.
  • Threshold-not-met cancellation state that snaps back or leaves content unchanged.
  • Commit state after the gesture passes a clear threshold or release boundary.
  • Conflict state where scroll, pan, drag, swipe, refresh, or edge navigation wins predictably.
  • Single-pointer alternative state for multipoint or path-based functions.
  • Equivalent button or menu state for users who cannot or do not discover the gesture.
  • Target-size and spacing state for compact controls.
  • Disabled, unavailable, or system-reserved gesture state with explanation.
  • Undo, reset, or recovery state for reversible gesture outcomes.
  • Mobile compact, large-text, landscape, stylus, and assistive-touch states.

Interaction Contract

  • The gesture starts only from the intended target or gesture region, not from unrelated content.
  • Movement thresholds, velocity thresholds, direction locks, and edge zones are defined before implementation.
  • Feedback begins early enough for users to know whether they are scrolling, panning, dragging, swiping, zooming, rotating, selecting, or dismissing.
  • Users can cancel before the commit boundary by reversing, releasing outside, pressing cancel, or using a visible reset where the platform supports it.
  • Multipoint or path-based gestures have simple single-pointer alternatives such as buttons, handles, steppers, menus, or tap targets.
  • Gesture shortcuts do not replace keyboard, screen reader, switch, pointer, mouse, stylus, or assistive-device operation.
  • Targets meet minimum size or spacing expectations, or equivalent controls are available on the same page.
  • System gestures, browser gestures, assistive-technology gestures, and platform navigation gestures are not overridden unless the platform explicitly supports the custom behavior.

Implementation Checklist

  • Inventory every touch gesture, target region, affected object, outcome, threshold, pointer count, direction, speed, and commit boundary.
  • Define whether each gesture is basic, path-based, multipoint, dragging, system-reserved, or content-specific.
  • Add visible controls for zoom, reset, previous, next, move, dismiss, select, refresh, rotate, or recover when the gesture is not enough.
  • Set target size and spacing for touch controls and avoid placing dangerous actions near routine scroll or navigation targets.
  • Provide live feedback for start, movement, invalid direction, threshold reached, cancellation, commit, undo, and failure.
  • Resolve conflicts between vertical scroll, horizontal swipe, nested panning, drag handles, pull-to-refresh, browser back, and screen-reader touch exploration.
  • Test one-handed use, thumb reach, tremor, slow movement, accidental diagonal movement, multi-touch failure, stylus, mouse, keyboard, screen reader, zoom, large text, and landscape.
  • Record analytics for failed gesture attempts only in aggregate and without logging sensitive path or content data.

Common Generated-UI Mistakes

  • Requiring pinch, rotate, two-finger swipe, or shape gestures with no single-pointer alternative.
  • Making a hidden gesture the only way to find navigation, delete, refresh, zoom, or edit controls.
  • Letting short diagonal scroll movements trigger swipe actions.
  • Using tiny targets or placing opposing actions too close together.
  • Overriding operating-system, browser, or assistive-technology gestures.
  • Committing actions on touch down instead of release or a clear threshold.
  • Providing no cancel, undo, reset, or recovery for high-friction gesture mistakes.
  • Assuming desktop hover hints will teach mobile users a gesture.

Critique Questions

  • Which exact function depends on touch, path, velocity, pointer count, or contact duration?
  • What visible control performs the same function for users who cannot do the gesture?
  • How do users know when the gesture has started, crossed threshold, canceled, or committed?
  • What prevents scroll, pan, swipe, pull-to-refresh, drag, and system back gestures from fighting each other?
  • Are targets large enough and spaced far enough to prevent accidental activation?
  • What happens for screen reader touch exploration, switch control, head pointer, stylus, mouse, keyboard, large text, and landscape?
  • Is this better handled as a named pattern such as swipe action, pull to refresh, long press, drag and drop, bottom sheet, or carousel?
Accessibility
  • Provide a simple single-pointer alternative for multipoint or path-based gestures unless the gesture is essential.
  • Provide keyboard and assistive-technology alternatives for gesture outcomes.
  • Use visible target size and spacing that reduce accidental activation for touch and other pointer users.
  • Do not rely on hover-only hints to explain touch gestures.
  • Announce gesture results such as zoom level, page position, selected object, dismissed item, moved item, canceled action, and restored state.
  • Avoid requiring precise paths, speed, simultaneous fingers, or sustained pressure for critical actions.
  • Keep system, browser, and screen-reader gestures available whenever possible.
Keyboard Behavior
  • Keyboard users can activate the same outcomes through buttons, menu items, steppers, sliders, or commands.
  • Focus order reaches the equivalent controls near the gesture surface.
  • Arrow keys, plus and minus, Escape, Enter, Space, and dedicated controls follow platform expectations for the component being manipulated.
  • Escape or Cancel reverses an in-progress gesture preview where an equivalent keyboard path exists.
  • After a gesture-equivalent action, focus stays near the manipulated object or updated status.
  • Keyboard alternatives expose the same disabled, invalid, committed, canceled, reset, and undo states as touch gestures.
Variants
  • Tap gesture
  • Double-tap gesture
  • Swipe gesture
  • Fling gesture
  • Pan gesture
  • Pinch to zoom
  • Spread to zoom
  • Rotate gesture
  • Two-finger gesture
  • Edge gesture
  • Gesture with visible controls
  • Gesture cancellation
  • Gesture conflict resolution

Verification

Source trail checked:

Saved items