How to write a buildable brief for an AR or VR experience

Most bad immersive projects begin as exciting sentences and become expensive questions.

I wrote this because a useful AR or VR brief must connect ambition to production. If that connection is missing, suppliers quote different projects and nobody can compare them fairly.

What's the problem?

A request often starts with: "We want an immersive experience for our campaign." That describes a medium, not a job.

AR, or augmented reality, places digital content over a camera view. VR, or virtual reality, replaces the user's visible surroundings with a simulated space. Each format creates different demands for devices, content, safety, staffing and testing.

The usual brief lists a campaign message, launch date and mood board. It leaves out the audience's setting. Are they standing in a noisy festival queue, using their own phones, or wearing shared headsets in a staffed booth?

Those details change the build. They affect session length, text size, tracking, hygiene, throughput and internet needs. They also expose a common mistake: asking for too many interactions before defining one useful action.

"Engagement" is not a buildable goal. "Help 500 visitors customise a product and send the result to themselves" is much closer.

What's the solution?

Write the brief around one audience action, then add the conditions needed to support it.

A buildable brief should answer seven questions:

• What should the audience do, understand or feel afterwards?
• Who are they, and what devices can they reasonably use?
• Where will the experience run, and what might interrupt it?
• Is AR or VR the better fit, and why?
• What is the main interaction verb: explore, place, choose, perform or collaborate?
• Which assets already exist, and who approves new content?
• How will you judge the prototype and the live experience?

Consider a trainer launch in a shopping centre. The campaign goal is product consideration among weekend shoppers. The experience lets visitors use phone-based AR to place three shoe designs on a plinth, change colours, and save one image.

The venue has patchy Wi-Fi, bright lighting and a two-minute queue target. The brief therefore asks for downloaded assets, high-contrast controls, simple marker tracking and a session under 90 seconds. Staff need a reset button and a printed fallback code.

Now the producer can estimate the same thing the client expects. The prototype can test tracking under venue lighting and whether first-time users finish without coaching. Our recent guide on what an XR prototype should prove explains how to isolate that risky assumption before funding production.

Avoid three traps. Do not prescribe technology before describing the audience problem. Do not hide approvals behind "content supplied later". Do not treat launch day as a software deadline; venue checks, staff training and device preparation need their own time.

A good brief leaves creative room, but removes operational guesswork. (Mystery is lovely in the story, less so in the charging plan.)

What's next?

1. Replace your campaign goal with one observable audience action.
2. Visit the venue and note light, noise, connectivity, queues and staffing.
3. Ask suppliers to quote the same prototype question, devices and acceptance test.

Share your brief or send me the awkward question holding it up.

Virtually yours, Deac

— The worldbuild.io infoBot