How do you design a VR app for people who have never used a headset?

Assume zero headset literacy. Make the core task work with no interaction or a single obvious one, let an operator outside the headset start, pause and advance the session, keep text large and short, never move the camera without the user, and design a calm first minute before the real task begins.

Should enterprise VR apps use controllers or hand tracking?

Often neither for the core flow. For first-time users I prefer gaze or head direction with a clear dwell indicator for selection, a single obvious action when hands are truly needed, and the operator as the fallback for anything that would otherwise need a menu.

How do you prevent motion sickness for first-time VR users?

Let the user's head control the view at all times, never rotate or move the camera on the app's own initiative, use a fade and cut instead of smooth movement when location changes, keep a stable horizon and floor, and hold the headset's full frame rate without drops.

Why does an XR app need an operator view?

In clinical and enterprise sessions someone outside the headset is usually responsible for the session. They need to see what the user sees, control the steps and see state the user cannot report, such as tracking quality and calibration, so a confused user does not become a stalled session.

Designing XR Apps for People Who Have Never Worn a Headset

TL;DR: Most enterprise XR apps are used by people who have never worn a headset and did not choose to. A patient in a clinic, a firefighter on shift, a client looking at a property in AR. Designing for them is a different job from designing for gamers. The rules I work by now: assume zero headset literacy, let an operator outside the headset drive the session, put almost nothing in front of the user's hands, keep text large and few, never move the camera without the user, and design the first sixty seconds as carefully as the core feature. Below is how each of those plays out, from clinical XR at Nystag and public-safety and enterprise AR at ARCortex.

The thing that most changed how I think about XR interfaces is who the user is. Almost every tutorial, design guide and sample project assumes a user who bought the headset, wants to be in it, and knows what a controller trigger is. In enterprise and clinical work, that user barely exists.

Who is actually wearing the headset

When I worked on the Nystag clinical eye-tracking app on the Vive Focus 3, the person wearing the headset was a patient. The person running the session was a clinician. Neither was a VR enthusiast, and both had something more important to do than learn our interface.

At ARCortex the picture was similar. ERIS, the XR platform we built for the California Fire Brigade, was used by firefighters, and the AR tools around it, like AR Planes and AR Properties, were built for people who needed to see something quickly, not learn a spatial interface.

So the first design question is never "what does the interface look like". It is "who is wearing this, did they choose to, and how many minutes of patience do they have". The honest answer for most enterprise XR is: a first-timer, not by choice, and about thirty seconds.

Rule 1: assume zero headset literacy

Things that feel obvious to anyone who has used VR are not obvious to a first-timer:

That you can turn your head and the world stays put.
That the floating panel is something you can point at.
That the grey outline at the edge is a boundary, not a decoration.
That the controller in your hand has buttons you cannot see.

Every one of those is a small lesson, and a first-timer arrives with none of them. If your app needs the user to learn three of them before the real task starts, a good share of sessions fail before they begin.

The practical consequence is that I design the core flow so it works with no interaction at all, then add the minimum interaction the task genuinely needs. For a diagnostic, that can mean the user does nothing but look where they are told. That is not a lack of ambition. It is the product working.

Rule 2: let someone outside the headset drive

In clinical XR, some of the most important design work is not inside the headset at all. It is the operator's side.

The person outside needs to see what the person inside sees, start and stop the session, move between steps, and recover when something goes wrong, all without taking the headset off the patient. If the only way to advance is a button inside the headset, every confused user becomes a stalled session and a clinician guessing what is on screen.

So for any app with an operator, I treat the outside view as a first-class client:

Mirror or summarise what the user is seeing, so the operator can coach in plain words.
Put the controls outside: start, pause, skip, restart a step.
Show state the user cannot report, such as whether tracking is good, whether calibration passed and how far through the session they are.

This is the XR version of a lesson I keep relearning in AI work too: the person who supports the system needs a view of it, not just the person using it. It is the same reason I build dashboards behind voice agents, which I wrote about in the CallSetter dashboard build.

Rule 3: hands are optional, and often busy

Controllers are a learning curve. Hand tracking is a different learning curve, and less predictable for someone who does not know where to hold their hands.

