How does the build reach the device?
The design conversation starts with the experience. The shipping conversation starts somewhere duller: how a build gets onto a device that belongs to someone else, and who fixes it when it will not start. Answer that first, because the route determines the account model, the update cadence and how quickly a fix reaches users.
- A public store listing: platform review, store policies, age rating, privacy declarations and a product page you maintain.
- Managed distribution to devices a client owns: no store review, but the update mechanism is yours to run, whether that means a device management platform with kiosk launching and remote install or a routine somebody performs by hand.
- Phone and tablet AR through the mobile stores: the hardware is already in the user’s pocket, and you inherit store review and platform requirements that can force periodic rebuilds.
- The browser, through WebXR: no store, but support differs by browser and headset, so verify it on the exact devices in the room.
What the device choice commits you to
Choosing between headset classes on their merits is its own question, and one worth taking separately. What belongs here is the tail that follows the choice, because a device commits you to an art budget, an interaction model, a comfort profile and a support routine before anyone writes a line of gameplay code. The useful questions are about the room: who wears it, how many at once, who supervises, and whether their hands need to be free.
Standalone headsets carry a mobile-class GPU and a thermal envelope to match, and the art budget follows from that. Tethered headsets give more rendering headroom, and in return you have shipped a PC, a cable and a longer setup routine to every site. Phone AR removes the fleet entirely and hands you every screen size and thermal profile your users own, with tracking that depends on the room’s lighting and surfaces. Passthrough mixed reality makes the physical space part of the design, so content has to behave in a cluttered room.
Frame budget is a constraint, not a polish task
In XR the scene is rendered for each eye at the headset’s refresh rate, and frame loss is experienced differently from a stutter on a monitor. Runtimes use reprojection to cover isolated misses, but sustained frame loss can leave users uncomfortable rather than merely unimpressed. That argues for treating performance as a design constraint instead of end-of-project optimization: set the budget first, then design inside it.
In practice that means polygon and draw call budgets agreed with whoever builds the art, a texture memory ceiling, lighting that is mostly baked, and transparency and post-processing treated as expensive. It also means building to the device continuously. Editor playback on a workstation GPU is useful for logic and interaction, but it will not tell you what a frame costs on a standalone headset. Thermals matter as well: a headset that runs warm will throttle, so behavior late in a long session can differ from a short desk test.
Comfort, accessibility, and who can use it
If the audience is a workforce or the public rather than gamers, the design has to work for people who have never worn a headset, who wear glasses, who are seated, who have limited hand mobility, or who get motion sick.
An experience that only works for a confident, standing, two-handed user with good vision is not finished, and it carries an eligibility requirement nobody wrote down. Five choices carry much of that weight:
- Locomotion: teleport, snap turn and comfort vignettes, or a design without artificial locomotion at all.
- Seated and standing modes with height calibration, and no required interaction on the floor or overhead.
- One-handed and dominant-hand options, and alternatives to gestures that demand fine motor control.
- Captions and a visual equivalent for every audio cue, since a shared room may be loud.
- IPD adjustment, glasses spacers and a fitting routine somebody performs.
Who looks after the headsets on a Tuesday morning?
Operations is where a deployment meets the real site, and it can go unowned unless somebody is named for it. Work through it while the build is being scoped: charging and storage between sessions; cleaning and replaceable facial interfaces; boundary setup for each room and who redoes it when furniture moves; whether users need platform accounts or managed device accounts; what a non-technical staff member does when the headset shows the platform’s own error screen instead of your app; and how a new build reaches devices. Storage matters physically too, since direct sunlight through the lenses can damage display panels.
The countermeasures are unglamorous: kiosk or launch-on-boot configuration so the app starts without navigating a store interface, a one-page runbook for the staff who hold the device, an on-site champion, and offline behavior that does not end a session when the network drops. Add telemetry with whatever consent handling the deployment requires, since a user mid-session is unlikely to stop and write up what went wrong. Crash reporting and light session logging are how the problem gets described after the fact.
The IT and privacy questions worth raising early
An XR device is a networked computer with cameras and microphones worn on someone’s head, which raises questions a laptop application does not. Put them in the first requirements conversation rather than the week before launch: what passthrough cameras and room scanning capture, whether any of it leaves the device, and what is retained; how hand, eye and body tracking data is classified under the client’s policies and applicable law; network provisioning, since captive portals and certificate-based enterprise Wi-Fi are awkward on a device with no keyboard; and what the experience does when a user declines a permission.
Maintenance is part of the same review. Platform operating system updates arrive on the vendor’s schedule and store rules can require rebuilding against a newer SDK, either of which can change how a shipped app behaves. An XR deployment needs a named maintenance owner.
Pilot before the fleet arrives
Everything above is operational load, and it is easier to judge from a small deployment than on paper. Before hardware is ordered in quantity, run the experience on the real devices, in the real room, with real users, and with the staff who will run it when you are not there.
A pilot can answer questions a design review cannot: whether the Wi-Fi in that building holds up, whether the boundary survives a room that gets rearranged, whether the fitting routine happens when nobody is watching, how long the batteries last across a real session schedule, and what staff do when something does not start. Those are device, network and human questions, and they are better settled before a fleet is committed than after.
If the pilot suggests the experience does not need a headset at all, that is a useful result rather than a failed one. Choosing between AR, VR and flat delivery deserves to be worked through on its own terms, before any of the deployment work above begins.
Related service: Related service: If an immersive project is on your roadmap, our AR and VR development page is the place to start a conversation with us.