What this prompt does
This prompt generates a complete spatial computing UI specification across eight distinct output zones: window design, navigation, content hierarchy, interaction zones, immersion modes, multi-window management, accessibility, and a [framework]-keyed SwiftUI code block for the primary app window. It does not just ask for "a VR interface" — it encodes the actual constraints of the medium (eye-gaze target sizing, motion sickness avoidance, glass material rendering) directly into the generation rules, so the output skips beginner mistakes and starts from platform-correct assumptions.
What makes the template structurally sound is the anti-patterns block. Spatial computing has a short list of specific failure modes — tiny tap targets, flat 2D layouts ported unchanged from mobile, rapid camera movements — and baking them in as explicit constraints means the AI spends its tokens on spatial-native solutions rather than recycling responsive web patterns into a headset context.
The [framework] variable also pulls through to a SwiftUI code output, so you get an actionable starting point for the primary window, not just a design brief you still have to translate.
When to use it
- You are prototyping a visionOS app and need a defensible UX foundation before writing any SwiftUI.
- A client wants a Meta Quest productivity app and you need to communicate spatial design rationale to a team that has only shipped mobile.
- You are designing a training or simulation tool and need to spec out partial/full immersion transitions.
- You want to audit an existing spatial app concept against industry anti-patterns before dev starts.
- You are writing a design document for a pitch and need a concrete, structured UI breakdown with interaction zones called out.
Example output
For app_purpose: surgical procedure reference, platform: Apple Vision Pro, interaction_model: eye-gaze + indirect pinch, content_type: 3D anatomical overlays + step-by-step text:
App Window:
- Floating glass panel, 60cm depth placement, 800×600pt base size
- Frosted visor material, 80% opacity, 1pt border highlight
- Resize handle: ornament-style corner grips, 44pt minimum touch target
Navigation:
- Bottom ornament tab bar: 5 tabs, SF Symbols 4+, label + icon
- Eye-gaze highlight: system-controlled hover dwell, subtle rim glow on focus
Interaction Zones:
- Primary tap targets: minimum 60×60pt (comfort zone at 60cm)
- Pinch-to-expand: 3D model scale gesture, spring animation 0.4s
- Drag threshold: 8pt deadzone before window repositioning begins
Pro tips
- Set
[platform]to a single target. Mixing visionOS and Quest in one generation produces watered-down output that fits neither platform's material system or input model. - For
[interaction_model], be specific about direct vs. indirect touch — "hand tracking (direct pinch at surface)" behaves very differently from "eye-gaze + indirect pinch" and the prompt uses this distinction to size interaction zones and choose gesture affordances correctly. - Pair the generated SwiftUI window code with Apple's RealityKit documentation for the immersive space layer — the prompt outputs the 2D ornament UI correctly but 3D anchor placement needs RealityKit primitives the template does not cover.
- If your
[content_type]is data-dense (dashboards, medical, engineering), add "progressive disclosure" to the interaction model field. The prompt will then distribute information across depth layers rather than cramming everything into one window — which is the correct spatial answer to information overload, not smaller text. - Eye-gaze dwell timing in visionOS is system-controlled and intentionally not exposed as a developer constant. If the output suggests hardcoding a specific ms value, treat it as a design intent annotation only — implement the system hover API and let the OS handle timing so it respects user accessibility preferences.
