From Problem to Proof: The IkigaiXR Development Process

  1. Introduction

Most VR development projects that go wrong don’t go wrong because of the technology. They go wrong because of process failures that have nothing to do with rendering quality or interaction design: a project that should never have used VR in the first place, requirements that were assumed rather than confirmed, scope that expanded quietly until nobody could say what “finished” actually meant, or testing treated as a final gate instead of a discipline running throughout the build.

Each of these failures is preventable, and each has a specific point in a project’s life where it should be caught. A problem-definition stage that never happens means VR gets used where it wasn’t the right tool. A requirements stage without formal sign-off means the client and the developer are quietly building two different things. A scope stage without measurable outcomes means nobody can later say whether the finished product actually achieved what it set out to.

Over eight years of building VR solutions, we’ve structured our process around exactly these failure points – not as generic project-management best practice, but as direct answers to the specific ways simulation projects go wrong when they’re not caught early. Six stages, each with a clear deliverable, and – critically – client sign-off built into the stages where ambiguity is most dangerous, before time and budget are committed on the strength of an assumption.

This isn’t process for its own sake. It’s how “transparent, controlled, and measured” stops being a claim on a website and becomes something you can actually verify, stage by stage, as a project runs.

  1. Stage 1 – Problem Definition

Every project starts with a question that’s easy to skip and expensive to skip: what problem are we actually trying to solve, and is VR genuinely the right way to solve it?

This matters because VR is not a universal answer. It’s an exceptional tool for specific categories of problem – building physical or procedural instinct, letting someone safely experience a hazard or consequence they couldn’t otherwise encounter, rehearsing a task that’s expensive, dangerous, or logistically difficult to practise repeatedly in reality. It is a poor and often wasteful tool for problems that a well-designed slide deck, a video, or a conventional e-learning module would solve just as effectively, at a fraction of the cost and development time.

A provider with a VR development business to run has an obvious commercial incentive to say yes to every enquiry. We treat this stage as the point where that incentive gets set aside in favour of an honest answer – because a client sold VR for a problem that didn’t need it ends up with an expensive solution that underperforms a cheaper one, and a provider who’s damaged their own credibility to make a sale.

In practice, this stage asks:

The output of this stage isn’t a technical specification. It’s a shared, explicit understanding of the problem and a considered answer – sometimes “yes, VR is right for this,” and sometimes “no, or not entirely” – before either party commits further resource on an assumption neither has actually tested.

  1. Stage 2 – Client Requirements

Once the problem is defined and VR confirmed as the right tool, the next failure point is requirements that exist only informally – assumed, implied in conversation, or scattered across emails rather than captured and agreed in one place. This is where two parties can walk away from the same meeting with genuinely different understandings of what’s being built, and not discover the gap until it’s expensive to close.

This stage exists to close that gap before it opens. It covers four categories of requirement, each gathered explicitly rather than inferred:

Technical requirements – the hardware the simulation must run on (headset make and model, minimum specification, tethered or standalone), any integration with existing systems, and any technical constraints imposed by the client’s environment (network restrictions, device management policies, security requirements for high-hazard or sensitive sites).

Operational requirements – how the simulation will actually be used day to day: who administers it, how learners are scheduled or assigned, whether it needs to run unsupervised or with a facilitator present, and any operational constraints of the environment it will be delivered in (a site induction room, a mobile unit, a classroom shared with other training).

Deployment requirements – how the finished simulation reaches learners: via a managed platform (such as our own XR2train delivery infrastructure), a standalone build distributed directly to devices, or integration into an existing LMS. This includes update and maintenance expectations once live.

Analytics and reporting requirements – what data the client needs captured and reported: completion rates, assessment scores, time-on-task, specific in-simulation behaviours worth tracking, and how that data needs to reach the client’s own systems (a compliance record, an LMS gradebook, a CRM).

