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.

A standup in front of a wall of notes at the start of a project. Step 01 of five, Discovery and consultation: Weeks one to four.

A workshop table where a team works through a scenario together. Step 02 of five, Co-design workshops: Weekly, with your team.

A first prototype reviewed as floating panels in an office. Step 03 of five, Prototyping and development: Months two to six.

An accessibility check on a phone build before launch. Step 04 of five, Testing and deployment: Before launch.

A finished build handed to the team that will run it. Step 05 of five, Ongoing support: After launch, for as long as it runs.

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.

A bearded man in a navy jacket talks across a table to two colleagues, a tablet of coloured shapes between them. — You explain the job at hand, and we listen before anyone proposes a technology.

A facilitator with grey hair talks through a flow diagram and sticky notes on a whiteboard while two participants, one using a wheelchair, watch from the table. — Your practitioners and people with lived experience shape the scenario at the whiteboard.

Three people at a table of small models, one on a phone, one holding a controller, one pointing, in a studio lined with screens. — 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.

Leonie Sanderson, PTR co-founder, who designs and leads the co-design workshops. — Your workshops are led by Leonie Sanderson, whose training is in psychology and communications.

A woman explains a coloured-block model on a desk to a man wearing a headset, in an office with bright abstract screens. — Your tester talks through the blockout while it is still coloured blocks, so the scene is theirs before it is built.

A man holds out a tablet showing a working scene to a woman in a headset, in a studio with a large screen behind them. — 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

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.

A reviewer watches an AI conversation with the approval controls in view. — Your reviewer watches a session with the approval controls in view, and can stop it.

A woman in a navy top stands in an office with a translucent panel of blank lines floating in front of her. — Your people are told when an AI is in the scenario, before it speaks.

A woman guides small glowing shapes toward a wireframe human figure, a panel of blank lines on the wall behind them. — 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.

Two hands cup a small form of blue and pink light in a dark room. — 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.

A designer and a developer at two standing desks turn toward each other, a translucent panel floating between their screens. — Your trainers’ feedback turns into a change while it still costs an afternoon, not a rebuild.

A man in a headset gestures as a colleague adjusts a monitor beside him. — We adjust the scene while your tester is still inside it, so what feels wrong is fixed while they still feel it.

A man with a pointer and a colleague at a large touch table trace a soft gradient scene in a studio hung with panels. — 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.