Design

Hands UI best practices

Updated: May 18, 2026

One of the most common surfaces hands meet is spatial UI. The guidance on this page is specific to designing spatial UI for hand input in immersive apps.

For broader guidance on hands as an input modality, including philosophy, gesture vocabulary, and overall trade-offs, see Hands best practices. For guidance on hands UI that overlaps with 3D scenes (role confusion, middle-distance UI, panel angles), see Spatial UI inside interactive 3D scenes.

Choosing the right interaction type for spatial UI

Hands offer three primary interaction patterns for spatial UI. Pick the right one based on where the UI lives, how much content it holds, and what the user is doing.

Touch (direct interaction or poke)	Default for in-range UI with a small number of items. The most intuitive option, since users instinctively reach to tap. Best for simple menus and confirmation flows that fit within arm's reach. Use ISDK Poke Interaction.
Ray casting (indirect interaction)	Use for UI beyond arm's reach, or for panels with more items that are easier to navigate from a distance with a stabilized ray than by reaching to tap each one. Use ISDK Ray Interaction.
Microgestures	Specialized for very simple menus where the user swipes and taps without aiming at a target. Useful when the user's hand is at rest or otherwise unavailable for ray or touch. See Microgestures.

Grab is a sub-action used within touch or raycast for window-level manipulation (resize, reposition, snap). Most window grabs in practice are performed with raycast, since touch menus are not typically built for moving windows around. See Window manipulation (grab) below. Use ISDK Grab Interaction.

Design for a seamless transition when a UI supports both direct and indirect. For example, as the user moves their hand closer, switch to touch; as they pull back, fall back to ray casting. For more on input modality selection and how the system falls back between gaze, ray, and touch, see Input hierarchy and fallback behavior.

Support the Meta-recommended in-game options gesture: palm-up index pinch with the left hand. This is the hand-input equivalent of pressing the hamburger button on the left controller and gives users a consistent way to summon the options menu across hand-driven experiences.

Sizing and density

Interactive spatial UI elements need to be large enough and spaced enough that users can target them confidently. Use a physical hit target size as the primary constraint, then verify the angular size meets the minimum for the targeting mode being used.

Minimum hit target: 48dp at panel scale. The 48dp value is the hit target, not the visual button. Use a smaller visual element with ~4 to 6dp of padding around it so the visible button is centered inside a forgiving collider. This draws the user’s eye to the target’s center while keeping selection generous. At the recommended touch distance, 48dp at panel scale works out to roughly 22mm of physical hand-tracking target.

Minimum angular collider size: ~2.5° to 3° for both direct touch and ray casting. Targets that fall below this become hard to hit reliably under hand tremor and tracking variance.

Minimum spacing: 12mm between adjacent interactables to prevent accidental selection from minor hand tremor or brief tracking gaps.

Avoid densely packed UI with many interactable elements close together. Density compounds with hand tremor, tracking variance, and brief occlusion (when one hand blocks the headset’s view of the other) to produce the Midas Touch effect of accidental selections from incidental movement. Targets that meet the minimum size also tolerate the brief tracking gaps that hand tracking inevitably produces.

Keep panels level with the user’s space unless the design intentionally tilts them for a creative reason.

Touch

Touch (direct interaction or poke) is the most intuitive interaction for spatial UI. Users reach toward the panel and physically tap it with their index finger. Designing for direct touch first, rather than as an afterthought, produces a UI that feels familiar and requires almost no learning. For the foundational interaction reference, see Touch usage.

Optimal distance

Position UI between 42cm and 46cm from the user when you want to encourage touch. This range puts the panel within comfortable arm extension without forcing the user to lean forward.

Layout for ergonomics

One distance does not fit all bodies.

When optimizing for touch, place frequently-used elements in the bottom half of the panel. Sustained reaching, pinching, or holding arms elevated produces shoulder and arm fatigue over a session.

Lower elements require less arm reach, reducing fatigue and keeping the head in a neutral position. Top-half elements are still valid. Just consider how often the user will need to lift their arm to reach them. Where possible, let users reposition the UI to find their own comfortable reach.

Button feel

Travel depth: use a default button travel depth of 7mm. A short physical press gives users a satisfying sense of pushing into a real surface.

Touch limiting: apply touch limiting so the virtual hand cannot pass completely through a 2D panel. Hands phasing through the panel breaks the illusion of solidity and removes the spatial cue that an action registered.

Index finger only: reserve direct touch on UI panels for the index finger. Allowing other fingers to trigger UI causes accidental activations as the hand moves near the panel. This is the same false-positive risk that comes from gesture ambiguity in any hand-based input.

Avoid hover-driven complexity

Avoid progressive disclosure of additional actions on hover. When the layout shifts as a user’s finger approaches a button, options can change underneath the finger and the press lands on something the user did not intend. This adds cognitive load and produces a feeling of unpredictability.

Ray casting

Use ray casting when the UI sits beyond comfortable reach, or when a panel holds many small items that would be tedious to tap one at a time.

Comfortable distance range

Ray casting or indirect interaction is comfortable from roughly 0.46m to 3m. Inside that range, users can target panels without straining their arm or struggling to read content.

If a UI can move along the z-axis (closer or further from the user), maintain its angular size rather than its physical size. A panel that stays a fixed physical size becomes harder to read and harder to target as it moves further away. Maintaining angular size keeps it legible and selectable at any distance.

The jitter problem

Ray casting with hands is sensitive to small movements. The pinch gesture itself causes a slight hand shift, which often pulls the ray reticle off small targets. This is a common failure mode for close buttons (the “X”), small toggles, and tightly packed controls.

