--- title: "Our approach: from discovery to ongoing support" description: "Discovery and consultation, co-design workshops, prototyping, testing and deployment, ongoing support: how PTR builds XR and AI training with your people." canonical: https://peopletechrevolution.com/about/approach --- [About Us](https://peopletechrevolution.com/about) # Our approach Every scenario is built with your practitioners, your language and your real situations, with psychological safety designed in from the opening workshop. You get a straight answer on whether immersive practice earns its place, before any money moves. ## How we decide the work is real Before any build we apply the DICE test, from Stanford’s Jeremy Bailenson and the Virtual Human Interaction Lab: is practising this in real life Dangerous, Impossible, Counterproductive or Expensive? If the answer is no on all four, we say so, even when that means telling you not to buy VR, AR or AI from us. When it is the right tool, PTR builds in Unity and Unreal Engine for VR, AR and MR, WebXR for the browser, native mobile, and modern web and AI stacks. HOW A PROJECT MOVES ## From the first conversation to the years after launch Discovery, co-design, prototyping, testing, support. Scroll through them the way a project lives them: each stage takes the whole screen, with the room it happens in behind the word. - DISCOVERY - CO-DESIGN - PROTOTYPING - TESTING - SUPPORT 01 of 05 ### DISCOVERY Discovery and consultation: Weeks one to four We start with your goals, the people who will use the build and the technology that fits them. If practice in real life is not dangerous, impossible, counterproductive or expensive, we say so and stop here. 02 of 05 ### CO-DESIGN Co-design workshops: Weekly, with your team Your practitioners shape the scenarios in their own language: an alignment session, a high-level concept, scripts, storyboards and agreed constraints. Lived experience sits at the table as an equal. 03 of 05 ### PROTOTYPING Prototyping and development: Months two to six Environments, characters and features are built and rebuilt: draft builds, two to three feedback rounds, and short fortnightly check-ins so nothing drifts from the brief. 04 of 05 ### TESTING Testing and deployment: Before launch The build goes to the people it is for, on the platforms they use, with the accessibility check done first. Then it ships with analytics and support built in. 05 of 05 ### SUPPORT Ongoing support: After launch, for as long as it runs Guides and workbooks, a high-level review, and a team that stays with the experience as it changes, with clear approval and content-oversight accountability rather than a one-off sign-off. The timeline ## One to three months of design, three to six of build Discovery and design run for one to three months: weekly workshops that end in an alignment session, a concept, scripts, storyboards and agreed requirements. Development runs for three to six months: draft builds, feedback rounds, user-testing prototypes and fortnightly check-ins. Delivery brings the final product, guides and workbooks, then a review and ongoing support. You explain the job at hand, and we listen before anyone proposes a technology. Your practitioners and people with lived experience shape the scenario at the whiteboard. You choose the format your staff will use: phone, controller or headset. Co-design ## Lived experience sits at the table as an equal Lived experience counts as much as professional expertise. The Central Coast Council program was co-designed with the Council’s Access and Inclusion Reference Group, and members of that group appear in the VR itself. Co-founder Leonie Sanderson, a facilitator qualified in psychology and communications, shapes and leads the workshops, weighing emotional impact against the risk of re-triggering the people taking part. Your workshops are led by Leonie Sanderson, whose training is in psychology and communications. Your tester talks through the blockout while it is still coloured blocks, so the scene is theirs before it is built. Your team sees a working scene on a tablet at the end of a workshop, not a rendering months later. Want to see how this runs on your own project? [Open the contact form](https://peopletechrevolution.com/about/approach#contact) Ask our CEO Simon Lowe’s Digital Twin a question Governance ## What we settle before a scenario is built In a published article on VR in healthcare workforce training we set out the considerations we hold ourselves to on every project: privacy and data protection; ethical design, co-designing bias, trauma or discrimination scenarios with the affected groups; transparency about any embedded AI; informed consent with pre-briefing, debrief guidance and an opt-out; psychological safety with skilled facilitators; governance and evaluation with clear approval and content-oversight accountability. Your reviewer watches a session with the approval controls in view, and can stop it. Your people are told when an AI is in the scenario, before it speaks. You decide what a build is allowed to know, and it knows nothing else. The room ## The opening workshop decides what the work is Before anything is built, the people who live the situation sit at the table and say what a hard day contains. A scene starts as a sketch, then as a rough version somebody can stand inside and argue with. Moving a wall at that point costs an afternoon; moving it after the scenario has been written around it costs the scenario. Your scenario is shaped by hand with your people in the room, so what ships is recognisable to them. ### The moment is shaped by hand before it is built The people the scene is about are in the room while that happens. They argue with the rough version, and the argument is what the build is made of. Your trainers’ feedback turns into a change while it still costs an afternoon, not a rebuild. We adjust the scene while your tester is still inside it, so what feels wrong is fixed while they still feel it. Your team walks the build together, and anyone can point to the moment that does not ring true yet. Sign-off ## The people who sign off see what your learners will see Every build goes to the people it is for, on the platforms they use, with the accessibility check done before launch. Your client signs off on a room they have stood in, not a storyboard. Then it ships with analytics and support built in, and a team that stays with it as it changes. The people who sign off see exactly what your learners will see, before anything is final. Before launch, every control is checked for people who have never held a controller. Want to see how this runs on your own project? [Open the contact form](https://peopletechrevolution.com/about/approach#contact) Ask our CEO Simon Lowe’s Digital Twin a question ### Where this leads The values behind the method, the years that shaped it, and the projects it produced. [Our values. Community, excellence, trust and creativity, and how each one shows in the room.](https://peopletechrevolution.com/about/values) [Our story. From The Ageing Revolution to the PTR VR Library, told a year at a time.](https://peopletechrevolution.com/about/story) [Our work. Case studies, industries and the research behind them.](https://peopletechrevolution.com/work) - [Training programs](https://peopletechrevolution.com/training) - [Rehearse it in VR](https://peopletechrevolution.com/xr) - [Practise with AI](https://peopletechrevolution.com/ai) - [Fast Builds](https://peopletechrevolution.com/fast-builds)