Interlock's intermediate states need explicit feedback, or users will assume the system has frozen

What it is

Interlock constrains operations to happen in order, which means a later step gets rejected, or simply produces no response, until its precondition is met. If that moment of "no response" comes with no accompanying feedback explaining where things are stuck and what's still missing, a user has no way to tell it apart from a system failure — pressing something with no effect, tapping something that doesn't react, feels identical, from the user's side, to a freeze or a hang. No matter how sound the interlock's design is, it will read as a product defect.

Why it happens

People judge whether an action took effect by how quickly they get some perceivable result afterward, and that judgment happens almost instantly — within a very short delay, absence of feedback gets read as "nothing happened," not as "there must be an unmet precondition holding this back." Interlock's intermediate states are exactly the scenario most prone to this misreading: the action really was received by the system, it's just being withheld because a precondition isn't satisfied yet, and this "received but withheld" state is, without feedback, perceptually indistinguishable from "never received at all." Breaking that misreading requires feedback to arrive within the window a user expects a response, and it has to communicate two things clearly: that the action was blocked (not that it failed to register), and what condition still needs to be met before it can proceed.

Studying it

Evaluating whether interlock feedback is adequate can borrow methods from research on perceived feedback-delay thresholds: measure the interval between a user triggering an interlocked action and any perceivable feedback appearing, then check it against the known thresholds for how long a delay a person will still attribute directly to that action before starting to suspect nothing happened — and see whether the interlock's feedback falls inside the window where the correct attribution still holds. It's also useful to compare repeated-click and repeated-attempt counts between a design with clear intermediate-state feedback and one with silent blocking — a high repeat-attempt count signals that users read the silence as no response and are pressing harder or more often to "wake up" the system, rather than waiting for the condition to be met.

Where it stops holding

Interlock feedback solves the perceptual problem of a user mistaking the system for broken; it can't substitute for making the precondition itself more reasonable. If an interlock's precondition is extremely demanding and most users could never naturally satisfy it, even the clearest feedback only tells the user, clearly, that they're stuck — it doesn't make the flow usable. That situation calls for revisiting the higher-level question of whether the interlock's precondition was set up sensibly in the first place.

Applying it

For every node in a flow where interlock might reject an action, design immediate feedback timed close to the moment the action is attempted, and make sure its content covers at least two things: that the action can't happen right now, and what condition needs to be met before it can. Avoid handling the block with total silence or with a visual state indistinguishable from normal success. The feedback's timing needs to sit close to the moment the user presses the action, not appear after a long delay — delay itself will read as a second failure signal. Verification: log what users do right after being blocked at an interlock node. If a large share immediately repeat the same action two or more times, the feedback either wasn't noticed in time or wasn't clear enough, and its timing and placement need to be checked against where the user's attention actually is.

Related

• Same group: A10.14.1 forcing functions are implemented as lock-in, lockout, or interlock, each matching a different risk pattern · A10.14.3 a forcing function placed at the wrong step blocks legitimate operations instead of hazardous ones
• Nearby: I1.01 the just-noticeable simultaneity threshold · A10.02 mode errors
• Search terms: interlock feedback · perceived responsiveness · intermediate state