VR Interaction Design

Purpose

A VR interaction design document is the authoritative specification for how players physically interact with a virtual reality experience. It defines every input modality the project supports—hand tracking gestures, motion controller button and trigger mappings, gaze-based selection, and voice commands—along with the locomotion system (teleport, smooth movement, room-scale bounds), comfort settings that mitigate motion sickness, haptic feedback patterns, guardian/chaperone boundary behavior, and spatial UI placement rules for menus, HUDs, and tooltips anchored in 3D space.

VR interaction is fundamentally different from flat-screen input. A traditional game can rely on decades of established conventions: WASD movement, mouse-look, radial menus. VR has no such consensus. Teleportation vs. smooth locomotion is a comfort tradeoff, not a preference. Hand tracking accuracy varies by headset generation. Gaze-based interaction works well for selection but poorly for continuous manipulation. Without a document that makes these design decisions explicit, each developer implements their own interpretation. One engineer builds a teleport arc with a 10-meter range; another caps it at 5 meters. A UI designer places a health bar at chest height; the locomotion system jitters it during movement because nobody specified that world-locked UI must be decoupled from the player rig’s vertical axis.

The consequences of missing this document are physical: poorly designed locomotion triggers nausea, mismatched haptic feedback breaks immersion, and absent comfort options make the game unplayable for large segments of the audience. A VR interaction design document prevents these failures by making every interaction decision measurable, testable, and traceable to a design rationale.

Who needs this document

What separates a good version from a bad one

Criterion 1: Locomotion methods are specified with comfort parameters

