Can test flows and state transitions
Aliases: click-through state testing · flow and transition testing
What it is
An interactive prototype lets participants trigger transitions themselves rather than watch stills or wait for a facilitator to turn a page. What it can test is not “does it look good” but flow and state transition: whether an entry from A to B can be found, whether the same object is still recognizable across states, whether back and cancel return where they should. Relative to paper, choice, error, and recovery become observable events for the first time. Relative to a shipped system it still usually omits data integrity, permissions, and performance, so the test is of state logic, not reliability.
Why it happens
Flow knowledge lives in action: people build a model by trying entries, reading state changes, and choosing a next step. Clickable transitions turn those attempts from verbal guesses into trajectories. Inconsistent state machines—the same control sometimes submits and sometimes does nothing, an object named differently in list and detail—surface only when transitions actually happen. Stills can display every happy state at once; participants never collide with mutually exclusive states. An interactive prototype turns exclusion into a path that must be chosen, so missing transitions, wrong defaults, and dead ends appear as behavior rather than opinion.
Studying it
Drive walkthroughs with tasks and record entry finding, illegal actions, state misreads, back strategies, and whether recovery succeeds. A protocol can ask participants, after each transition, to say where the system now thinks they are. The coding unit is the transition event, not a page rating. A control condition is a non-clickable wireframe plus spoken narration, to see whether the same state errors still appear—if they appear only when clickable, the error depends on real transitions. Low-code click-throughs and front-end prototypes with real state both work; what matters is that the system, not the facilitator, maintains state.
Where it stops holding
Being able to test transitions is not being able to test the full task ecology. Unimplemented branches, accounts locked to a script, and “the demo user always has stock” make a flow look passable while live transitions still break. Cross-session state (drafts, login expiry, concurrent edits) is often absent. If the question is visual hierarchy or tone of copy, interactivity is not required. Performance, accessibility focus order, and live data edges need other materials; they cannot be inferred from “the flow completed.”
Applying it
- Draw a state table first: objects, legal states, triggers, illegal inputs; then decide which transitions must be clickable.
- Write tasks as “get the object from state X to state Y,” not “please look around.”
- After each session, mark impassable, backtracking, and lost transitions back onto the table; patch transitions before pixels.
- Check the recording: the transition the participant thought happened must equal the one the prototype actually performed.