Spatial UI/UX Design Principles: Why Flat Design Rules Don’t Apply in XR 🧠
❌ Why 2D Design Rules Break in XR
Flat UI was designed for one thing: a rectangle on a desk.
Fixed dimensions. Known viewing distance. Mouse precision. Gravity doesn’t exist. Depth doesn’t exist.
In XR, all of that changes:
The physical body is now part of the interface. That changes everything. 👇
🎯 The Comfort Zone — Most Important Concept in Spatial UI
Before any visual design decision — understand the comfort zone first.
The Three Zones
Distance from user │ Zone │ What it's for
────────────────────┼───────────────┼──────────────────────────────
< 0.5m (50cm) │ Intimate │ Avoid for UI - causes eye strain
0.5m – 1m │ Near │ OK for brief interactions only
1m – 3m │ Conversational│ ✅ Sweet spot for most UI panels
3m – 10m │ Social │ Environmental cues, large labels
> 10m │ Public │ Wayfinding, world markers onlyThe sweet spot: 1.5m — 2.5m from the user.
At this distance:
- Eyes converge comfortably ✅
- UI panels feel natural in scale ✅
- Users can read without leaning or squinting ✅
- Depth cues read correctly ✅
Height Positioning
Don’t put UI above or below eye level without good reason.
Bad positions:
❌ Above eye level → users strain neck upward
❌ Below waist level → users look down, disorienting in VR
❌ Behind the user → discovery problem
Good positions:
✅ Slightly below eye level (5–10°) → most natural reading angle
✅ Center field of view for primary content
✅ Peripheral zone for secondary / ambient infoField of View Consideration
Human comfortable FOV for reading: ~60° cone straight ahead.
Beyond that cone — things exist, but reading and fine interaction become uncomfortable. Put your critical UI within 30° of center. Navigation and ambient info can live up to 60°.
📐 Depth & The Z-Axis — Your New Design Dimension
In flat design you have X and Y. In spatial design you have Z too — and it’s not decoration. It carries meaning.
Using Depth Intentionally
Far (background) → Environmental / world-anchored content
Decorative 3D elements
Atmospheric fog, sky
Mid (content zone) → Primary content panels
Virtual objects users interact with
Spatial menus
Near (foreground) → Heads-up information
Notification toasts
Critical alertsDepth as Visual Hierarchy
Depth replaces z-index in spatial UI.
- Closer = more important — pull critical elements slightly toward the user
- Further = ambient / background — push secondary info back
- Layer separation — use 10–30cm depth gaps between UI layers so they read as distinct
The Depth Comfort Rule
Never place two interactive elements at the same depth when they’re adjacent. The eye can’t resolve which to focus on — it causes fatigue.
❌ Bad: Two buttons side by side, both at z = 2.0m
✅ Good: Primary button at z = 2.0m, secondary at z = 2.05m
Small offset creates clear visual separationDrop Shadows Are Depth Cues
In flat UI, shadows are decorative. In spatial UI, shadows tell the user how far something is from the surface below it.
- Shadow directly below = object is on the surface
- Shadow offset and soft = object is floating above
- No shadow = object is part of the surface
Use them accurately. Users read depth from shadows instinctively. Lying to them breaks trust in the space. 🧠
👁️ Gaze, Cursor & Dwell Interaction
Gaze is to XR what hover is to desktop — but much less precise, and it carries a weight that mouse hover doesn’t.
The Problem With Direct Gaze Targeting
Eyes move constantly. Saccades, micro-tremors, natural scanning — your gaze point is never truly still. Designing UI that responds directly to gaze position = jittery, exhausting interfaces.
Solutions:
- Gaze smoothing — apply a rolling average over 3–5 frames before registering gaze position
- Dead zones — only register gaze if it stays within a target for 100ms+
- Large hit targets — minimum 5° × 5° for gaze-selectable elements (larger than you think)
Dwell Interaction
Dwell = user looks at target for a defined duration → action triggers.
Good dwell durations:
Destructive actions (delete, close): 1.5 – 2.0 seconds
Navigation / selection: 0.8 – 1.2 seconds
Quick actions (next, confirm): 0.5 – 0.8 seconds
Always show a visual progress indicator:
✅ Fill arc around target
✅ Expanding ring
✅ Color shift over time
❌ Nothing - users don't know if it's workingGaze + Confirm Pattern
For most interactions, gaze alone isn’t enough. Pair it with a confirm action:
Pattern 1: Gaze + Controller Button
Look at target → button press confirms
Pattern 2: Gaze + Hand Pinch
Look at target → pinch gesture confirms
Pattern 3: Gaze + Dwell (no controller)
Best for accessibility / no-controller scenarios
Needs generous dwell times and clear feedbackThe Midas Touch Problem
Don’t trigger actions on gaze alone without confirmation.
Named after King Midas — everything he touched turned to gold, which sounds great until you touch your food. If looking at something triggers it, users will accidentally activate things just by scanning the UI.
Get ATNO For AR / VR / MR / XR Developer’s stories in your inbox
Join Medium for free to get updates from this writer.
Always require explicit intent: dwell, pinch, voice, or button. 👑
📝 Text Legibility in 3D Space
Text in XR is hard. Genuinely hard. And most developers underestimate it until they’re squinting at blurry 12pt labels through a headset.
Font Size Rules (Angular Size)
Forget pixel sizes. In XR, angular size (how big something appears to the eye at a given distance) is what matters.
Minimum comfortable angular size for body text:
~0.5° – 1.0° of visual angle
Practical translation at 2m distance:
Minimum body text height: ~3.5cm in world units
Recommended body text height: 4–5cm
Heading text: 6–8cm
Large labels / wayfinding: 10cm+
In Unity world units (1 unit = 1 meter):
Body text: 0.035 – 0.05 world units tall
Headings: 0.06 – 0.08 world units tallFont Choice
- ✅ Sans-serif fonts — much more legible in headsets (Inter, Roboto, SF Pro)
- ✅ Medium weight (400–600) — thin fonts disappear at distance
- ✅ High contrast — white text on dark surfaces, or vice versa
- ❌ Thin decorative serifs — look blurry on current headset displays
- ❌ All-caps for body text — harder to read in XR than flat screens
- ❌ Colored text on colored backgrounds — contrast gets crushed by headset optics
Text Rendering Quality in Unity
The most common beginner mistake: using Unity’s default TextMeshPro settings without tuning them.
// TextMeshPro settings for crisp XR text:
// In the TMP font asset:
Atlas Resolution: 4096 × 4096 (not the default 512!)
Padding: 8
Sampling Point Size: 90
// On the TextMeshPro component:
Font Size: calculate based on distance (see formula below)
Overflow: Truncate (never let text overflow its container)
Wrapping: enabled
Raycast Target: OFF if not interactive (saves performance)
// Quick formula for font size at known distance:
// WorldHeight = 2 × distance × tan(angularSize_radians / 2)
// For 0.7° text at 2m:
// WorldHeight = 2 × 2 × tan(0.00611) = 0.0488m ≈ 0.05 world unitsLine Length & Spacing
- Max line length: 50–60 characters per line (same rule as web, for same reason — eyes get lost tracking back)
- Line height: 1.4× — 1.6× font size (more generous than flat UI)
- Paragraph spacing: give spatial text more breathing room than flat UI — the 3D environment is already complex
Text Don’ts in XR
- ❌ Text that curves aggressively (mild curves OK, sharp curves = motion sickness risk)
- ❌ Text that moves with head movement (fixed HUD text causes fatigue)
- ❌ Text billboarding without smoothing (snapping to face camera = jarring)
- ❌ More than 3–4 lines of body text in a single panel
🏛️ Spatial Layout Patterns That Actually Work
Forget nav bars. Forget hamburger menus. Forget sidebars. Here are the spatial equivalents.
Pattern 1: The Floating Panel
The XR equivalent of a modal or card.
Characteristics:
• Positioned at 1.5–2m in front of user
• Slightly curved to wrap user's FOV (~cylinder radius: 3m)
• Soft drop shadow or subtle depth glow
• Dismissible - always give user an exit
• Never fills more than 40% of FOV
Good for:
Settings menus, informational displays,
object property panels, confirmation dialogsPattern 2: The Radial / Pie Menu
Replaces linear dropdown menus. Works great with gaze + controller.
Why it works:
• Each item equidistant from center gaze point
• User can select with small eye movement
• Avoids long vertical scroll lists
• Works with 4–8 items comfortably (more = clutter)
Implementation tip:
Space items at minimum 15° apart
Highlight on gaze, confirm on triggerPattern 3: World-Anchored UI
UI attached to objects in the world, not to the user’s head.
Best practices:
• Label appears when user looks at object (gaze-triggered)
• Label faces toward user (billboard behavior, smoothed)
• Appears 10–20cm above the object it describes
• Fades in - never pops instantly
Use cases:
Object labels in AR, object inspector panels,
interactive hotspot tooltips, spatial annotationsPattern 4: The Wrist Menu
A menu attached to the user’s wrist (or controller). Discovered by rotating the hand inward.
Why developers love it:
• Always accessible without looking far from hands
• Natural "glance down at watch" discovery gesture
• Doesn't occlude the world when not needed
Key rules:
• Maximum 6 quick-action items
• Large hit targets (finger imprecision is real)
• Confirm on press, not on hover
• Include haptic feedback on item hoverPattern 5: The Diegetic UI
UI that exists as part of the world — a virtual screen, a holographic display on a table, a dashboard on a virtual vehicle.
Why it's powerful:
• Increases immersion massively
• Reduces cognitive load (UI feels like part of the world)
• Easier to spatially anchor (user knows where to look)
When to avoid:
• When the UI needs to be always-accessible (user can move away from it)
• When information is critical (diegetic UI can be missed)🖐️ Input Modality Design
Your UI must be designed for a specific input method. Designing for “all inputs at once” = designing for none of them well.
Controller-Based Input
Design rules:
✅ Minimum button / hit target: 5cm × 5cm in world space
✅ Pointer ray origin from controller, not from user head
✅ Visual ray line to confirm where user is pointing
✅ Haptic feedback on hover AND on press (they're different sensations)
✅ Trigger = primary action, grip = grab/hold, thumbstick = navigation
❌ Never require two-handed input for primary actions
❌ Never put critical UI behind the user's bodyHand Tracking Input
Hand tracking is less precise than controllers. Design accordingly:
✅ Even larger targets - 7–8cm minimum
✅ Pinch gesture for selection (most reliable hand gesture)
✅ Visual feedback when pinch is detected (glow, sound, haptic if available)
✅ Near-field interaction: user can "poke" buttons physically
✅ Far-field interaction: ray from index finger for distance selection
❌ Avoid wrist twists, complex multi-finger combos as primary interactions
❌ Never require high precision (dragging small sliders = frustrating)
Best interactions for hand tracking:
Button press, pinch-to-select, grab-and-move,
two-hand resize, point-and-confirmGaze-Only Input (Accessibility / No Controllers)
✅ Dwell as primary selection mechanism
✅ Very large targets (10cm+)
✅ Long dwell times for destructive actions
✅ Clear, animated progress indicators
✅ "Back" always accessible without precise gaze
❌ Never require selection of small adjacent targets
❌ Avoid menus with more than 5 items🎨 Color, Contrast & Visual Style in XR
Contrast Ratios
WCAG 2.1 AA requires 4.5:1 for body text on flat screens. In XR, aim for 7:1 minimum — headset optics and lens diffraction reduce apparent contrast.
Translucency & Glass Effects
Frosted glass / translucent panels look stunning in XR demos
When translucency works:
✅ Panel content is short and high-contrast
✅ Background behind panel is relatively calm
✅ Panel has clear depth separation from background
When translucency fails:
❌ Complex, busy backgrounds bleed through → unreadable text
❌ Animated backgrounds → motion behind text → eye strain
❌ On Quest 2 (limited passthrough quality) → looks muddy
Safe default: semi-opaque dark background (80–90% opacity)
then add translucency as enhancement on capable hardware.Colors That Work in XR
✅ Work well:
High-saturation accent colors on neutral backgrounds
White/near-white on dark (navy, charcoal, black)
Warm neutral backgrounds (easier on eyes than pure white)
❌ Problematic:
Pure white large surfaces → glare in headsets
Red on black → chromatic aberration at display edges
Very low contrast (light gray on white) → disappears
Rainbow gradients → color fringing through lenses📱 Platform-Specific Quick Reference
Meta Quest (VR/MR)
- Comfort zone: 1–3m
- Recommended text size: 0.04–0.06 world units at 2m
- Primary input: Touch controllers or Hand Tracking
- Panel curve radius: ~3m
- 🔗 Meta Quest Design Guidelines
Apple Vision Pro (visionOS)
- Emphasizes window-based UI (familiar app windows in space)
- Primary input: Eye tracking + hand pinch (no controller)
- Minimum tap target: 60pt
- Glass morphism encouraged (but follow Apple’s material system)
- 🔗 visionOS Human Interface Guidelines
Mobile AR (ARKit / ARCore)
- UI exists on a 2D screen overlay OR in 3D world space
- Comfort zone matters less (user holds device)
- Primary challenge: not occluding the AR content with UI chrome
- Keep UI to edges — center is for the AR experience
- 🔗 Google AR Design Guidelines
HoloLens 2 / Enterprise MR
- Narrower FOV than Quest — design conservatively within 52° horizontal
- Users often in workplace — UI must work with gloves in some cases
- Prefer dwell + air-tap over complex gestures
- 🔗 MRTK Design Documentation
🧰 Tools for Spatial UI Design
📚 Further Reading
🏁 The Big Takeaway
- Spatial UI isn’t harder than flat UI. It’s just different.
The principles that make 2D UI good clarity, hierarchy, feedback, consistency, still apply completely. But the execution changes because:
- The body is part of the interface now
- Distance and depth carry meaning they never had on a flat screen
- Comfort is a first-class design constraint, not an afterthought
- Precision is lower across almost every input modality
