Goal
Universities keep piloting eXtended Reality (XR) and keep failing to scale it. This study asked why — not by evaluating the technology, but by treating adoption as a socio-technical systems problem. Working within an R1 university's XR Community of Practice, I set out to identify every stakeholder the XR lifecycle actually depends on, map their roles and interdependencies, and characterize the barriers and enablers that determine whether XR gets adopted or abandoned. This became my M.S. thesis and produced two institutional deliverables: a Stakeholder Needs Document and an External XR Development Guide.
Background
Most XR-in-education research focuses on students and faculty, and on whether immersive learning "works." That framing misses where implementations actually break. Universities are bureaucratic organizations with decision-making distributed across dozens of units — instructional design, IT, accessibility services, information security, procurement, administration — and an XR deployment touches all of them. Existing literature had little to say about those non-faculty stakeholders, or about how cost, governance, accessibility, and pedagogical alignment compound each other when institutional coordination is missing. That gap is what the study was designed to fill.
Methods
Participants
Campus-wide survey: 371 responses, 232 complete (undergraduates, graduate students, faculty, and staff across every college).
Focus groups: 14 faculty and staff across 10 departments, selected for direct experience designing or integrating XR into curricula.
Domain expert interviews: 3 semi-structured interviews with specialists in information technology, accessibility, and information security — roles largely absent from prior XR research.
Study Design
A single-case, mixed-methods design run sequentially: the survey established institutional baseline and surfaced patterns, focus groups explored those patterns in depth, and interviews probed the system-level and governance layers the earlier methods couldn't reach. I applied a systems engineering lens to stakeholder identification, classifying stakeholders as active (continuous, hands-on operation of the system) or passive (episodic, governance-level influence) — a distinction based on mode of engagement rather than job title.
Qualitative data were analyzed with inductive thematic analysis across 199 coded instances, with codes iteratively refined and continuously compared across all three data sources to identify convergence and divergence. Triangulation across methods and participant groups was the primary credibility strategy. Findings were then synthesized into a structured stakeholder needs framework mapping specific needs to specific stakeholder groups.
Insights
The constraint is coordination, not capability. Interest in XR was high (mean 4.15 for enhancing teaching, 4.10 for student engagement), yet over half of respondents had never used immersive technology in an educational setting and only about a fifth had participated in development. That gap isn't explained by unwillingness. Barriers clustered evenly across resource, technical, organizational, pedagogical, and governance dimensions — funding and sustainability, hardware and infrastructure, and accessibility tied as the most frequently raised, followed by institutional siloing and faculty training deficits. These barriers reinforce each other, so resolving any one in isolation does little.
Bad first experiences may be driving the adoption gap. Among educators who had facilitated XR, negative experiences nearly doubled positive ones — technical instability, usability problems, hardware limitations. This reframes the interest-to-adoption gap: it isn't only awareness or resources, it's accumulated friction among the very early adopters an institution needs as champions.
Stakeholder visibility is asymmetric. Educators in focus groups named stakeholders concentrated in the instructional layer. Domain experts in interviews named a substantially broader system-and-governance set. That divergence was itself a finding: educators have limited visibility into the infrastructure their work depends on, which creates invisible dependencies and unrecognized bottlenecks. A concrete instance surfaced at the operational level — AV services and IT support still sit in separate silos even as XR makes them structurally interdependent, leaving deployments to fall into a support gap where neither group holds the full skill set.
Accessibility and governance can't be retrofitted. Interview participants drew a sharp line between accommodation (reactive workarounds that often produce a separate, isolating experience) and accessibility (designing multiple modes of engagement from ideation so no one has to disclose to participate). Separately, XR's collection of behavioral and biometric data sits in genuine legal ambiguity — existing student-privacy frameworks weren't written for sensor-rich immersive environments, and vendor terms may assert ownership over data generated by students in a university context. Both are foundational design requirements, not post-deployment cleanup.
Unsustainable funding has a visible cost. The clearest illustration came from a participant who described a room holding more than 50 VR headsets, unused for years after the grant that bought them ended — no maintenance plan, no institutional memory, no strategy for reuse. Lifecycle planning is a prerequisite for XR investment, not an afterthought.
My Learnings
The biggest shift for me was learning to research the system rather than the interface. Interviewing an information security officer and an accessibility specialist changed my understanding of this problem more than any usability session could have — they surfaced constraints that were invisible to the educators actually using the technology, and that no amount of user testing would have revealed. I also learned that a finding's format determines whether it gets used: translating six months of qualitative data into a stakeholder needs document and a practical development guide made the work something the institution could act on, rather than a report that gets read once and shelved.