Each of these is documented explicitly, reviewed with the client, and formally signed off before the project proceeds to scoping. This isn’t bureaucracy for its own sake – it’s the point at which any misunderstanding about what’s being built is cheapest to correct, because nothing has yet been designed, prototyped, or built against an incorrect assumption.

  1. Stage 3 – Scope Definition

Requirements establish what is needed. Scope definition establishes exactly what will be built to meet it – in enough detail that both parties can point to the same document months later and agree on whether the finished product matches what was agreed. This is the stage where ambiguity is most expensive if left unresolved, because it’s the last point before development work actually begins.

Scope definition covers:

User flows – the complete path a learner takes through the experience, start to finish, including every decision point, branch, and outcome. Not a summary – a full map of the experience as the learner will actually move through it.

Sequencing – the order in which content, interactions, and assessments occur, and the reasoning behind that order. As set out elsewhere in our approach, sequencing is a deliberate design decision, not a default – the order in which a learner encounters consequence, correction, and practice materially affects what they actually retain.

Interactions – every distinct action a learner will perform, described specifically enough to design and build against: what they pick up, operate, assemble, or respond to, and what the correct and incorrect versions of that interaction look like.

Learning criteria and objectives – the specific, named things a learner will be able to do, identify, or explain on completion. These are written to be assessable, not aspirational – each objective needs a clear answer to “how would we know if a learner has achieved this?”

Measurable outcomes – how success will actually be measured once the simulation is live: completion and pass rates, specific behavioural indicators, or downstream measures such as incident or near-miss trends where the client can track them. Defined now, before development, so success isn’t defined retrospectively to fit whatever gets built.

Testing approach – how the simulation will be tested throughout development and before launch, including who tests it, what “passing” a test means at each stage, and how issues found in testing feed back into revisions.

As with Stage 2, this scope document is formally signed off by the client before development work starts. Once agreed, it becomes the shared reference point for every decision that follows – including, if scope needs to change during development, an explicit conversation about what’s changing and why, rather than drift nobody can quite pin down after the fact.

  1. Stage 4 – Development

With scope agreed, development begins – but not as a single, opaque build phase that disappears until a finished product emerges at the end. Development is broken into staged milestones, each producing something tangible the client can see, react to, and formally sign off before work continues to the next stage.

This structure exists because a project with no visibility between kickoff and delivery carries all its risk at the very end – if something has drifted from what was scoped, or a requirement was interpreted differently than intended, it’s discovered only once most of the budget and timeline have already been spent. Staged development moves that discovery earlier, repeatedly, while course-correction is still cheap.

In practice, this typically follows a sequence such as:

Prototyping – early, rough builds of key interactions or environments, used to validate feel, mechanics, and technical feasibility before committing to full production values. This is often where interaction-level decisions – how a tool should respond, how an environment should be navigated – are tested and refined, well before final art and polish are applied.

Staged builds – the simulation constructed in agreed sections or milestones (for example, by module, by scene, or by user-flow stage), with each staged build reviewed against the signed-off scope document before proceeding.

Client sign-off at each stage – rather than a single final approval, the client reviews and formally signs off progress at each agreed milestone. This keeps the client actively involved throughout, not just at kickoff and delivery, and means any change in direction is caught and agreed at the stage it’s raised, not retrofitted later.

This staged approach does add visible checkpoints to a project timeline that a less transparent process might not include. That’s deliberate. The alternative – a long, opaque build period with no interim visibility – is faster to describe but riskier to deliver, and risk in this category of work ultimately lands on the client’s training outcomes, not just the project timeline.

  1. Stage 5 – Testing & Re-work

Testing is not a phase that happens after development finishes. It runs continuously, in parallel with development, from the earliest prototypes onward – and it happens again, deliberately, once the simulation reaches real, unfamiliar users.

Continuous internal testing throughout development

Every interaction, environment, and behaviour is tested as it’s built, not batched up and checked at the end. This includes functional testing (does it work as intended), but just as importantly, it includes the kind of fidelity testing described in our wider approach to simulation design: does an interaction feel correct to someone who has real-world experience of the task it represents. A grinder that operates correctly in code but feels wrong in the hand is a failed test, even if nothing has technically broken.

