A smooth prototype does not mean a smooth live context

What it is

A session in which the task completed, nobody stuck, and satisfaction looked fine shows smoothness in that test context. Exporting it to live work, home, or a service window is prototype-to-context overgeneralization. The test setting strips parallel work, interruption, real stakes, messy data, and other people present. Prototype smoothness is a local observation, not a field prediction. Unlike a demo path that hides exceptions, even a non-demo script can still sit in an untrue setting.

Why it happens

Usability tests, to be repeatable, fix the task, the quiet room, the prepared account, and an atmosphere in which a facilitator can rescue. Those conditions make the flow’s inner logic visible and also remove the external load that makes flows fail: a phone call, wrong stock, a queue of customers, a dying battery. People explore more when nothing is at stake and become conservative or panicked when something is. The “smooth” a team sees is often smoothness with the load lifted off. Extrapolating while keeping the interface and dropping the contextual constraints is changing the phenomenon and keeping the conclusion.

Studying it

Write the target context’s load into the plan: interruptions, time pressure, shared devices, real cost of error. After a lab pass, retest with context: field observation, contextual interviews, or enactment under live load. Compare failure types on the same task in a quiet lab versus the field, not only success rates. The ecological-validity literature is blunt: problems found in the lab often remain true; “no problem” in the lab does not write “no problem” in the field. Reports should split “completable under a controlled task” from “completable in the target context.”

Where it stops holding

Early structural exploration can and should run under low load, or questions tangle. For tasks that almost only happen quiet, alone, at a desk, the extrapolation from lab smoothness is shorter. Expert users tested at their own desks already carry some live context, yet may still lack customers, peaks, and faults. Full field work sacrifices repeatability and control and needs another method, not lab standards forced onto it.

Applying it

• After every “it went smoothly,” name the context: task, place, whether stakes were real.
• List loads the lab removed, and schedule the ones most likely to reverse the conclusion into the next field round.
• Do not play only the smooth lab clip in review as evidence that “users are fine.”
• If the field shows failures the lab did not, the field wins; what you revise is the context assumption, not “the user was having a bad day.”

Related

• Same group: Q5.07.1 Over-polishing steers discussion toward visuals · Q5.07.3 Demo paths conceal exception branches
• Adjacent: Q5.03 Interactive prototypes · Q5.10 Prototype misleadingness and over-polishing
• Search terms: prototype-to-context overgeneralization · ecological validity · lab-smooth fallacy