Designing a Gate Someone Actually Uses
A Gate Is an Interruption You Are Asking Someone to Absorb
The security case for gating irreversible actions is well established and is treated properly as its own discipline. The engineering problem that remains is that a gate is an interruption into somebody's working day, and interruptions are absorbed by whatever mechanism costs the person least — which, for a stream of approvals that have almost always been fine, is approving without reading. That is not a training failure. It is the predictable behaviour of a reasonable person facing a queue with a low base rate of problems, and any design that depends on sustained vigilance against a low base rate is depending on something people do not do. Design for the person who is busy, has seen forty of these this week, and is being asked for one more. Everything else in this lesson follows from taking that seriously rather than treating it as a discipline problem.
- Approval fatigue is rational behaviour under a low base rate, not carelessness
- A design that depends on sustained vigilance depends on something people do not do
- The consequential question is what the person does on the fortieth request, not the first
- Security places the gate; this is about whether the placement produces a real decision
Volume, Timing and the Shape of the Queue
Three engineering levers change engagement more than any wording. Volume: every gate you remove makes the remaining ones more likely to be read, so the gate list should be short by design and reviewed as a set rather than grown one incident at a time. Timing: a synchronous gate mid-run holds a process and pressures the approver toward speed, whereas an asynchronous gate — the run checkpoints and resumes when a decision arrives — removes the time pressure entirely and is worth the state-management work it requires. Grouping: batching related approvals into one decision with shared context is better than five separate notifications, provided the batch is genuinely one decision and not five smuggled into a single click. Measure decision latency and approval rate per gate; a gate approved almost always, in a couple of seconds, is a gate that is not functioning whatever the policy says.
- Fewer gates makes the remaining ones more likely to be genuinely read
- Asynchronous gates with a checkpointed run remove the time pressure to approve fast
- Batch related decisions, but only where it is honestly one decision
- Track approval rate and decision latency per gate as engagement metrics
Defaults, Expiry and the Cost of Saying No
What happens when nobody responds is a design decision that reveals whether the gate is real. Timing out into proceeding converts the gate into a delay, and this happens more often than anyone admits because a blocked queue is visible and a skipped approval is not. The correct default is to abandon or hold, with the state preserved so the decision can still be made later. Equally important and usually neglected: make rejection cheap and useful. If declining means the run dies and the requester starts over, approvers feel the cost of saying no and will say yes more often. Offer decline with a reason that returns to the agent as an observation, and offer modify-and-approve where the action has parameters, so the common case of nearly right does not force a binary between accepting something wrong and discarding the work.
- Timing out into proceed turns the gate into a delay; default to abandon or hold
- Preserve state on timeout so the decision remains available later
- Make rejection cheap — if no is expensive, approvers will say yes
- Offer decline-with-reason and modify-then-approve for the nearly-right case
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.