This testing is iterative by nature. Issues found lead to rework, rework is re-tested, and the cycle continues – an agile-style loop running throughout the development stage described previously, rather than a single pass at the end.

Critically, this testing discipline doesn’t stop once a module is considered finished. Whenever testing parameters change – a new headset, an updated build environment, a change elsewhere in a linked module – previously completed work is re-tested against those new parameters. A simulation that passed testing under one set of conditions is not assumed to still pass under different ones without being checked again.

Testing with live, unfamiliar users

Internal testing, however rigorous, is conducted by people who already know what the simulation is supposed to do and how it’s supposed to feel. That familiarity is valuable for catching functional issues, but it can mask problems only a genuinely unfamiliar user would encounter – confusion at a decision point that seemed obvious to the team, an interaction that feels natural to someone who’s tested it fifty times but not to someone experiencing it for the first time.

Before final sign-off, the simulation is tested with live users who match the actual intended audience – not the development team, not the client’s project sponsor, but representative learners encountering it fresh. Their confusion, hesitation, or unexpected behaviour is treated as genuine test data, not user error, and feeds back into final revisions before launch.

This two-layer approach – continuous internal testing throughout the build, followed by dedicated live-user testing before release – is what allows us to treat “tested” as a meaningful claim rather than a formality completed once and never revisited.

  1. Stage 6 – Live Deployment & Monitoring

Launch is not the end of the process – it’s the point where the simulation starts generating real data, and that data needs to be watched, not just collected.

Deployment

The simulation goes live through whichever deployment route was agreed and documented in Stage 2 – delivered through our own XR2train platform, distributed as a standalone build to managed devices, or integrated into the client’s existing learning infrastructure. Deployment follows the specification agreed at that stage; nothing about how learners access or run the simulation should come as a surprise at this point, because it was defined and signed off well before development began.

Monitoring

Once live, the analytics and reporting requirements agreed in Stage 2 come into active use: completion rates, assessment scores, time-on-task, and any specific in-simulation behaviours identified as worth tracking. This data serves two distinct purposes.

First, it answers the operational question the client needs answered day to day – who has completed training, who hasn’t, and whether performance is meeting expectations.

Second, and just as importantly, it answers the question posed all the way back in Stage 1 and defined concretely in Stage 3: is this achieving the outcome it was built for? The measurable outcomes agreed during scoping aren’t abstract targets – they’re the criteria this live data is checked against, on an ongoing basis, not as a one-off evaluation shortly after launch.

Ongoing relationship, not a handover and exit

Where monitoring reveals a gap – a stage learners consistently struggle with, an assessment question that isn’t discriminating as intended, a completion pattern that suggests friction somewhere in the flow – that’s fed back as a genuine finding, not treated as the client’s problem to solve alone. Live deployment closes the loop between what was designed and what actually happens with real learners, and that loop stays open for the life of the simulation, not just its first few weeks in the field.

  1. Conclusion

Six stages, each with a specific job: confirm the problem is real and VR is the right answer to it; capture requirements explicitly rather than assume them; scope the build in enough detail that “finished” has a clear, agreed meaning; develop in stages the client can see and approve, not a single opaque build period; test continuously rather than at the end, and again with genuinely unfamiliar users before launch; and deploy with monitoring that keeps answering the question the whole project started with – is this actually working.

None of these stages exist to slow a project down for its own sake. They exist at the specific points where simulation projects, across our own eight years of building them and more broadly across the industry, tend to go wrong – and each is designed to catch that specific failure before it becomes expensive, embarrassing, or safety-critical to fix.

This is what “transparent, controlled, and measured” means in practice: not a claim on a page, but a process a client can see, participate in, and sign off at every stage where ambiguity would otherwise be allowed to compound.

If you’d like to see this process applied to your own project, we’d welcome the conversation.

Further reading: