A10.03.4Sequential interlock against skippingdesign

Sequential interlocks that force step order to prevent skipping

Aliases: order-forcing interlock · forced sequencing

What it is

For the specific flavor of omission where a required step gets skipped, the most direct countermeasure is a physical interlock that locks the step order: the entry point for the next step simply isn't available until the previous one is complete, so there's nowhere for the user to skip to. This differs from relying on a prompt or a warning telling the user "don't forget this step" — an interlock doesn't depend on the user remembering or noticing anything; it builds the ordering constraint into the interaction itself, so skipping isn't structurally possible.

Why it happens

An interlock only works when the two steps it forces really do have a genuine precedence dependency — the later step logically or physically needs the earlier one done first to proceed correctly, such as needing to select a target object before an action on it can execute. If no such dependency exists between the two steps and they're only sequenced that way out of habit, forcing an interlock doesn't reduce omission — it just turns operations the user could otherwise do in parallel, or in their own order, into a longer, more rigid queue. Omission doesn't drop; waiting and frustration go up instead.

Where it stops holding

Interlocks are effective only on step pairs with a genuine dependency; applying one to steps without that dependency suppresses an otherwise legitimate order of operations — experienced users accustomed to filling things in a different order find themselves forced into an unfamiliar sequence, with completion time stretched but no matching safety gain. Interlocks also solve only the "skipped step" cause of omission, not the case where a trailing step gets eclipsed by the sense that the main goal is already done, or where an interruption breaks memory for resuming a sequence — in those cases the step was never a skip candidate to begin with; the failure is in monitoring or memory retrieval, which an interlock cannot lock down.

Applying it

Start with a dependency analysis and apply an interlock only to step pairs with a genuine precedence relationship: disable or hide the next step's entry control until the system confirms the prior step's completion event has fired. Don't make interlocking the default applied to every step — reserve it for places where the dependency is clear and the consequence of skipping is significant. To verify: before shipping, log how often and where users actually attempt to skip steps in the current flow, and add interlocks only at those points; after shipping, compare completion time and skip-attempt count on the same task set — skip attempts should drop to near zero without dragging out completion time for steps that had no real dependency.

Related

  • Same group: A10.03.1 Omission errors: a required step never happens · A10.03.2 Commission errors: a step happens but comes out wrong · A10.03.3 Post-completion error: a trailing step is left after the main goal is reached · A10.03.5 Explicit confirmation of critical-step completion · A10.03.6 Interruption makes resumption prone to dropped steps
  • Nearby: A10.14 Forcing functions and interlocks · A10.06 Error-proofing design
  • Search terms: interlock · forcing function · sequential lockout

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/A10.03.4