Decide which kind of use you want to observe
Before handing over your prototype, finish this sentence: “After this session, I need to decide whether…” For a storage case, the decision might concern whether a first-time user can open it and put away the contents without a demonstration. That is different from deciding whether the case is comfortable after training. Both questions can matter, but they need different starting conditions.
This guide is for small, exploratory sessions with an inert, low-risk physical prototype. It is not a procedure for testing hazardous equipment or certifying a product. Use a safe mockup when the real mechanism could expose someone to harm. Decide what is safe to handle before inviting participants; silence is never a reason to let an unsafe action continue.
GOV.UK’s moderated usability guidance recommends specific task goals, neutral instructions and mostly observing, while allowing occasional help. It concerns services. The physical-case example and intervention record below are our practical adaptation, not a validated research instrument.
Give a destination without supplying the route
Nielsen Norman Group’s task-scenario guidance explains why a task should be realistic and actionable without revealing the steps. Apply that distinction to what someone must accomplish with the object. Include enough context to make the goal clear; hiding the goal is not a useful test of the product.
| Prompt that gives away the operation | Goal-based replacement |
|---|---|
| Slide this catch sideways and lift the lid. | The pieces for your next activity are in this case. Take them out and leave them on the mat. |
| Press down until the two clips click. | You have finished the activity. Put the pieces away so the case is ready to store. |
| Use the handle on the short side. | Place the empty case on the marked shelf, if you feel comfortable doing so. |
These are sample prompts for a hypothetical case, not universal scripts. The shelf task requires a safe, accessible shelf and a case suitable for that action. A task should fit the participant’s actual routine. If the real product always comes with an instruction card, decide whether you are testing that complete package or the object alone, and record the choice.
Freeze the setup that could quietly teach the answer
Write a short setup card for each task. Include the prototype revision, the starting state, the items nearby and any information already given. For example: “Case C04; lid closed; catch facing participant; three wooden pieces inside; instruction card available to the right.” Photograph that arrangement for your own study record if appropriate.
An open lid, a pre-positioned thumb or an inventor’s casual demonstration can disclose the operation before the task begins. A participant who watched a previous session has a different starting condition too. Record prior exposure instead of calling every attempt a first use.
Rehearse the session with someone unfamiliar with the design. Ask them to explain the task goal before they touch the object. If the goal is unclear, revise the script. Keep the pilot separate from the main round, especially if it changes the setup. For a broader engineering record, use the prototype test-plan guide.
Agree on a way to help without hiding the help
The useful question is not whether the moderator spoke at all. It is whether that action supplied information needed to complete the task. The following labels are an original shorthand for your notes. Choose words that your team understands, and keep their definitions stable within a round.
| Code | What happened | How to record the result |
|---|---|---|
| O: observation | You watched without supplying new task information. | Record the participant’s action and the task outcome. |
| C: clarification | You restated the intended goal or corrected missing scenario information. | Save the exact wording; check whether it also revealed a method. |
| H: hint | You named a control, indicated a direction or suggested the next action. | End the unaided portion of the affected task and mark the continuation assisted. |
| D: demonstration | You operated or repositioned the object to show the method. | Label later attempts as following a demonstration. |
| R: reset | You repaired or reset a prototype limitation that interrupted the task. | Describe the limitation and what the reset revealed. |
| S: stop | You ended the attempt for safety, discomfort, withdrawal or the planned stop rule. | Record the reason and last observed state; do not turn it into a completed task. |
A code is not a verdict. Saying “the pieces need to go inside the case” may clarify a vague storage goal. Saying it while pointing to a concealed opening also provides a hint. Record words and gestures, then classify their effect. If you are unsure, keep the ambiguity visible rather than choosing the label that makes the result look better.
Use a short opening and a deliberate stopping rule
Digital.gov’s usability-test script includes permission to record, the option to stop and an explanation that the researcher may defer some questions. Its observer guidance also separates quiet observation from coaching. Those are useful boundaries when the inventor is in the room and wants to explain every feature.
For this case study, an opening could be: “I am checking this early design. You can pause or stop whenever you want. I will give you an activity and watch what happens. I may leave some questions until afterward. If you want help, tell me, and I will record any help I give.” Describe recording and who will see it separately, and obtain permission before recording.
Define a stop rule before the attempt: participant asks to stop, an agreed task limit is reached, the same unproductive action repeats without useful new information, or a safety concern appears. Set the limit for the task; there is no magic waiting time. At a routine stop, ask whether the participant wants to end the task or continue with help. Respect the choice.
Worked example: a case that opens after a hint
The following session is hypothetical. An inventor is testing whether a first-time user can retrieve wooden pieces from case C04. The latch must slide before the lid lifts. The participant has not seen a demonstration. An observer takes notes while the inventor reads the task.
| Point in session | Observed event | Record |
|---|---|---|
| Start | Participant hears the retrieval goal and picks up the closed case. | O; first-use attempt starts. |
| First attempt | Participant pulls upward on the lid, then turns the case over. | O; no opening observed. |
| Request for help | Participant asks which part moves. Inventor points at the catch and says it slides. | H; unaided retrieval ends incomplete. |
| Continuation | Participant slides the catch, opens the lid and removes the pieces. | Assisted completion; record the sequence after the hint. |
| Storage task | Lid will not seat because an internal prototype spacer has shifted. | R; pause and document the build fault before resetting. |
“The participant opened and closed the case successfully” would erase two different events. A defensible note is: “Retrieval was not completed before a directional hint. After that hint, the participant retrieved the pieces. Storage was interrupted by a displaced spacer, so closure performance was not resolved in this attempt.”
That record supports a focused next step: investigate how the opening action is communicated, repair the spacer and try the revised setup. It does not prove that everyone will struggle, that the latch needs a particular color, or that the participant cannot learn the product. The assisted sequence may reveal useful handling details even though it cannot answer the original first-use question.
If the same participant opens the case easily ten minutes later, retain that finding as a repeat attempt after instruction. Do not relabel it as a new first-time success. A fresh participant can help examine first-use discovery on the next revision; the returning participant can help examine repeat use. State which question each session answers.
Keep a copyable observation sheet
Use one sheet per participant and task. The fields below preserve the small details that often disappear in a general “it worked” summary. Use participant IDs rather than putting contact information into every research note.
- Decision: What design choice should this task inform?
- Participant context: Relevant task experience, prior exposure to this prototype and recruitment channel.
- Configuration: Object revision, starting state, contents, instructions and environment.
- Task wording: The exact prompt delivered, including any change made during the session.
- Event record: Time or sequence, visible action, participant words, moderator words or gestures, and intervention code.
- Unaided outcome: Completed, incomplete, stopped or indeterminate, with the reason.
- Assisted continuation: What help was given, what happened afterward and which question remains unanswered.
- Next decision: Keep, revise, investigate or retest, tied to the specific observation.
Where recording is permitted, reference a short timestamp rather than making memory do all the work. Where it is not, note the sequence promptly and distinguish a paraphrase from an exact quote. Do not reconstruct a confident-sounding quotation afterward. Collect only the personal information needed for the study and keep the notes within the agreed audience.
Turn the record into the next experiment
The WordPress observational-testing handbook separates reporting what happened from proposing a design fix. Keep that separation in your decision memo. The table below suggests what to investigate; it does not diagnose the cause from one observation.
| Pattern in the record | Useful next question |
|---|---|
| Participants cannot explain the goal before starting. | Does the scenario need clearer context? |
| The goal is understood, but the operation needs a hint. | What communicates the available action on the object or supplied instructions? |
| The operation is understood, but handling remains difficult. | Which grip, force, fit or sequence needs a separate investigation? |
| Moderator resets dominate the session. | Is the prototype stable enough to answer the intended question? |
| Completion occurs only after a demonstration. | Is training part of the intended product, and what should a trained-use test establish? |
Review the specific episodes before counting outcomes. Do not combine assisted and unaided completion into one unexplained success rate, or turn a small exploratory sample into a market claim. If two observers disagree about whether a clarification was a hint, return to the wording and event sequence. Preserve unresolved disagreement when the evidence cannot settle it.
Finish with one change and one question for the next round. For case C04, that could be a revised cue for the sliding motion, followed by a first-use observation with the same retrieval goal. Keep unrelated styling changes out of that comparison if they would obscure what you learned. The research-notes guide can help connect several sessions without losing contradictory evidence.