User-Centric Design in XR Development: Lessons from Humanitarian Training

Early Immersive Prototyping with Non-Technical Stakeholders

The XRisis project demonstrated that effective XR platform development for non-technical users requires fundamentally different engagement approaches than conventional software projects, with early immersive prototyping proving essential for requirements gathering. During the initial requirements phase in August 2024, Nuwa created rudimentary virtual environments in Mozilla Hubs representing a deserted village, a broken landscape, and an emergency coordination centre, inviting Action Contre la Faim team members to explore these spaces and experience collaborative communication within immersive contexts for the first time. This hands-on exposure transformed abstract technical possibilities into tangible experiential understanding, enabling humanitarian professionals who had never worn VR headsets or navigated 3D virtual spaces to viscerally comprehend what immersive training might offer their organisation, moving conversations from speculative "could this work?" discussions to concrete "here's what we specifically need" design sessions. The design team deliberately chose low-fidelity environments rather than polished demonstrations, recognising that realistic prototypes with obvious limitations invited collaborative refinement whereas highly finished demos created false impressions that design decisions had been finalised, discouraging the open-ended exploration essential for uncovering genuine user needs rather than confirming designer assumptions. Nuwa team members participated in Action Contre la Faim's existing e-learning modules through the Cross Knowledge platform and silently observed four three-hour Emergency Preparedness Response Plan design sessions between Paris facilitators and humanitarian workers in Yemen, building deep familiarity with organisational processes, terminology, pedagogical approaches, and operational constraints before proposing technical solutions. This investment in domain immersion enabled the technical team to speak the language of humanitarian professionals, understand implicit requirements that users might not articulate because they assumed all systems would naturally incorporate certain capabilities, and recognise when proposed features addressed superficial wants rather than fundamental needs. Weekly requirements sessions alternated between traditional video conferencing and immersive virtual world meetings, with the contrast demonstrating both the potential of spatial collaboration and the learning curve required before non-technical users could achieve fluent interaction in 3D environments, informing decisions about how much complexity the final platform could reasonably expect users to accommodate. The iterative cycle of discussion, prototype development, demonstration, feedback, and refinement created shared understanding that bridge

d organisational cultures, with humanitarian professionals learning to express requirements in terms technical teams could implement whilst developers learned to assess feature value through humanitarian operational lenses rather than technical elegance criteria. This approach required substantial time investment (nearly three months for Phase 1 requirements gathering) compared to conventional specification processes, yet the resulting alignment between development priorities and genuine user needs proved worth the extended timeline, preventing wasted effort on capabilities that seemed valuable in abstract discussions but would have delivered minimal operational benefits. The early prototyping investment fundamentally shaped project success: by the time formal development commenced in Phase 2, both teams shared clear vision about what the platform needed to accomplish and why, enabling efficient implementation focused on validated priorities rather than speculative features.

Value of Dedicated Liaison Roles

The decision by Action Contre la Faim to engage Laurence Knoop, an independent training consultant specialising in simulation exercises, as a dedicated liaison between humanitarian and technical teams proved transformative for project success. Knoop brought over a decade of leadership, training, and project management experience in disaster response operations, providing credibility with humanitarian stakeholders who might have been sceptical about technology-driven innovations proposed by personnel without field experience. His expertise in simulation exercise design enabled translation of high-level learning objectives into specific scenario requirements, inject sequences, participant task definitions, and facilitation approaches that technical teams could implement as system features and content, creating the crucial bridge between pedagogical intent and technical realisation. Serving as an external consultant rather than embedded Action Contre la Faim staff member provided important "arm's length" perspective, questioning institutional assumptions about how training must be delivered whilst maintaining sufficient organisational understanding to ensure proposed innovations aligned with operational realities and cultural norms. The liaison role managed expectation calibration from both directions: helping Action Contre la Faim understand what XR technology could realistically accomplish within timeline and budget constraints whilst helping Nuwa appreciate why certain apparently simple requirements actually represented complex challenges given humanitarian operational contexts. Knoop participated in both Action Contre la Faim internal planning sessions and Nuwa technical scrums, maintaining awareness of evolving priorities and emerging constraints on both sides, enabling proactive identification of potential misalignments before they manifested as project delays or deliverable disputes. His simulation exercise expertise proved particularly valuable during validation planning, designing evaluation instruments that would assess both CORTEX2 technical integration requirements and Action Contre la Faim humanitarian training effectiveness criteria through a single workshop structure, avoiding the need for separate validation events that would have doubled participant time commitments and complicated result interpretation. The consultant reflected that bridging gaps required translation in both directions: technical teams needed help understanding that humanitarian users care more about scenario realism and learning outcome achievement than technical sophistication, whilst humanitarian teams needed reassurance that technical constraints weren't excuses for incomplete delivery but genuine limitations requiring priority trade-offs. Having someone relatively tech-savvy compared to typical humanitarian trainers who could grasp key elements of the Unity development environment, understand WebSocket synchronisation challenges, and appreciate why certain feature requests would require substantial architecture changes enabled much more productive conversations about what to build first, what to defer, and what to abandon entirely. The liaison investment demonstrated an important principle for XR development in specialised domains: the cost of miscommunication, wasted development effort on misunderstood requirements, and project failure from accumulated small misalignments vastly exceeds the cost of skilled intermediaries who can ensure genuine mutual understanding, making dedicated liaison roles not optional extras but essential project infrastructure for successful outcomes.

