Participants fill in missing pieces and hide genuine confusion

What it is

When a prototype omits a control, copy, empty state, or next step, participants often do not stop to ask “is it gone?” They fill the gap: assume there is search, assume they can go back, assume an error will prompt. The task then looks complete; genuine confusion is covered by the fill-in. The record keeps smoothness, not “this should have been impassable.” Unlike a presenter skipping exceptions, here the participant completes the hole in the head. Unlike a test that interrupts on an unimplemented branch—if the control looks real, people invent the world behind it instead of stopping.

Why it happens

People keep a usable world model through incomplete perception; interface holes are packed with familiar software conventions. Politeness and a wish to “help the study succeed” strengthen filling: pointing at a gap feels like nitpicking. High visual especially invites fill-in, because a finished skin implies that omissions are temporary and guessable. Once filling happens, you cannot measure findability (can the entry be found) or recoverability (what if it goes wrong). A facilitator who nods at the fill-in writes fiction into the product. A later interview that asks “what do you think would happen here” still harvests fill-in, not the confusion of the moment.

Studying it

Have participants point at the control they mean to use before each action; if they cannot point, log an exposed gap rather than letting them “assume it’s there.” Contrast explicitly stubbed (dashed, disabled, spoken) with looks-clickable-but-isn’t. Code how often a next step was invented, and whether the invention equals the team’s unspoken assumption. Eye tracking or pointing can separate “saw the gap” from “did not see it and walked on.” Do not count success-after-filling as task success.

Where it stops holding

Structural exploration sometimes wants people to say what they assumed would be there; that is inspiration and should be tagged “invented,” not “completed.” Expert fill-in may be domain convention, worth recording as expectation. Children fill less and stop more. If the material is deliberately incomplete for co-design, the gap is method; if the material pretends to be complete, the gap is contamination. In remote tests the facilitator cannot see a hesitant hand, so fill-in is harder to catch live.

Applying it

• Make unimplemented places explicitly broken: disabled, dashed, “not built”; do not make a hotspot and have the facilitator paper over it.
• Mid-task, ask “what did the system just do when you pressed that,” to force fill-in out of the action.
• Log invented next steps as expectations, not as “the flow passed.”
• In playback, mark every moment they continued with no control; those are hidden confusions.

Related

• Same group: Q5.10.1 Mismatched visual and interaction fidelity pulls feedback onto the wrong dimension · Q5.10.2 Stakeholders easily read prototype finish as engineering finish · Q5.10.4 Polish spend should match the cost of the current question, not completeness
• Adjacent: Q5.07 How prototypes mislead · Q5.03 Interactive prototypes
• Search terms: participant gap filling · inferred affordance · hidden confusion