interaction design
Forcing function
What is a forcing function?
A forcing function is a design constraint that stops you proceeding until you've done the right thing, making an error physically or logically impossible rather than merely discouraged. The cash machine that won't release your money until you take your card back, or the form that won't submit until a required field is filled, both force the correct action.
Also known as: forcing function, forcing functions
Prefer to watch?
Watch the recap 0:59
The demo
A cash machine. Withdraw your money two ways - one that lets you forget your card, and one that makes forgetting impossible. Run each and see which design protects you.
What this demo shows (text version)
A cash machine is shown two ways. Without a forcing function it dispenses the cash first and returns your card afterward - so once you have the money, it's easy to grab it and walk away, leaving your card behind (a real, common error). With a forcing function the machine returns your card before it releases any cash, so you literally cannot complete the withdrawal without first taking your card - the mistake becomes impossible.
That's a forcing function: a constraint that blocks progress until the right action is taken, making an error impossible rather than merely warning against it. It's the strongest form of error prevention, best reserved for consequential, irreversible or easy-to-forget actions, because the friction it adds is justified only where a slip would really cost.
A forcing function prevents an error by blocking progress until a condition is met - the strongest form of error prevention, because it removes the option to do the wrong thing rather than just warning against it. ATMs that return your card before the cash, microwaves that stop when you open the door, "type DELETE to confirm" gates, and submit buttons disabled until a form is valid are all forcing functions. Use them for consequential, irreversible or easy-to-forget actions, where a slip would be costly. The cost is friction, so apply them where the stakes justify it - and don't force trivial steps, or you just annoy people.
Without the forcing function you sailed past the critical step and paid for it later; with it, you simply couldn't proceed until you'd done the right thing - the mistake became impossible. That's the power of a forcing function: it doesn't warn, it blocks. Reserve it for the moments where forgetting or erring really matters, because the same friction that protects people can also irritate them if overused.
Forcing functions are the strongest constraint-based error prevention: they make the wrong path unavailable until the right one is taken. Norman describes several flavours - interlocks (the sequence must happen in order, like a microwave stopping when the door opens), lock-ins (preventing you leaving prematurely, like "you have unsaved changes"), and lockouts (preventing entry into a dangerous state). Each removes an error rather than catching it afterward.
Everyday examples: ATMs that dispense the card before the cash (so you don't walk away without it), cars that won't start unless in park, "are you sure? type DELETE to confirm" gates for destructive actions, required fields that block submission, and two-step confirmations for irreversible operations. They're appropriate where an error is costly, irreversible, or easy to make through inattention.
The trade-off is friction: a forcing function deliberately interrupts the flow, so it must be reserved for actions where the cost of a mistake justifies the cost of the interruption. Forcing trivial confirmations everywhere causes habituation (people click through on autopilot) and irritation. Used judiciously - on the genuinely consequential steps - forcing functions are the most reliable safeguard there is.