Incomplete branches interrupt the test
Aliases: dead-end prototype paths · branch coverage gap
What it is
If an interactive prototype implements only the main path, the flow stops the moment a participant steps into an unimplemented branch: “forgot password,” a second payment method, an empty state with no next screen. Incomplete branch coverage is not merely “one road not seen”; it is test interruption—the task cannot continue, later behaviors you actually needed vanish, and the facilitator starts narrating to save the session. Participants encode the break as the product being broken, which contaminates judgments of the main path.
Why it happens
Live use leaves the script. People probe the wrong entry, undo, refresh, and use secondary controls—the brittle parts of a state machine. A prototype that makes unimplemented branches look clickable without a sequel is a trap: the more discoverable the control, the earlier the interruption. Two bad repairs follow. One is the facilitator saying “here it would…,” turning unobserved behavior into narration. The other is dragging the person back to the happy path, losing not only that branch’s data but recovery-strategy data. Sparse coverage also biases who finishes: only people who happened not to take a side path contribute a complete task, so the sample is filtered toward script-followers.
Studying it
Before testing, list branches the tasks can reasonably enter: empty states, errors, cancel, back, secondary entries. In pilots, count interruption points—the first control and state where continuation dies. Coverage is not page count; it is whether illegal or secondary actions under key tasks still have a next state. In analysis, mark post-interruption behavior as unusable; do not count a facilitator-rescued completion as task success. Interruptions clustered on one control are a material defect, not a user error.
Where it stops holding
Exploratory prototypes need not cover every product branch, but they must cover those a test task can reasonably step into. Wizard of Oz or extra paper sheets can temporarily stand in for missing branches if the stand-in is logged as enacted, not as already built. For a guided demo that only allows scripted clicks, interruption is not a problem because it is not a test. Infinite branches (arbitrary search strings, arbitrary uploads) cannot be exhausted; use a finite representative set and write the uncovered input space into the limits.
Applying it
- Mark every clickable control as “has a next state / disabled / explicitly stubbed”; forbid a fourth option: clickable black hole.
- Write at least one error branch and one cancel branch per task, and dry-run until no facilitator speech is required.
- When interruption happens, log the control and time, end that task, and do not invent the next screen.
- Next round, patch the interrupting branches before adding visual detail on the main path.