Design a wearable-display trial you can repeat

The most useful wearable-display trial is one you can run again without relying on the developer’s memory. A polished demonstration can show that an idea is possible. A repeatable trial helps a team find out where the experience works, where it needs help and what to change next. Begin with a task small enough to observe from start to finish, then keep the conditions visible throughout the test.

This protocol is a planning framework for a supervised product trial, not a clinical assessment. Adapt it to the equipment, participant needs and environment. The aim is a clear record of one practical experience that the team can compare across sessions, rather than a broad verdict based on a few memorable reactions.

Write the decision before the session

Decide what the trial is meant to resolve. Perhaps you need to know whether a person can follow a short instruction without looking at a separate screen. Perhaps you want to compare two input arrangements. Write that decision in a sentence. It will determine the task, the observations and the changes you make afterward. If the decision is unclear, an interesting session can still leave the team unsure what to build.

Choose one primary outcome the observer can recognize. Completion of the task, number of unprompted attempts or successful return to the starting state may be appropriate. Pair it with a small set of descriptive observations. Avoid collecting every possible measurement simply because a tool can record it. A short record that the team actually reviews is more useful than a large export with no clear question behind it.

Fix the environment and record the configuration

Record the device model, unit identifier, relevant software versions, application build and input equipment. Note the room, lighting and position of the task. A photograph of the setup can help the next facilitator reproduce it, provided it does not capture information the participant has not agreed to share. Keep the configuration beside the session record so a later change can be traced.

Prepare a known starting state. Charge the equipment, verify the application and test the reset procedure before the participant arrives. If a particular network or account is required, confirm it in advance. A connection problem may still be worth observing, but it should not accidentally consume a session intended to study a different part of the experience. Separate readiness checks from the participant’s actual task.

Use an introduction that does not teach the answer

Give each participant the same short explanation of the activity. Tell them what they are trying to accomplish, what they can do if they want to stop and how the facilitator will help. Avoid describing the exact interaction sequence unless that instruction is intentionally part of the product. Otherwise the trial may measure whether someone can follow a developer’s coaching rather than use the interface.

Ask the participant to explain the task back in their own words before starting. This can uncover a confusing brief without forcing the observer to infer understanding from later behavior. If the explanation reveals a problem, clarify the brief and record the change. Use that revised brief consistently for later sessions, and distinguish results collected before and after the revision.

Treat fitting as part of the experience

Record how a person finds a comfortable position, adjusts the frame and confirms that the display is visible. Note where help was needed. Do not silently correct the device and then count the session as independent setup. If the intended product includes a staff-assisted fitting, test that assistance as a documented step with its own instructions.

Allow participants to stop or remove the device whenever they need to. Ask about comfort at planned points without suggesting a preferred answer. Record the participant’s own description and the moment it occurred. A comment at the beginning of the session may have a different context from one after repeated interaction. Do not turn a small trial into a general claim about comfort for all users.

Run the task and keep help consistent

Use a task with a visible beginning and end. A participant might identify a component, follow a short sequence and confirm completion. Define what counts as completion before the trial. If the observer changes the standard during the session, the results become hard to compare. Keep exploratory comments in the record, but separate them from the agreed completion criterion.

Create a simple help ladder. The first prompt might repeat the task goal, the second might point to an available control and the third might demonstrate the action. Record which prompt was used and when. This keeps the facilitator from rescuing one participant immediately while allowing another to struggle for much longer. It also shows the team which part of the interface needs explanation.

Include a recovery step

A trial should test more than the ideal path. Choose one safe, ordinary interruption, such as pausing the application or returning to the start. Ask the participant to resume using the instructions the product provides. Do not introduce a surprising hazard or a failure the equipment is not prepared to handle. The recovery step should reflect a plausible part of the intended session.

Observe whether the application makes its state clear after the interruption. Can the participant tell where they are? Can the facilitator restart the session without the developer? Record both perspectives. In a shared training environment, the reset between participants may be as important to the practical offer as the learner’s interaction with the display.

Separate observation from interpretation

Write what happened before writing why you think it happened. “Participant tapped the control three times before asking for help” is an observation. “The control was too small” is an interpretation to investigate. Keeping those separate gives the designer more ways to respond. Size, placement, feedback and the task explanation might all be involved.

After the task, ask a few neutral questions: what felt clear, where they paused and what they expected at the difficult moment. Let the participant describe the experience before showing your theory. A short conversation can provide context for an observed hesitation, but it does not replace the observation. Preserve both in the record and label them clearly.

Check the technical assumptions on real equipment

If the application uses a browser interface, the WebXR Device API specification provides the primary description of its session and device model. For a native XR approach, consult the Khronos OpenXR resources. Use those references to identify what the application asks of the platform, then verify that behavior on the exact trial configuration.

A standards label does not tell you how your task feels to a participant. Keep the implementation record connected to the session record. When a build changes, repeat the affected task before comparing it with earlier results. That makes the trial a working part of product development: a small, repeatable way to decide what the team should improve next.