Iterative Feedback Loops and Progressive Refinement

The XRisis development process implemented tight iterative cycles with fortnightly sprints, twice-weekly scrum sessions, and continuous prototype demonstrations enabling rapid feedback incorporation. Nuwa's engineering team adopted practices where each sprint delivered testable increments that Action Contre la Faim team members could actually experience, moving beyond status reports and technical descriptions to hands-on interaction with evolving capabilities, ensuring feedback addressed actual implementation rather than imagined functionality. During Phase 2 implementation from October 2024 through February 2025, this rhythm created momentum where Action Contre la Faim personnel saw visible progress every two weeks, maintaining confidence in project velocity whilst enabling course corrections before substantial effort invested in directions that user testing revealed to be suboptimal. The rehearsal workshop on 25 March 2025 represented a critical validation checkpoint, engaging Action Contre la Faim project team members (not yet involving emergency roster participants) in comprehensive end-to-end testing that identified interface issues, workflow confusions, technical integration bugs, and scenario narrative weaknesses requiring resolution before final validation. Feedback from this rehearsal directly shaped final refinements during April 2025, including simplification of navigation mechanics, addition of explicit task instructions, adjustment of AI avatar dialogue pacing, and reconfiguration of how facilitators managed scenario progression and participant observation. The team discovered that the most valuable feedback came not from asking users what features they wanted but from observing where they encountered friction, confusion, or workflow breaks during actual scenario participation, revealing usability problems that users themselves might not consciously identify yet substantially impacted effectiveness. Early demonstrations of the AI-powered Mentor Maud avatar generated disproportionate enthusiasm from Action Contre la Faim stakeholders, validating the value of conversational AI capabilities and encouraging investment in refining dialogue quality, knowledge grounding, and personality configuration even though this component had not originally been prioritised in initial technical planning. The feedback loop structure deliberately separated rapid iteration during active development from summative evaluation after platform stabilisation, recognising that users provide different types of feedback when asked "how can we improve this work-in-progress?" versus "does this finished system meet your needs?", with both feedback modes serving essential but distinct purposes in development progression. Sprint retrospectives examined not just what got built but whether the user-centric design process itself worked effectively, refining how the team gathered requirements, prioritised features, communicated technical constraints, and incorporated feedback, treating methodology improvement as equally important to technical progress. This continuous process improvement created learning effects where later sprints executed more efficiently than earlier ones because both teams had developed shared vocabulary, mutual understanding of constraints, and streamlined communication patterns that eliminated friction from

mismatched assumptions and terminology confusion. The iterative approach required tolerance for temporary incompleteness and imperfection, resisting pressure to deliver polished experiences prematurely in favour of rapid learning cycles that accumulated knowledge about what actually worked versus what seemed promising in design discussions, a discipline that ultimately accelerated overall progress despite feeling slower during early phases when functionality remained visibly incomplete.

Bridging Technical Capability and Humanitarian Needs

