Web experiences

Send someone a link and the experience opens in their browser, on desktop or mobile, with nothing to install and no headset required.

A scroll-driven story, moving as the reader scrolls.

One link is the whole rollout

A web build lives at an address. The people it is for open it in the browser they already have, on the phone in their pocket or the laptop on their desk, and nobody installs anything.

The published Fast Builds timeline applies: rapid prototypes from two business days, full builds up to eight working weeks.

How Fast Builds run Try the browser demos

What you bring, what you get

A web build starts with the problem you already have and ends with something your people can open today.

A web build on two screens: what the customer sees, and the page behind it. — Reviewing a web build across two screens.

Any screen, the same build

You bring the brief: who the experience is for, what they need to do, and what it has to prove. PTR builds the working page, puts it in front of the people who matter, refines it and ships it.

What comes back is a link you can share the day it is ready, and a build that keeps evolving after launch.

Where a web build gets used

The browser is wherever the work is: a warehouse aisle, a kitchen bench, a table with three devices on it.

A warehouse picker checks a phone build between the racks. A rapid prototyping scenario for mobile experiences, from idea to working product. — A picking aid, opened between the racks.

A tablet shows coloured shapes among kitchen objects. A rapid prototyping scenario for fast builds, from idea to working product. — A tablet plan, checked at the bench.

Three people around a round table compare the same build on a phone, a tablet and a laptop, with a wall display behind them. A scene for PTR's web experiences. — Comparing the build across devices.

Two people stand at a large touch table showing a browser build, one pointing at the screen, in a bright studio. A scene for PTR's web experiences. — Trying the build on a large touch screen.

Reach over depth

A browser build trades some depth for reach. It opens from a link on a device someone already has, which suits a fast prototype, a low-friction first touchpoint, or a demo shared before committing to a larger build.

It is the weaker choice when the experience needs a headset's sense of presence, an app's offline access or device sensors, or processing better handled outside a browser. Those needs shape the platform choice, and PTR says so in the brief.

"In a world where much of our learning has moved online, the human element is often lost. VR can help bridge this gap, allowing people to practice real-world interactions in a controlled, immersive environment."

Simon Lowe, PTR's CEO. Simon Lowe
CEO, People Tech Revolution. The Cusp of a Revolution, Global Best Practice Group, October 2024

Try one now

PTR's browser builds are live on Labs Demos. Open them on a phone or laptop; nothing installs.

Two visitors inspect tabletop forms. A first person rapid prototyping scenario for web experiences, seen through the headset.

AR Business Card. An augmented reality business card that runs in the browser on a phone or laptop.

A tester moves a pointer through particles. A rapid prototyping scenario for fast builds, from idea to working product.

The Pissing Game. The camera tracks your hands and you aim without touching the mouse; the video never leaves your device.

Three reviewers use browser stations. A rapid prototyping scenario for fast builds, from idea to working product.

Immersive Learning Wall. Stand back and move: full-body pose tracking lets your hands push, gather and burst the ideas on the wall.

Every step, visible

You see working builds in sprints, not a single reveal at the end.

Practice on a monitor, a laptop or a phone. An AI roleplay scenario for AI roleplay and practice. — The same page tested on every screen.

Brief, Build, Test, Refine, Ship

Brief pins down what the page has to prove. Build turns it into something people can use. Test puts the working build in front of the people who matter. Refine changes what they showed you. Ship deploys it and keeps improving it.

The five steps are the same on every Fast Build; the detail of each is on the Fast Builds page.

A hand nudges a wireframe block. A first person rapid prototyping scenario for web experiences, seen through the headset. — The first wireframe block, nudged into place.

When the brief needs more than a browser

Some experiences need hands in the scene or a room around the person. PTR builds those too, through the same steps, and the web build is often where they start.

A scientist turns a component above the laboratory bench. — Turning a component above the lab bench.

A cook tests a mould at the kitchen bench. — A cook tests a mould at the bench.

A footwear designer checks a shoe last at the studio workbench. — A footwear designer checks a shoe last.

A tall glass panel stands upright in a dark room, its blocks lit in blue and pink but empty of any writing. — A page laid out before the words arrive.

The shape of the page comes first

Before a line is written, a web build already has a shape: what a person meets first, what they are meant to do next, and where the one thing that matters sits. Get that order wrong and better sentences will not rescue it.

So the empty structure goes in front of the people who will use it early, in the same five steps as everything else, and it changes while it is cheap to change.

Two people select speech tiles by a display. A VR training scenario for People Tech Revolution. — Two people choose speech tiles beside a display.

Words are part of the build

A web experience is read as much as it is used. The copy on the page, the labels on the controls and the line that tells someone what to do next are shaped with the client's team, in the same sessions as the layout.

When the page carries a conversation, the words get tested with the people who will read them, not written once and left.