Cannot test timing and feedback
Aliases: paper cannot test feedback · timing gap on paper
What it is
Paper can simulate “what the next screen is” but cannot honestly simulate system timing and immediate feedback: how long from press to state change, whether a load can be cancelled, when an error appears, whether a gesture feels tracking. A human handing paper inserts delay, pause, and explanation in place of millisecond response. Paper can therefore answer structural questions and must not be treated as evidence about waiting, motion, voice turns, or live validation. Reading “nobody complained while waiting for the next sheet” as “acceptable wait” is a method overreach.
Why it happens
Timing and feedback are a closed loop between person and system, not a page sequence. People decide whether the system has died from delay, confirm a hit from micro-feedback, and decide whether to undo from when an error appears. Paper splits that loop into “facilitator parses intent → finds the next sheet → puts it down,” inserting human comprehension time and social pauses. Participants read those pauses as research procedure, not product behavior, so they do not abandon, mash, or change strategy the way they do in front of a spinner. Gestures, scroll inertia, and audio cues likewise depend on continuous time; discrete scraps cannot encode it. What is missing is not “high visual fidelity” but the time dimension itself.
Studying it
If the question includes waiting, feedback clarity, or live validation, paper is only a rehearsal of the task script; formal evidence needs timeable interactive material. A contrast design can run the same flow on paper and on a clickable version, coding abandonment, repeated clicks, error recovery, and “did it hear me” comments—behaviors that almost only appear on timeable material. Measure delay from action to visible change and whether feedback arrives inside an expected window, not merely whether the task eventually completes. Facilitator-handing delay belongs in the limitations; it is not an estimate of system delay.
Where it stops holding
Coarse sequential feedback—“after this tap you land on that page”—paper can test. Some service waits live in the organization rather than the interface (approval, logistics); paper then lacks interface timing, not business timing. A Wizard of Oz operator following a delay script can partly restore time, but that is no longer paper prototyping, and operator stability itself needs calibration. For reading and form-structure tasks that do not depend on millisecond feedback, this limit is not a veto.
Applying it
- Split the question list into “structure/copy” and “timing/feedback”; keep the latter out of the paper round.
- Treat waiting complaints on paper as hypotheses and retest them on clickable material.
- When you must test loading, validation, or gesture, use a minimal runnable prototype rather than adding the spoken gloss “it would spin here.”
- Report unobserved timing issues separately so readers do not take a structural pass for an experience pass.