For the best result, use Interaction SDK’s Ray Interactor, which is optimized for ray interactions and mitigates pinch-caused jitter. If you are not using ISDK, you can access the runtime raycast pose through OpenXR via the XR_FB_hand_tracking_aim extension’s aimPose property.

Stabilization and target magnetism

ISDK includes ray stabilization that smooths the reticle path and helps the user hold the ray on a target through a pinch.

If you layer target magnetism on top of stabilization, tune it carefully. A confirmation box or target that is too sticky can trap user intent and make it hard to select adjacent items in the 3D world. Use stronger magnetism on a primary CTA, and lighter magnetism when the panel sits among other interactable objects.

Use as a fallback to gaze

On devices where eye tracking is available, gaze handles distance targeting. Ray casting serves as the fallback when eye tracking is unavailable. Do not combine gaze and ray casting as simultaneous targeting modes. The two compete for intent and produce unpredictable selection behavior. See Input hierarchy and fallback behavior for how the system selects between targeting modes.

Touch and ray casting transitions

Many panels will be touched directly when close and ray-cast when farther. Design for seamless transitions:

As the user moves their hand toward the panel, switch to direct touch behavior.

As the user pulls back, fall back to ray casting.

Maintain consistent visual feedback (cursor, reticle, hover state) so the user understands which mode is active.

Window manipulation (grab)

For window-level actions like resize, reposition, and snap, use grab. Grab is a sub-action of touch or raycast: most window grabs in practice are performed with raycast, since touch menus are not typically built for moving windows around.

Grab from the panel edges: flat panels feel natural to grab from their edges. Use a clearly visible edge handle so the user knows where the grabbable surface is.

Leave room for grab colliders: when a panel supports edge grabs, keep enough space between side grab colliders and the closest interactable elements that a grab attempt does not register as a poke on a button.

Avoid head-down placement: when placing UI, avoid forcing the user to tilt their head down more than ±15° for extended periods. Head tilt past that range fatigues the neck quickly.

Do not use traditional scroll bars

Users struggle with the ray casting pinch-and-drag motion required to operate traditional 2D scroll bars. Most users fail at the pinch-and-drag scroll bar interaction without explicit teaching, and instinctively reach for an index swipe directly on the panel content instead.

Design accordingly:

Support index swipe as a primary scroll input. The user runs their index finger up or down across the panel content, or uses the ray and pinches and drags to scroll.

Support ISDK microgesture thumb-holds for scrolling when direct swipe is not viable.

Do not rely on raycast pinch-and-drag as the only scroll mechanism.

Size the window so content is clearly cut off at the edge. A visible content clip is the affordance that tells the user the panel is scrollable when no scroll bar is present.

Do not anchor menus to an active wrist

Avoid anchoring menus to an active, moving wrist. A menu that follows the wrist is hard to use because it shifts position while the other hand tries to poke it. The wrist also moves naturally during gameplay, which causes accidental triggers or missed inputs. 2D graphics anchored to a moving wrist, such as “Accept” or “Reposition” prompts, are easy for users to misinterpret.

Spawning a menu from the wrist (for example, when the user looks at their palm) is fine, as long as the menu is static once it appears and is positioned in world space rather than following the wrist. Keep wrist-spawned menus simple, and use spatial placement in front of the user for any primary or complex action.

Audio and visual feedback

Hands have no haptics. Without controller vibration to confirm an action, every successful poke, pinch, or grab needs strong audiovisual feedback to compensate.

Pressed states: every interactive element should change visually on press. Use a color shift, depression, glow, or all three.

Audio cues: pair every successful selection with a short, distinct sound. The sound is the primary confirmation that the action registered.

Hover states: show clear hover feedback so the user knows what they are about to select before they commit.

This is not optional. The lack of haptics means the visual and audio channels are doing the work that vibration does on a controller. Designs that rely on subtle feedback will frustrate users.

Dos and don’ts

DO Use Interaction SDK for your spatial UI interactions. It includes best-practice tunings and affordances out of the box. Start from ISDK's UI Set sample when designing your UI.

DON'T Anchor complex menus to an active, moving wrist. The menu shifts while the other hand tries to poke it, causing missed inputs and accidental triggers.

DO Use visual and audio cues to confirm every successful poke, pinch, or grab. Without haptics, audiovisual feedback is the only confirmation users get that an action registered.

DON'T Make interactive elements too small or pack them too closely together. Density combined with hand tremor causes the "Midas Touch" effect, where slight hand movements lead to accidental selections.

DO Reserve direct touch on UI panels for the index finger. This prevents accidental UI activations from other fingers passing near the panel.

DON'T Use traditional 2D scroll bars. Users struggle with the pinch-and-drag motion required to operate them and instinctively reach for index swipe directly on the panel content.

DO Support index-finger swipe directly on panel content for scrolling. Users naturally reach for swipe before pinch-drag.

DON'T Rely on raycast pinch-and-drag as the only scroll mechanism. Most users fail at this interaction without explicit teaching.

DO Place frequently-used elements in the lower half of the panel and keep UI level with the user's space. This reduces reach fatigue and keeps the head in a neutral position.

DON'T Use progressive disclosure that changes button layouts on hover. Options shifting beneath the user's finger lead to accidental presses on unintended controls.

DO Use Interaction SDK's Ray Interactor for hand ray casting. It mitigates pinch-caused jitter. If you are not using ISDK, access the runtime raycast pose through OpenXR via the `XR_FB_hand_tracking_aim` extension's `aimPose` property.

DON'T Combine gaze with ray casting as simultaneous targeting modes. Use ray casting only as a fallback when eye tracking is unavailable.