✓ Strong: “Teleport: parabolic arc, max range 8m, arc rendered as dashed line (color: #00FF88, 2px width), valid landing zones highlighted with 0.5m radius ring. Smooth locomotion: default speed 2.0 m/s, configurable 1.0–3.5 m/s, vignette tunneling enabled by default (FOV reduction to 80° during movement, 200ms ease-in). Snap turn: 30° increments, 45° optional. Smooth turn: disabled by default, unlock in comfort settings.”

✗ Weak: “Players can teleport or walk around. Add comfort options.” (No arc parameters, no speed limits, no vignette specification. Every developer will implement a different teleport distance, and “comfort options” without specifics means they will be the last thing built and the first thing cut.)

Criterion 2: Controller and hand tracking mappings are defined per platform

✓ Strong: “Quest Touch Pro: grip button = grab (threshold 0.7), trigger = interact (threshold 0.5), thumbstick click = teleport initiate, thumbstick push = smooth locomotion. Hand tracking: pinch gesture (thumb-to-index distance < 2cm) = select, palm-open at 45° toward object = grab initiate, fist clench (all fingers curled > 80°) = grab confirm. Fallback: if hand tracking confidence drops below 0.6 for 3 consecutive frames, prompt controller reconnection.”

✗ Weak: “Support hand tracking and controllers.” (No button assignments, no gesture definitions, no confidence thresholds. Hand tracking without explicit gesture specs produces unreliable interactions that frustrate players.)

Criterion 3: Spatial UI follows documented placement and readability rules

✓ Strong: “Primary HUD elements: world-locked, 1.5m from player head, 15° below eye line, curved panel radius 2.0m. Font minimum: 24pt equivalent at render distance (0.8mm per unit at 1.5m). Tooltip panels: tag-along with 500ms delay, max 0.4m width, anchored to interaction hand’s wrist-up vector. Menus: spawned at controller point position + 0.3m forward offset, face player head (billboard Y-axis only).”

✗ Weak: “UI should float in front of the player and be readable.” (No distance, no angle, no font scaling. “Readable” means nothing without a minimum angular size specification—text that’s legible at 1m is illegible at 3m.)

Criterion 4: Haptic feedback and comfort safeguards are specified numerically

✓ Strong: “Grab confirmation: single pulse, 0.3 amplitude, 50ms duration. Collision with boundary: triple pulse, 0.8 amplitude, 30ms on / 20ms off pattern. Motion sickness safeguards: if headset acceleration exceeds 2.5 m/s² for more than 300ms during smooth locomotion, auto-reduce speed by 30% and increase vignette by 10°. Guardian proximity: fade-in translucent grid at 0.5m from boundary, solid wall at 0.2m, force snap-back at 0.0m.”

✗ Weak: “Add haptic feedback when the player grabs things. Warn them if they get close to the boundary.” (No amplitudes, no durations, no distance thresholds. Haptics without numbers produce inconsistent buzzing that feels arbitrary rather than informative.)

Common mistakes

Designing only for standing room-scale. The interaction design assumes a 2m × 2m play space with full arm extension. Players in seated mode, wheelchair users, or those with limited mobility cannot reach objects placed at standing head height. Define a seated-mode profile with adjusted UI heights, reachability envelopes, and one-handed interaction alternatives for every two-handed gesture.

Treating locomotion as a single choice. The document specifies teleport-only or smooth-only and offers no runtime switching. Different players have different comfort tolerances, and comfort changes within a session (a player fine with smooth movement in open areas may need teleport in tight corridors). Specify all supported locomotion modes as runtime-switchable options with per-mode comfort defaults.

Ignoring hand tracking degradation. Hand tracking is specified as the primary input but the document never addresses what happens when tracking is lost—hands pass through objects, occluded fingers trigger phantom gestures, or tracking confidence drops in low light. Define explicit fallback behavior, confidence thresholds for each gesture, and visual feedback when tracking quality is degraded.

No motion sickness testing protocol. The document describes comfort features but includes no testing criteria. Without a defined protocol (minimum session length, specific locomotion stress tests, nausea severity scale), comfort settings are tuned by developers who have already adapted to VR and no longer experience the discomfort that new players will.

How to use this document

When to create it

Create the VR interaction design during pre-production, immediately after the game design document establishes the core gameplay mechanics and before any locomotion or input code is written. If the project is prototyping VR interactions, the document should codify the decisions made during prototyping—it captures what worked and formalizes the parameters. Update it when adding new input modalities (e.g., eye tracking support), when platform requirements change (new headset SDK), or after each comfort playtest round.

Who owns it

The VR interaction designer or UX lead owns this document. On teams without a dedicated VR designer, the person implementing the locomotion and input systems owns it. The accessibility lead should co-author the comfort settings and seated-mode sections. Changes to any interaction parameter must update the document before code is modified, so the document remains the single source of truth for every grab threshold, teleport distance, and haptic amplitude in the project.

How AI agents should reference it

get_standard_docs(type="video_game", features=["vr"])
→ vr_interaction_design in documents[]
→ agent reads interaction design before generating any VR input or locomotion code
→ agent applies documented controller mappings and gesture thresholds
→ agent enforces comfort parameters (vignette FOV, teleport range, snap turn angle)
→ agent validates spatial UI distances and font scaling against documented minimums

The prompt_snippet — “Ensure the project has a VR interaction design document covering hand tracking, gaze input, locomotion methods, and spatial UI patterns” — tells the agent to verify that all four interaction dimensions are present with measurable parameters rather than subjective descriptions.

How it connects to other documents

The VR Interaction Design is downstream of the Game Design Document, which establishes the gameplay mechanics that interactions must support. It feeds the VR Performance Budget (which allocates frame time for hand tracking processing, haptic driver calls, and UI rendering), the Accessibility Plan (which inherits the seated-mode profile, one-handed alternatives, and comfort settings defined here), and the Control/Input Specification (which maps the abstract interaction intents from this document to platform-specific hardware bindings). Changes to locomotion methods or input modalities ripple into all three downstream documents.

Recommended Reading

• The VR Book: Human-Centered Design for Virtual Reality by Jason Jerald — Comprehensive treatment of VR interaction principles, comfort science, and human perception constraints that directly inform locomotion and UI placement decisions.
• Designing Immersive 3D Experiences by Renée Stevens — Practical frameworks for spatial interaction design, gesture vocabularies, and the unique UX challenges of head-mounted displays.
• 3D User Interfaces: Theory and Practice by Joseph LaViola Jr., Ernst Kruijff, Ryan McMahan, Doug Bowman & Ivan Poupyrev — Academic yet actionable coverage of selection, manipulation, navigation, and system control techniques in 3D environments.
• Oculus VR Best Practices Guide (Meta) — Platform-specific comfort guidelines, rendering requirements, and interaction standards that inform cross-platform VR interaction design.