A promising VR or XR idea should not move straight from a presentation into full production. Before committing the larger budget, the team needs evidence that the experience solves a useful problem, makes sense to its intended users and can perform responsibly on the chosen hardware. This guide explains how to run that feasibility stage, what the first prototype should prove and how to make a defensible go, revise or stop decision.
What does feasibility mean for a VR or XR project?
Feasibility is not a promise that every feature can be delivered exactly as first imagined. It is a structured attempt to expose the assumptions that could make the idea ineffective, uncomfortable, inaccessible, technically unsuitable or unnecessarily expensive. The result should be evidence that improves the decision—not simply an impressive demonstration.
A useful assessment connects three questions: what must the user be able to do, why is an immersive format better than a conventional screen or real-world process, and what must be proven before more money is committed? This is why responsible VR and XR development planning begins with the behaviour, decision, skill or feeling the experience needs to create.
Which outcome and users should the experience serve?
- User: Who will use it, and what ability or prior knowledge can be assumed?
- Setting: Where will it run, and what space, supervision or connectivity is available?
- Behaviour: What must the user practise, understand, decide or accomplish?
- Evidence: What observable result would show that immersion adds useful value?
“Build a VR training app” is a format request, not yet a defined outcome. “Help new technicians rehearse one hazardous isolation decision without using live equipment” is testable. A game concept also needs this clarity: define the core action and intended feeling before expanding levels, progression and cosmetic content. When the user, context and desired behaviour are specific, the team can compare XR with simpler options and avoid selecting a headset merely because it is novel.
Which assumption should the first prototype test?
1. Can users understand and perform the defining interaction?
Build the smallest usable slice of the experience around its most important action. That might be manipulating a tool with tracked hands, positioning a virtual product in a real room or making a time-sensitive decision inside a simulation. Observe whether representative users understand what to do without being coached. Placeholder art is acceptable when visual fidelity is not the risk; the interaction itself must be real enough to test.
2. Can the experience remain comfortable in its intended session?
Comfort is part of feasibility, especially when the design introduces artificial movement, turning, prolonged standing or repeated reaching. Meta's current locomotion comfort guidance discusses sensory mismatch and options including vignettes and seated modes. These are possible mitigations, not substitutes for testing the actual experience with suitable users.
3. Can the target device sustain the required experience?
A prototype tested only on a powerful development computer does not prove that it will work on a standalone headset. Put the defining scene, interaction and content density onto the intended device early. Measure loading, thermal behaviour, tracking, input reliability and frame performance under realistic conditions. Unity's Profiler documentation confirms that performance information can be collected from a connected target device, which is stronger evidence than judging the project only inside the editor.
How should you choose the target device and delivery platform?
- Access: Will users own the device, borrow it on site or use a managed headset fleet?
- Environment: Is the experience seated, room-scale, public, supervised or remote?
- Demand: Does it need portability, visual fidelity, mixed-reality sensing or specialist inputs?
- Delivery: Will it use an app store, private deployment, device management or a browser?
The best platform is the one that the intended users can realistically access and that can support the defining interaction. Standalone headsets favour portability; PC-connected systems can support more demanding simulation; browser-based WebXR can reduce installation friction for lighter experiences. The architecture should also consider future device needs. OpenXR provides a common API across a range of XR systems and can reduce platform-specific adaptation, but teams should still expect device-specific features, optimisation and testing. Record the reasons for the platform choice so a later hardware change can be evaluated against the original constraints.
What should count as success in a feasibility test?
- Users can begin and complete the defining interaction with an agreed level of assistance.
- The prototype runs acceptably on the intended device in the real operating environment.
- Comfort, safety and accessibility issues are identified, recorded and given an owner.
- Stakeholders agree what the evidence supports, what remains uncertain and what happens next.
Set the criteria before the test so enthusiasm for a polished demonstration does not replace evidence. “People liked it” is weak because it does not reveal whether they understood the task or whether the system can survive real deployment. Better criteria describe observable behaviour, technical thresholds and unresolved risks. A training prototype might measure completion and error patterns; a game prototype might test whether the core loop is understood and voluntarily repeated. The feasibility stage does not need to prove the final commercial result, but it should show whether the central product assumption deserves further investment.
Who should test the prototype, and what should you observe?
- Representative ability: Include people with the knowledge and confidence levels expected in real use.
- Physical context: Test the available space, posture, lighting, noise and supervision conditions.
- Unprompted behaviour: Watch where users hesitate, misread cues or invent unintended workarounds.
- Comfort response: Record fatigue, disorientation, reach problems and reasons for stopping.
- Access needs: Check whether motion, controls, audio, visual cues or physical position exclude users.
Use a small but relevant test group before seeking a larger sample. The purpose is to discover failure patterns and unclear assumptions, not to manufacture a statistically impressive result from an unfinished product. Avoid explaining every interaction during the session, because constant coaching can hide poor onboarding. The W3C's XR Accessibility User Requirements is a useful planning reference for varied input, output, movement and customisation needs, although it is a Working Group Note rather than a formal compliance baseline. Where an experience affects safety, regulated training or sensitive personal data, involve the appropriate specialist before treating a prototype as deployment-ready.
Which warning signs mean full production is still too early?
- The team cannot state why immersion improves the outcome over a simpler format.
- The core interaction works only when a developer explains or resets it repeatedly.
- Performance is acceptable on a development PC but has not been measured on the target device.
- Comfort, accessibility, physical-space or safeguarding risks have no planned response.
- The prototype keeps gaining features while the original high-risk assumption remains untested.
These signals do not automatically kill the idea. They mean the next step should be a narrower experiment, a revised interaction, a different platform or a more suitable non-XR approach. Stopping can also be a successful feasibility outcome when it prevents a costly build that would not serve users responsibly. Document what failed, what was learned and what evidence would justify reconsideration.
What should a useful XR feasibility decision record contain?
- Problem and audience: The user, setting and outcome the immersive experience is intended to serve.
- Critical assumption: The interaction, comfort, platform or performance question the prototype tested.
- Test conditions: The hardware, physical environment, participant profile and version used during evaluation.
- Observed evidence: What users did, where they struggled and what the target device measurements showed.
- Decision and ownership: Whether to proceed, revise or stop, with named actions for unresolved risks.
Keep observations separate from interpretation. “Three participants reached for the wrong control” is an observation; “the interaction cue is unclear” is a plausible interpretation that the next test can examine. Record prototype limitations too, including placeholder content, features that were simulated and conditions that were not tested. This prevents a successful narrow experiment from being mistaken for proof that the complete product is ready. A concise decision record also gives developers, stakeholders and future reviewers the same starting point when scope or hardware changes.
How does the evidence lead to a go, revise or stop decision?
A go decision should define a production scope, target hardware, acceptance criteria, content requirements, technical dependencies and the risks that remain open. It should also distinguish evidence gathered from decisions that still depend on budget, procurement, legal review or operational approval. A revise decision should name the failed assumption and the smallest next test. A stop decision should preserve the learning so the organisation does not repeat the same experiment later.
The output of feasibility is therefore not just a prototype. It is a decision record: intended users and outcome, chosen platform, tested interaction, observed behaviour, device evidence, unresolved risks and the reason for the next move. Full production should begin with a shared understanding of what has been proved, what remains uncertain and how later milestones will test those remaining assumptions. If you need help turning an immersive idea into that evidence, request your free XR feasibility plan and identify the first interaction or technical assumption worth proving before full development.
