Scaling Training Production
Every client project rebuilt the same pieces from scratch. I set the vision for a shared framework and led a team of eight to make it work alongside client deadlines.
- Client
- VR Owl
- When
- 2024 - now
- Team
- 5 developers and 3 3D artists, with me as design and project lead
- Duration
- Ongoing, about 2 years so far
- My role
- Product vision, Prioritisation, Process design, Design lead, Documentation
Challenge
Every client project rebuilt the same instructions, checks and feedback moments from scratch, which made VR training slow and expensive to make.
What I did
Set the vision for a modular framework, let the developers decide how to build it, and kept balancing it against client work.
Result
3×Internal production went from one training module per quarter to three, and VR Owl now has a library of standalone products.
The problem
VR Owl makes VR training for clients in many industries. As the number of projects grew, we noticed the same pieces coming back every time: instructions, safety checks, confirmations, feedback moments, progress indicators. Every project designed and built them again, slightly differently. That made training slow and expensive to make, and it meant we couldn’t easily sell trainings as ready-made products.
My role
This is an internal product, and it’s been running for about two years. I’m the design and project lead. I set the vision: what the framework should do, what it should cover first, and in which order. The developers decide how to build it, because they know best. The core team is five developers, with three 3D artists involved less often.
What we built
First I mapped which patterns kept coming back across client projects, and where a shared structure would save time without making every training look the same. From that we built a modular framework that defines:
- Components like instructions, checks and confirmations, built once and reused.
- How users are guided through a training, step by step.
- Brand-neutral styling, so a client’s colours and logo can be applied without changing how anything works.
The hard part: balancing
The framework had to grow while client work kept coming in, with its own deadlines. Most of my job was deciding what mattered most right now: which framework improvement would help the next client project, what could wait, and when a module was good enough to release. We built internal modules alongside client projects, so every release tested the framework on real work. Topics included NEN 3140, PPE, LOTOTO, fire safety and CPR.
Video courtesy of VR Owl
Outcome
Internal production went from one module per quarter to three: from one every three months to one a month. Modules became more consistent, development costs went down, and VR Owl now has a catalogue of trainings it can sell as standalone products.
Image courtesy of VR Owl
What I’d do differently
Start with a clearer project overview. Because the framework grew alongside client work, the big picture lived mostly in my head for a while. A shared overview from day one would have made priorities easier to discuss with the team and easier to explain to others.