Safety training is a near-ideal XR use case: the whole point is rehearsing a high-stakes procedure you can't safely rehearse for real. But the university had no in-house XR development capacity available on the needed timeline, and prior institutional survey data showed most internal XR builds took six to twelve months or longer, with student workers as the most common development resource — a workforce that graduates and takes its expertise with it. Going external promised speed and professional quality at the cost of vendor dependency and reduced control. Documenting that tradeoff honestly, rather than just shipping the module, was part of the research goal.

Participants

Usability feedback: 14 faculty and staff across two structured sessions reviewed the working build and surfaced design issues that fed directly into the iteration cycles.

Efficacy study: 22 participants spanning students, faculty, and staff from a wide range of disciplines.

Study Design

Development. I served as the translator between instruction and implementation — converting safety syllabus objectives into concrete interaction specifications, researching the domain content the developer needed to build accurate mechanics, and mediating between stakeholders' ideal features and what was actually buildable. The module was scoped to two activities: hazard identification in a virtual environment, and a scenario-based assessment where the user decides whether to extinguish an active fire or evacuate. A functional prototype landed within roughly a week of kickoff; multiple structured iteration cycles followed. Because the iteration budget was finite, I ranked every feedback item by priority so the developer could triage — critical bugs first, then UX, then cosmetic.

Efficacy testing. A within-subject counterbalanced mixed-methods design. Participants were randomly assigned to complete either the traditional web training or the VR module first, then crossed over to the other. Measures included quiz performance after each condition, time-to-completion, the New General Self-Efficacy scale administered at three points (baseline, post-first condition, post-second condition), the Technology Acceptance Model questionnaire for faculty and staff, and open-ended engagement questions analyzed thematically.

Confidence moved, and it moved specifically after VR. Self-efficacy scores were essentially flat after traditional training but rose meaningfully after the VR condition. Over 90% of participants reported the XR training positively influenced their self-efficacy; the remainder reported no change, and not a single participant reported a negative effect. For a procedure where the failure mode is freezing under pressure, confidence is arguably the outcome that matters most.

Time-on-task exposed a problem with the existing training. The traditional module is advertised as roughly an hour. Participants finished it in about 12 minutes on average — because the format lets you skip. They spent about 27 minutes in the VR module, which is structured and sequential and gives you nowhere to skip to. That's a finding about the incumbent training as much as the new one: when completion is tied to mandatory certification and there are no consequences for skimming, the delivery format quietly undermines the learning objective.

Positive perception did not equal intent to adopt. Faculty and staff rated the module's usefulness highly and averaged 4.18 on supporting it as an official training tool — yet behavioral intention to actually use XR in their own teaching sat at only 2.9 out of 5. That gap is the real adoption story: people are convinced by the tool and still blocked by time, training, and institutional support. Enthusiasm was never the bottleneck.

Engagement and discomfort came from the same source. Thematic analysis of open responses put interactivity and immersion at the top of what kept people engaged, followed by hands-on scenario-based learning, realism, and sensory feedback. The leading negative was simulation sickness, followed by cognitive overload and control friction. The immersion doing the pedagogical work is the same immersion making a subset of users physically uncomfortable — which is precisely why multi-modal alternatives aren't optional.

Usability iteration was where the module got usable. Testing surfaced issues that would have quietly degraded the experience: information panels sized and positioned so they obscured the environment, a sequencing bug that hard-blocked progress if a user pulled the extinguisher pin early, missing restart and back navigation, and an evacuation time threshold calibrated too strictly for first-time VR users. Continued review after launch caught additional bugs before formal data collection began — including one that made an activity uncompletable — which protected the study's validity.

This project taught me what it actually takes to get a research-grade product built on a real budget and timeline. Precision upstream was worth more than effort downstream — a detailed design document before the first vendor conversation shaped both the price and the quality of what came back, while every ambiguity left unresolved at scoping cost an iteration cycle later. I also had to get comfortable saying no: when a usability expert proposed a genuinely good feature late in the process, the honest answer was that it exceeded scope and the budget was better spent on the sequencing bug blocking users entirely. Prioritizing well within real constraints turned out to be more of the job than generating ideas.