Roche VR Training
An immersive training system that let scientists and technicians practice complex laboratory procedures in a safe virtual environment.
The role statement defines my contribution boundary for this record. Client leaders, product partners, designers, artists, quality specialists, operators, and other engineers retain credit for their respective work; a project is described as independently built only when the supplied operating record supports that claim.
The Mandate
Turn Expert Procedures Into a Reusable Training Platform.
The central design problem was not how to build one impressive laboratory simulation. It was how to represent many procedures, devices, steps, checks, and learning outcomes without rebuilding the application each time the training content changed.
The Product As a Complete System
The visible experience was only one layer. These were the responsibilities that had to cooperate for the product to remain useful under real operating pressure.
Lesson Definition
Procedure steps, expected actions, instructional context, branching, and completion criteria.
Content needed to change at the pace of subject-matter review without destabilizing the runtime.
Interaction Runtime
Object handling, equipment behavior, spatial feedback, and reusable VR interaction rules.
The same action needed to feel consistent across lessons while still respecting device-specific behavior.
Progression & Assessment
Step state, validation, feedback, mistakes, completion, and measurable learning events.
The system had to distinguish exploration from assessed performance without confusing the trainee.
Authoring & Delivery
Content updates, review, release discipline, analytics, and collaboration between experts and engineers.
Knowledge transfer could not depend on programmers translating every procedural revision by hand.
Spatial guidance lets a trainee rehearse a laboratory procedure while the system preserves sequence, feedback, and measurable progress.
What The System Had To Solve
- Represent detailed laboratory equipment and procedures without turning every lesson into a new software project.
- Give non-programmers a safe way to author and revise training content.
- Preserve consistent interaction, progression, feedback, and assessment across lessons.
- Make procedural mistakes safe enough to learn from while keeping the virtual workflow faithful to expert intent.
How I Approached It
- Created a ScriptableObject-driven lesson model that separated learning content from reusable runtime systems.
- Built shared services for interaction, step progression, assessment, and analytics.
- Led planning, reviews, backlog quality, and release discipline for the delivery team.
- Designed authoring boundaries so subject-matter experts could change lesson content without reopening core runtime behavior.
The Tradeoffs That Shaped The Product
Architecture becomes meaningful when the decision, alternative cost, and operating reason remain visible together.
Content Outside The Runtime
Represent lesson structure through ScriptableObject-driven content rather than hard-coding every procedure.Separating content from behavior reduced repeated engineering and created a safer path for expert-authored revision.
Shared Services Before More Lessons
Build common progression, interaction, assessment, and analytics services as platform capabilities.The value of the architecture appeared in the second and third lesson; shared services made consistency cumulative.
Errors As Learning State
Model incorrect actions and recovery as part of the training flow.A safe simulation is most valuable when it lets a trainee understand consequences and recover, not only follow a perfect path.
Separating training content from the shared runtime lets subject-matter experts improve a lesson without rebuilding the complete product.
What Changed
- New features could become available to current and future lessons through the shared framework.
- Subject-matter experts could update scenarios without changing core application code.
- The platform reduced repeated engineering work while preserving a consistent training experience.
- Training logic, assessment, interaction, and content could evolve as separate concerns instead of becoming one tightly coupled lesson script.
What Supports The Story
Evidence is classified so a reader can distinguish public verification, portfolio-reported outcomes, and implementation details shared from direct experience.
Authoring Model
ScriptableObject-driven lesson content separated procedure definition from shared runtime systems.
Reusable Services
Interaction, progression, assessment, and analytics were designed as shared platform concerns.
Operational Value
The portfolio record describes reduced repeated engineering and safer expert-led content updates.
Delivery Partner
Ascent XR maintains a public record of its immersive enterprise work.
This case study explains the reusable architecture and delivery reasoning without publishing confidential laboratory procedures, proprietary Roche equipment details, trainee data, or client-sensitive implementation material.
What The Project Taught Me
Separate lesson authorship from the runtime systems responsible for interaction, assessment, and progression.
Platform leverage becomes visible in the cost and confidence of producing the next scenario.
Useful wherever subject-matter experts need to evolve structured content without reopening the entire application.
What This Work Demonstrates
- XR architecture
- Authoring systems
- Assessment
- Engineering leadership