Usability Testing¶
Empirical user test — instantiates Mental Model Mismatch Repair
Puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence.
Usability Testing, inside this archetype, is a controlled first-encounter test: it puts someone with no history of the product in front of the system, asks what they expect to happen before they touch anything, and then records what the system actually does. Its defining move is that it stages the mismatch prospectively and empirically — a real person, a real task, an observed outcome — and then stops at the raw gap. It does not explain why the model was wrong, and it does not prescribe a fix. Its entire product is a logged pair for each moment of action: what the user predicted, and what happened. That is what separates it from every other mechanism here: it manufactures the expected-versus-actual comparison from live behavior rather than reconstructing it, tracing it, or repairing it.
Example¶
A team ships a photo app with an Archive button on each picture. Support tickets hint that people are losing photos, but nobody can say why. A usability test settles it. Eight people who have never opened the app are each given one task — "get this photo out of your main feed" — and asked, before every tap, "what do you think this button will do?" Most point at Archive and say "delete it." They tap. The photo silently slides into a hidden album; nothing confirms or warns. Minutes later several of them are hunting for the photo they believe they deleted, confused that it is "gone but not gone." The test produces a plain record: predicted delete, actual move-to-hidden-album, at a named button, for six of eight testers. That record is the whole deliverable. Whether the fix is to rename the button, add a preview, or write a tooltip is a decision the test deliberately leaves to others.
How it works¶
The discipline that makes this an expected-versus-actual instrument, rather than a layout review, is the ordering:
- Recruit fresh users. People who already learned the system will not reveal the model a newcomer forms from the cues alone.
- Elicit the prediction before the action. Ask what will happen before the tap, so the original expectation is captured before hindsight rewrites it. This pre-reveal step is the mechanism's signature.
- Give a realistic task, then observe silently. No coaching, no hints — the point is to see which model the interface teaches.
- Log the divergence. Record predicted outcome, actual outcome, and the exact cue that produced the wrong prediction.
It is deliberately incurious about cause and remedy: naming the gap precisely, from live behavior, is the job.
Tuning parameters¶
- Sample size and freshness — more first-time testers widen coverage of the models people bring, but each session costs recruiting and moderation time; a handful of fresh users usually exposes the sharpest cue failures.
- Task realism — a tightly scripted task isolates one cue; an open goal ("do what you'd normally do") surfaces mismatches you didn't anticipate but is noisier.
- Pre-reveal depth — just the prediction, or the prediction plus the reasoning behind it. Capturing rationale tells you which cue misled them, at the cost of longer sessions.
- Moderation — moderated think-aloud yields rich verbal traces; unmoderated remote testing scales cheaply but loses the "why."
When it helps, and when it misleads¶
Its strength is that it catches a cue-induced wrong model before it ships, using real users instead of the team's imagination of them — and because it elicits the expectation before revealing the result, it captures the genuine prediction rather than a rationalized one.
Its failure mode is over-reading a small, artificial sample: a lab task is not the messy real context, and asking people to narrate their thinking can itself change what they do, so the think-aloud protocol[n1] must be read as evidence of a gap, not proof of its cause. The classic misuse is running the test to confirm a design the team already loves — leading the witness with hints until users "get it" — which converts a diagnostic into theater. The guarding discipline is to fix the tasks in advance, keep the users fresh and unled, and treat every result as a located gap to be handed onward, never as a verdict on the cause or the cure.
How it implements the components¶
expected_behavior— the pre-reveal question elicits the user's concrete prediction ("this deletes the photo") at the moment of action, before any outcome can distort it.actual_behavior— direct observation records what the system genuinely does under that task, giving the second half of the comparison as fact rather than recollection.
It surfaces the gap but does not explain it (mismatch_diagnosis) or weigh forensic records (evidence_check) — that is its nearest twin Incident Mental-Model Review, which reconstructs a past failure instead of staging a fresh one — and it neither authors nor transfer-tests a corrected model (model_revision_path, expectation_validation, Simulation-Based Correction).
Related¶
- Instantiates: Mental Model Mismatch Repair — Usability Testing supplies the observed expected-versus-actual evidence the rest of the repair acts on.
- Sibling mechanisms: Incident Mental-Model Review · User Journey Diagnostics · Interface Affordance Redesign · Documentation Revision · Simulation-Based Correction · Training Feedback Loop · Expectation Audit
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Usability Testing operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence.
Independent corroboration: The frozen evidence defines Usability Testing as 'Puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Both independent reviews identify human computer interaction as the historical home of the operation—Puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence.. The retained alternates document formative adjacent traditions; the reach field, not the origin field, carries later applicability.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence.
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence.
- Psychology — Psychology's perception, cognition, behavior, and risk-communication tradition contributes a separate formative lineage to the mechanism's usability testing logic.
Review resolution: Both blind reviewers independently place the defining operation—Puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence.—in human computer interaction. Their queued differences are secondary: alternate_origin_disagreement, origin_mode_disagreement, domain_reach_disagreement, encyclopedia_synthesis_disagreement. Reviewer A uniquely contributes no additional alternate; reviewer B uniquely contributes ['computer_science', 'engineering_design']. I preserve the full evidence-supported union of 3 alternate domain(s), without a numeric cap. origin_mode=single_lineage reflects the more specific lineage judgment in reviewer B's evidence, while domain_reach=universal separately records present-day portability. The affirmative encyclopedia-synthesis finding is preserved, and confidence=high uses the more conservative reviewer level.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The think-aloud protocol (Ericsson & Simon's protocol analysis) asks a user to verbalize their thoughts while performing a task. It is the standard way to surface an expectation before the outcome overwrites it — but verbalizing can subtly alter behavior, which is why the method is read as a signal of where a model breaks, not as a complete account of why. ↩