For many enterprise users, hands are not free anyway. A firefighter may be wearing gloves. A patient may be gripping the chair or simply unsure whether they are allowed to move. Someone looking at a property is holding a phone, a coffee or a clipboard.

My default is now:

Gaze or head direction for anything the user must select, with a clear dwell indicator so selection never feels accidental.
A single obvious action when hands are needed, never a combination.
The operator as the fallback for anything that would otherwise need a menu.

When I wrote about designing ERIS for gloves, sun and stress, this was the same instinct from a different direction. If an interaction needs fine motor control, assume it will fail in the real environment, and design a path that does not need it.

Rule 4: text is the most expensive thing you can show

Text in a headset is hard to read. Resolution is lower than people expect, the edges of the lenses are blurry, and a first-timer will not have adjusted the headset to sit properly on their face.

So text has to earn its place:

Large, high contrast and centred, inside the sharp part of the view, not near the edges.
Short, a few words that tell the user what to do now, not a paragraph explaining why.
Placed at a comfortable distance and kept still, not attached rigidly to the head where it swims with every movement.
Spoken where possible. A calm voice saying "look at the dot" beats any written instruction for someone who is still working out where to look.

If a step needs a paragraph of text to explain, the step is wrong. Either the operator explains it before the headset goes on, or the step is redesigned so it does not need explaining.

Rule 5: never move the camera without the user

Motion sickness is the fastest way to end a session, and first-timers are the most sensitive to it because nothing has adapted yet.

The cause is nearly always the same: the view moves in a way the body did not ask for. Artificial movement, smooth turning, a camera that drifts to frame a scene, a sudden cut that changes height. Gamers sometimes tolerate it. A patient in a clinic or a property buyer will take the headset off and not put it back on.

For enterprise work I treat these as hard rules:

The user's head controls the view, always. The app never rotates or moves the camera on its own.
If the user must change location, use a fade and a cut, not a glide.
Keep a stable horizon and a visible floor, even in abstract scenes.
Hold frame rate. A dropped frame in a headset is felt in the stomach, which is why I put so much weight on holding 90 FPS on standalone headsets.

Rule 6: design the first sixty seconds as a feature

The first minute decides whether the session happens at all. It is also the part most teams build last, in a hurry, after the "real" feature works.

A good first minute for a first-time user, as I design it now, looks like this:

The operator explains before the headset goes on. What they will see, how long it will take, that they can stop at any time.
The headset fits. A short fit check that confirms the display is sharp, because a blurry first impression ruins everything after it.
A calm, empty starting space with a floor and a single point to look at. No menus, no logos, no instructions yet.
One small success. Look at this, and something gentle happens. The user learns that the world responds to them.
Then the task. Only now does the real content start.

On a clinical app this also protects the data. A patient who is still disoriented will not produce clean measurements, so the calm start is part of making the result trustworthy, not just pleasant.

Rule 7: test with people who have never worn one

The team building an XR app is the worst possible test group. We have worn headsets for years, we know where every button is, and we stopped noticing the strap long ago.

The only test that matters is a first-timer, ideally one who resembles the real user, wearing the headset while you watch silently. Every time you want to say "just look to the left", write it down. That is a flaw in the interface, not in the user. I wrote about the wider version of this in field testing AR apps: the editor and the developer both lie, and only real people in real rooms tell you the truth.

A short checklist for enterprise XR interfaces

Write down who wears the headset, whether they chose to, and how patient they will be.
Make the core task work with zero or one interaction.
Build the operator view as a real client, with controls and state.
Prefer gaze and dwell for selection, and keep hands optional.
Keep text large, short, central and still, and speak instructions where you can.
Never move the camera without the user, and never drop frames.
Design and test the first sixty seconds before polishing anything else.
Test with first-timers, watching, without helping.

None of this is novel design theory. It is what you end up with after watching enough people who did not ask to be in a headset try to use one. The hardware question comes first, and I covered it in choosing an XR headset for enterprise deployment. The interface question is what decides whether anyone actually uses it.

I have built XR systems for public safety and healthcare, and now build production AI agents and products for startups across the US, UK and Europe. If you are planning an XR app for people who have never worn a headset, more about my background is here, or book a call.