Design

Hands UI best practices

Updated: Sep 24, 2026

One of the most common use cases for interactions in VR apps is user interfaces (UI). The guidance on this page is specific to designing UI for hand input.

Choosing the right interaction model for UI

There are two primary models for VR users to interact with UI.

Model	Guidance
Direct interaction (touch)	Works best for UI within arm’s reach of the user with a small number of buttons. The most intuitive option, since users instinctively reach to tap. Best option for VR games built around direct interactions, where gameplay is built around using virtual hands to interact directly with virtual objects. Use ISDK Poke Interaction.
Indirect interaction (ray cast or gaze)	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. The most comfortable option, since it requires less arm motion than direct interaction. Best option for entertainment, productivity, and utility apps, or games that do not use direct interactions for gameplay. Use ISDK Ray Interaction.
Hybrid	A hybrid interaction model enables users to interact with UI directly, such as poking, or indirectly. If the hand is far from the UI, indirect interactions are active, but if the hand enters close proximity to the UI, the interaction model switches from indirect to direct. This is best for apps with multiple UI panels that users can position dynamically.

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: a palm-up index pinch with the non-dominant 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.

Video: A user turns their palm up and pinches with the index finger to open the options menu.

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 roughly 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: roughly 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 device’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, also called 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. 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. For the button press animation in Unreal, see Adding recoil.
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. See touch limiting for Unity and Unreal.
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.

Indirect interactions

Use indirect interactions, such as ray casting or gaze, 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

Indirect interaction is comfortable from roughly 0.8m to 3m. Inside that range, users can target panels without straining their arm or struggling to read content. Avoid placing UI for indirect interactions closer than 0.8m, to avoid confusion from users who might expect to be able to interact with it directly.

If a UI can move along the z-axis, closer to 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.

Use ray cast 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 (hybrid interactions)

Many panels are 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, such as the cursor, reticle, and hover state, so the user understands which mode is active.
Avoid placing UI in the middle distance, roughly 0.5m to 0.8m from the user, when possible. Either bring the panel into clear direct-touch range, under roughly 46cm, or push it well into raycast range, 1m or more.
Show a mode indicator when the panel transitions. When the panel exits direct-touch range, the cursor or hover style should change visibly to a raycast reticle so the user understands what changed.
Test the handoff zone explicitly. Mid-distance handoffs are where most users lose the thread. Verify the visual transition is unmistakable.

UI scrolling

For UIs that support direct interactions, use index swipe as a primary method for scrolling. The user pokes their index finger through the panel and then drags it up or down across the panel content.

For UIs that support indirect interactions, use ISDK microgesture thumb swipe for scrolling in addition to pinch-and-drag. To implement microgestures, see Unity and Unreal.

Do not use traditional scroll bars that require users to directly target and select a visible scroll bar in order to move the UI. Users should be able to scroll UIs while targeting anywhere on the panel, using the interactions described above.

Size the window so content is visibly 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 the user’s wrist

Avoid anchoring menus to the user’s hand or 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 prone to misinterpretation.

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.

Hover states: show clear hover feedback so the user knows what they are about to select before they commit.
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.

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.

Making UI interactions cohesive with gameplay interactions

When indirect controls, such as ray cast or gaze, on UI sit alongside 3D direct manipulation, such as grabbing or tapping objects, users can experience role confusion where it is not visually obvious which actions need direct physical interaction and which need indirect menu input. In practice, users may attempt to reach for UI buttons that they are intended to raycast at, or they may raycast at game objects they are intended to grab.

Design accordingly:

Where possible, make your UI interaction model similar to your gameplay interactions. If your game primarily involves interacting directly with objects, use direct interactions for your UI.
Make the input mode visually obvious for each target. Use distinct affordances for grabbable 3D objects and clickable spatial UI: different highlight styles, different cursor behavior, and different hover feedback.
Group by interaction type when possible. Cluster all the menu-driven actions on a well-bounded panel, and leave the direct-manipulation surface visually clean. Mixing the two in the same visual space is the worst case.
Use audio and visual feedback to teach the mode on first interaction. Distinct sounds for grabbing something and for selecting a menu item help users build the mental model quickly.

Constrain panel rotation

If your app supports panel movement, panels should always orient, in pitch and yaw, toward the user so they remain legible and interactive. Constrain movement on the panel’s roll.

Dos and don’ts

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

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-and-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.