Describe the action the visitor should take
Write a small sequence: recognize the product, choose a feature, understand its role, and return to the overview. Identify which action is essential and which is optional. Separate a guided product presentation from training, assessment or a validated engineering simulator; each has a different scope and evidence requirement.
Decide who controls the experience. A salesperson operating a shared screen, a visitor holding a tablet and a visitor wearing a headset place different demands on the interface and the booth.
Use a short visitor journey
| Stage | Visitor sees or does | Operator check |
|---|---|---|
| Start | Overview with one clear first action | Correct build, device and starting state |
| Explore | Select a feature and receive feedback | Selection remains understandable at the booth |
| Return | Back or overview action | No hidden menu is required to recover |
| Finish | A clear ending and next step | Reset clears the previous visitor’s state |
| Fallback | Screen or video explanation if needed | The sales conversation can continue |
Write the operator runbook before the event
An interaction is only one part of a staffed exhibition experience. The operator also needs to welcome the visitor, explain the controls, recognise a stalled session and restore a known starting state. Write those steps in plain language and test them with someone who did not build the application.
| Moment | Operator action | Pass condition |
|---|---|---|
| Start of day | Power up the specified device and open the approved build | The correct product and start screen appear. |
| Before a visitor | Check the controls, presentation area and starting state | No previous selection or error blocks the next session. |
| During a session | Offer the agreed introductory instruction | The visitor can complete the main task without a developer. |
| After a session | Return to the starting state and prepare the device | The next visitor sees the intended introduction. |
| If the demo fails | Switch to the agreed fallback and record the symptom | The presenter can continue the product conversation. |
Device fitting, cleaning, comfort guidance and supervision depend on the actual hardware and venue. Include those instructions in the agreed operational plan rather than assuming that a software handover covers them.
Plan capacity with the whole session in mind
For a shared screen, several people may watch while one person controls the product. For a headset experience, plan a way for companions and waiting visitors to follow the explanation. An animation or physical model can keep the surrounding conversation useful without forcing every visitor into the same interaction.
Check the booth conditions
- Usable space, visitor access, seating and nearby screens.
- Power, charging, network availability and responsibility for each.
- Lighting and physical reference conditions relevant to the chosen AR setup.
- Audio, language, readable text and the operator’s demonstration script.
- Device handling, cleaning and supervision procedures using the manufacturer’s guidance.
- A reset, restart and fallback procedure available to the operator.
Define and test offline behaviour
List what must work without a network: launching the application, loading models and media, starting the experience and resetting it. Then test those actions on the intended build and device with the connection unavailable. A cached browser page is not sufficient evidence that every asset or startup step works offline.
Agree installation, account requirements, updates, device licensing and content delivery before the event. These requirements depend on the selected platform; ask for a deployment checklist rather than assuming a video or a 3D model is the entire deliverable.
Keep a device-specific acceptance record
Record the device model, operating system, browser or application version, build identifier and date tested. Include the normal start, interrupted session, idle timeout, repeated reset and recovery from a network loss where relevant. “Works on a phone” is not a reproducible test result.
An offline requirement needs a deliberately disconnected test after the intended installation process. A previously loaded browser tab can conceal missing assets in its cache. Confirm what is installed, what must be fetched and what happens on a fresh restart. Use the format comparison to decide which device tests belong in your scope.