DDES9902 Chap.3 User Testing and Prototype Evidence
User Testing and Prototype Evidence
A prototype is valuable when it lets someone attempt a meaningful interaction and exposes a design assumption. Fidelity is chosen according to the question: paper or acted responses can test sequence and meaning, while timing, embodiment and motion safety need a functioning immersive build. Testing produces credible evidence when the report preserves task, version, instructions and observed behaviour.
Interpretation comes afterward, with alternative explanations and a linked revision. The process becomes iterative only when evidence changes the next version and that change is tested again. Begin with one uncertainty and convert it into an observable task. Instead of asking whether an interface is intuitive, ask whether a first-time participant can identify, select and place a virtual object without prompting.
Choose the cheapest prototype that can produce the behaviour under study; visual finish is unnecessary for sequence, but a comfort question needs representative motion and timing. Keep the protocol stable enough to compare participants and versions, recording the build, device, instructions, assistance and any deviation. Observation and interpretation belong in separate notes.
A hesitation, repeated reach or wrong turn is visible evidence; confusion, unfamiliarity or tracking failure are competing explanations that require more support. Include unsuccessful and contradictory cases rather than averaging them away. A revision record should connect the observed pattern to a specific change and predict what will differ on retest.
Evidence from a small convenience sample can guide iteration without establishing universal usability. By preserving scope and alternative explanations, the report shows genuine learning and makes the next test more informative than a sequence of polished demonstrations.
What this chapter covers
- 01
Prototype fidelity matched to the design uncertainty
- 02
Moderated tests, cognitive walkthroughs and less intrusive observation
- 03
Observable behaviour such as attempts, pauses, errors and recovery
- 04
Separation of observation from interpretation
- 05
Versioned design changes linked to user evidence
- 06
Retesting comparable tasks to evaluate an iteration
Worked example · free
Document a failed selection interaction
- +1Record the repeated reach and missing trigger action without labelling the users confused.
- +1Infer that grasping is invited while the trigger requirement is not discoverable, noting this is a diagnosis.
- +1Add hover feedback and a contextual controller hint after the first failed attempt.
- +1Repeat the same task and record whether selection occurs before the hint on the revised version.
Key terms
- Prototype
- A testable representation built to expose a design assumption through user interaction.
- Prototype fidelity
- The amount and type of representation needed to answer the current design question.
- Moderated testing
- A session in which a researcher observes and may guide a participant under a defined protocol.
- Cognitive walkthrough
- A structured inspection of task steps from the perspective of a first-time user.
- Behavioural metric
- An observable action expressed as a count, duration, sequence or success condition.
- Iteration record
- A versioned account linking a question, method, observation, interpretation, change and retest.
User Testing and Prototype Evidence FAQ
How polished should my first prototype be?
Only as polished as the current question requires. Use low fidelity for sequence, concept or label problems and higher fidelity for timing, embodiment, visual performance or safety. Extra detail can consume effort and introduce variables without making the evidence more useful.
What is the difference between observation and interpretation?
Observation describes what happened, such as a pause, wrong turn or repeated reach. Interpretation proposes why it happened, such as an unclear cue or incorrect mental model. Keeping them separate lets you preserve reliable evidence while revising a diagnosis when new information appears.
How do I show genuine iteration?
State the uncertainty, identify the tested version and method, report behaviour, explain the change that followed and test a comparable task again. Multiple screenshots do not prove iteration unless the report shows why the design moved from one version to the next.
Assessment move
Practise turning broad goals into observable questions. Replace “is the interface usable?” with a task such as “can a first-time user select and place the object without help?” Then choose the cheapest prototype that can produce that behaviour. Create a two-column note after every session: camera-visible observations on the left and interpretations on the right. Add an alternative explanation beneath each interpretation.
Before revising, state which evidence supports the change and which part of the experience will remain constant. Retest the same core behaviour so the comparison has meaning. For assessment preparation, build a version ledger early and label files consistently. Select a few strong evidence chains for the report rather than including every artefact.
Each chain should show uncertainty, method, observation, design response and residual limitation.
