Y6.03.3Expert shortcut riskdesignresearch

Expert shortcuts can skip safety steps

Aliases: expert shortcut · procedural compression · efficiency-thoroughness trade-off

What it is

Expert shortcut risk describes a cognitive side effect of recognition-based judgment itself: once an expert recognizes the current situation as a familiar pattern and retrieves the plan that "usually works," that same recognition process also makes an implicit necessity judgment about each step of the plan — including interlocks, confirmation steps, and independent checks. If the recognition process judges that a given step "isn't needed this time," that step can be compressed away. This is not deliberate violation, and it is not a lapse in organizational safety culture. It is a cognitive cost built into expertise itself: the more skilled the operator, the more they tend to compress a standard step into the on-the-spot judgment "I know this one isn't needed" — a judgment that is usually correct within the range the operator's pattern library covers, and wrong only when the present situation happens to fall in the exception the library does not cover.

Why it happens

The root of this side effect traces back to a limitation in the verification step of recognition-primed decision making itself: the mental simulation an expert runs checks whether the overall plan can achieve the goal in the current situation, not whether every sub-step in that plan remains necessary. A good share of safety steps exist specifically to guard against conditions experience cannot judge — low-probability, normally invisible, or dependent on multiple independent causes coinciding. The value of such a step is precisely that it does not depend on the current operator's read of the current situation, while recognition-driven decision making is, by its whole mechanism, built on using that current read to decide what to execute. The two are structurally at odds: the sharper and more confident the recognition, the more the operator trusts they don't need that independent check; and how well the recognition system covers a situation is set by the patterns it has previously encountered — which is exactly what a low-frequency defensive step is there to guard against: the case with no precedent in the library.

Time pressure, peer habits, and a cumbersome step design all amplify this tendency, turning a one-off individual judgment into an unspoken routine across a crew.

Studying it

Cross-referencing the written steps of a standard procedure, logs of what was actually executed in the field, and post-hoc interviews can locate which steps are routinely merged or skipped and under what situational cues. A further step is to inject, in a simulation, a latent fault that the omitted step was designed to catch, and measure whether the shortcut leads to a miss and whether the miss is recoverable downstream — separating "the shortcut is usually fine" from "will the shortcut cause harm this time," rather than just tallying how often shortcuts occur.

Comparing omission rates when experts recognize a situation as typical versus atypical is a direct test of the mechanism itself: if it works as described, omission rates should drop noticeably when experts believe they are facing something unfamiliar; if the omission rate does not track perceived typicality, the omission is more likely a fixed habit than a recognition-driven judgment, and needs a different countermeasure.

Methodologically, deviations should not be predefined as misconduct — once participants sense they will be blamed, they hide the very information about why a shortcut exists and what it defends against that the research needs.

Where it stops holding

Not every compressed step deserves concern: duplicated checks, steps with no decision branch, and checks that a reliable automated signal has since replaced should be formally removed through a change process rather than left in place for experts to keep working around — that is a case of redundant step design, not a lapse in expert judgment. Whether a step is safety-critical should follow the consequence of its failure, whether that failure can be detected some other way, and whether other independent defenses exist — not the step's name or whether a procedure document labels it "safety."

Allowing a predefined abbreviated path in an emergency does not violate this boundary either — the difference is that path was reviewed and written explicitly into the emergency procedure, not improvised on the spot by an operator's recognition-based judgment.

Applying it

  • Identify steps that are frequently skipped and ask, for each one, what it does, what it actually costs in the field, and which class of expert-invisible failure it defends against — rather than simply calling for stricter discipline, which has limited effect on recognition-driven omission because the expert genuinely believes the step is unneeded in that moment.
  • For defensive steps that specifically guard against low-probability, hidden failures the expert's pattern library is structurally unable to cover, do not leave the decision to execute them to the operator's in-the-moment judgment. Design them as a form that cannot be skipped even when recognition judges it unnecessary — a physical interlock, a system-enforced second confirmation, or an independent second-person check — so execution does not depend on any single person's recognition at that moment.
  • For steps that are genuinely redundant and safe to drop, remove them through a formal change process to reduce burden, freeing the operator's attention for the steps that truly need independent verification.
  • How to check: in an exercise, deliberately set the recognition cues to point toward a "familiar pattern" while hiding a latent fault the pattern library does not cover, and observe whether the mandatory step actually blocks the expert's shortcut judgment — if the expert can still bypass it, the step's enforcement is not strong enough and is still functioning as a reminder rather than an interlock.

Related

  • Same group: Y6.03.1 Experts rely on pattern recognition rather than stepwise reasoning · Y6.03.2 Interfaces must support both strategies
  • Nearby: Y5.01 Operating procedures · Y7.03 Procedural deviation
  • Search terms: expert shortcut · procedural drift · efficiency-thoroughness trade-off

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y6.03.3