Q5.07.3happy-path demo maskingdesignresearch

Demo paths conceal exception branches

Aliases: demo path masking · happy-path performance

What it is

To keep the room from going cold, a presenter clicks a rehearsed happy path: the account is valid, stock is exact, the network never fails, the user never cancels. Watchers therefore never see empty states, permission denials, partial failure, or back-button dead ends. Demo paths conceal exception branches not because the exceptions do not exist, but because the social goal of a demo (looks like it works) conflicts with the goal of evaluation (find where it does not). The concealed branches are often where live harm lives. This is not a test that interrupts because a branch was never built: the branch may already be drawn and simply never walked.

Why it happens

A demo is a performance. Performance rewards continuity, climax, and ending on time, and punishes pause and apology. Operators avoid controls they know will break character; narration recodes skipped steps as “similar here.” The audience’s memory keeps one story that goes through; exceptions are filed as “edges,” even when edges are most of real sessions. Confidence after a demo comes from narrative completeness, not from branch coverage. The higher the stakes—payment, permissions, deletion—the more likely the demo skips them, because they fail most readily on stage.

Studying it

When a demo is used as a source of evidence, run a separate “walk it wrong” pass: cancel, empty input, expired session, conflicting edits. Code which states the demo script covered, which it skipped, and whether skips were papered over in speech. People who have not seen the demo can run a hostile script on the same prototype; compare the problem sets. Video analysis should mark every “we’ll skip this.” If a review conclusion comes only from the demo, downgrade it to “the main path can be performed,” not “exceptions are handled.”

Where it stops holding

For aligning vision inside a team, or explaining direction to people who were not in the work, a happy-path demo is legitimate communication—so long as it does not pretend to be evaluation. Training materials should sometimes teach the main path. Public demos are time-bounded and cannot exhaust branches, but they should show failure and recovery at least once so the audience does not infer that the system cannot fail. Automated and pre-recorded videos lock the happy path harder than live clicks, because viewers cannot pull them off-script.

Applying it

  • Separate “communication demo” from “evaluation walkthrough”; the latter may not use the demo script.
  • For evaluation, prepare an exception list executed by someone other than the presenter; the presenter does not click for them.
  • Show decision-makers one failure-and-recovery, not only the tape that goes through.
  • Minutes must name states that were never walked; unwalked states are not verified.

Related

  • Same group: Q5.07.1 Over-polishing steers discussion toward visuals · Q5.07.2 A smooth prototype does not mean a smooth live context
  • Adjacent: Q5.03 Interactive prototypes · Q5.10 Prototype misleadingness and over-polishing
  • Search terms: happy-path demo masking · demo script · exception branch

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Q5.07.3