The greatest challenge in XR platform development for humanitarian applications proved to be not technical implementation but ensuring technical capabilities served genuine operational needs rather than showcasing impressive demonstrations with limited practical utility. Humanitarian professionals initially struggled to articulate specific technical requirements because they lacked experiential reference points for what immersive training could accomplish, defaulting to general wishes like "make it realistic" or "support collaboration" that provided insufficient guidance for implementation decisions about synchronisation protocols, avatar fidelity levels, or environmental complexity. Technical teams conversely tended to prioritise features that demonstrated sophisticated capabilities (real-time 3D object manipulation, complex physics simulations, elaborate environmental details) without thoroughly validating whether these capabilities enhanced learning outcomes proportional to implementation complexity and computational requirements. The breakthrough came from shifting focus from "what can the technology do?" to "what specific training outcomes does Action Contre la Faim need to achieve and how might technology enable them?", reframing technical decisions as means to pedagogical ends rather than ends in themselves. Nuwa's team included a member with previous humanitarian field experience at Action Contre la Faim, providing insider understanding of organisational culture, operational pressures, and decision-making contexts that purely external consultants would have required substantially longer to develop, illustrating the value of cross-domain expertise within technical teams rather than relying solely on client liaison for domain knowledge transfer. The process revealed numerous instances where initial requirements reflected assumptions that field testing contradicted: for example, the assumption that team collaboration would work best with all participants using VR headsets proved incorrect when validation revealed that co-located participants preferred face-to-face interaction supplemented by desktop interfaces rather than mediated virtual presence. Technical capability bridging requires acknowledging that domain experts possess deep knowledge about their operational needs but may not know how to express those needs as technical requirements, whilst technical experts understand implementation possibilities but may not grasp domain-specific constraints that render certain solutions impractical despite technical elegance. The solution lies in collaborative exploration where both sides contribute complementary knowledge through joint problem-solving rather than sequential handoffs where one side specifies requirements that the other side implements without ongoing dialogue. Demonstration-driven requirement gathering proved far more effective than specification documents: showing a rough prototype that embodied a proposed capability generated immediate concrete feedback about what worked, what didn't, and why, whereas written specifications often generated only abstract approval that evaporated upon first contact with actual implementation. This discovery fundamentally influenced development approach: rather than extensive upfront specification followed by implementation, the team adopted minimal viable specification followed by rapid prototyping and demonstration-based refinement, accepting that initial directions would require substantial adjustment based on user interaction with actual capabilities rather than imagined features. The approach demands humility from technical teams about accepting that impressive technical achievements may deliver minimal user value, and openness from domain experts to recognise that solutions may look quite different from initial expectations yet serve needs more effectively than originally imagined approaches, requiring mutual trust that both sides genuinely seek optimal outcomes rather than defending predetermined positions.

Lessons for Future XR Platform Development

The XRisis user-centric design experience generated transferable lessons applicable to XR development in other specialised domains beyond humanitarian training. Invest substantially in early domain immersion before proposing technical solutions: the time Nuwa spent observing actual training delivery, participating in existing e-learning modules, and understanding organisational processes proved essential for developing solutions that fit within rather than requiring wholesale restructuring of institutional practices and workflows. Prototype early with deliberately incomplete implementations that invite collaborative refinement rather than polished demonstrations that suggest design finalisation, creating psychological permission for stakeholders to request changes and express concerns about directions that might not serve their needs. Identify and engage domain-expert translators who can bridge between technical possibilities and operational requirements, whether through external consultants, internal staff with cross-domain experience, or dedicated liaison roles that create continuous communication channels throughout development rather than relying on periodic formal reviews. Separate theoretical knowledge transfer from situated skill practice when designing training applications: immersive technology provides limited incremental value for conveying conceptual information but substantial value for experiential learning requiring contextual practice with realistic dynamics, making application focus essential for justifying XR investment. Budget time for expectation calibration and mutual learning between technical and domain teams: the weeks spent in collaborative exploration where both sides developed shared understanding about possibilities and constraints represented essential project infrastructure not overhead to be minimised. Validate assumptions through hands-on user testing rather than relying on expert opinions or specification reviews: actual interaction with working prototypes reveals usability issues, workflow misalignments, and value propositions that prove different from what designers anticipated or users predicted they would want. Maintain flexibility about implementation approaches whilst preserving clarity about ultimate objectives: how technical capabilities combine to serve learning outcomes matters far more than whether specific technologies get incorporated, enabling pragmatic substitutions when integration challenges or performance limitations make originally planned approaches impractical. Recognise that successful XR deployment in specialised domains requires more than technical excellence: understanding organisational culture, workflow constraints, change management dynamics, and user capability profiles determines whether technically sound solutions achieve adoption or languish unused because they failed to accommodate human and institutional realities. These lessons apply equally to healthcare XR training, industrial maintenance support, educational simulations, and other domains where technical teams must collaborate with specialised practitioners to create solutions addressing real operational needs, making the XRisis experience a valuable reference for the broader XR development community navigating similar challenges in their respective application areas.