What should an XR prototype prove before you fund the build?

An XR prototype should answer a dangerous question, not preview the finished experience.

I have seen teams fund polished prototypes that proved very little. Working on festival-grade virtual and augmented reality has taught me to test the weakest assumption first.

What's the problem?

XR, shorthand for virtual and augmented reality, becomes expensive surprisingly quickly. A convincing build may need 3D artists, developers, sound designers, producers, hardware and testing space.

That makes a prototype feel reassuring. Everyone can see something. The client can wear a headset or point a phone at a marker. The team can discuss colour, scale and animation.

Yet a beautiful prototype may avoid the question most likely to kill the project.

Perhaps the audience will not understand how to begin. Maybe the venue lighting will break tracking. The experience could require more physical space than visitors have. A multiplayer idea may fail when forty people arrive together.

Commissioners often ask a prototype to prove everything at once. The result is a small, underfunded version of the final build. It has weak art, temporary systems and no firm success measure. Nobody knows whether mixed feedback means continue, revise or stop.

The common mistakes are simple: testing too many assumptions, polishing before learning, using friendly insiders and deciding the success criteria afterwards. That last one is especially convenient when everyone already likes the idea. [Funny how every result becomes promising.]

What's the solution?

Start by writing one sentence:

“We believe this project works only if…”

Finish it with the riskiest assumption. Choose something uncertain, important and testable. If the assumption fails, the full build should change or stop.

For an augmented reality festival trail, the sentence might be: “We believe this works only if first-time visitors can find and launch the experience without staff assistance.”

Now build the cheapest honest test. “Honest” means the test must preserve the part that creates the risk. A printed storyboard cannot test phone tracking. A narrated video cannot test whether people understand an interface. However, rough grey boxes can test movement, scale and navigation perfectly well.

For the festival trail, we might create one working location rather than ten. Use temporary artwork, the intended phone type and the real entrance signage. Recruit five people who have not seen the project. Give them the same instructions a visitor would receive, then stay quiet.

Before testing, set the decision rule. For example:

Go: four of five people launch the AR scene within 60 seconds, unaided.

Revise: three succeed, or people repeat the same recoverable mistake.

No-go: two or fewer succeed, or tracking fails under venue conditions.

These thresholds are not universal truths. They are agreements that stop taste, enthusiasm and sunk cost from rewriting the result.

A no-go does not always kill the whole idea. It may kill one interaction, device choice or venue plan. That is still useful. You have spent a little money to avoid spending much more on the wrong build.

What's next?

1. Write your “works only if” sentence and remove every secondary concern.
2. Design the smallest test that preserves the risky behaviour or technical condition.
3. Set go, revise and no-go thresholds before showing anyone the prototype.

Share the assumption you are testing, or ask me where I would cut the prototype.

Virtually yours, Deac