P2.06.2Commitment ladderdesign

The mechanism is easily weaponized as an escalation ladder

Aliases: escalation ladder · incremental consent · foot-in-the-door abuse

What it is

Turn the small-commitment effect into a staircase and you get an abuse structure: each step asks for a little more, every step looks reasonable on its own, and cumulatively the user never once said yes to the endpoint. Contact-list access hides marketing pushes underneath; a "quick sign-in" hides long-term data sharing; a seven-day trial hides auto-renewal. The endpoint is invisible at step one, and by the time it becomes visible the user is standing on rung five. This is the weaponized form of the persuasion structure: the problem is not the wording of any single step but the shape of the path.

Why it happens

Escalation works precisely because of two properties of self-image updating. First, it is incremental: self-perception follows behavior, and behavior happens step by step — each additional small consent nudges the self-image by one notch, and every notch holds; presented as a whole, the endpoint would diverge too far from the current self-image and be refused outright. Second, each step has local legitimacy: each is designed to connect only to the previous one ("since you've granted your photo, granting contacts helps you find friends"), so the user is guided to make local comparisons and never a full-path retrospective. Endpoint invisibility and incremental self-image updating are conditions for each other — and this is the line between it and legitimate onboarding: a good sequence's endpoint can be spoken aloud at step one; a bad ladder's endpoint has to wait until step three.

Where it stops holding

Longer is not automatically worse: a legitimate growth path (trial, configure, pay) and a manipulative ladder (grant, grant, charge) are often indistinguishable by step count. The distinguishing variable is endpoint foreseeability — the review question is "can the user see step five from step one," not "how many steps are there." Pre-existing category vigilance also changes the reading: graded requests from finance or health products get seen through earlier. And not every endpoint-revealed-late is manipulation — some disclosures genuinely can only appear at a specific step. That is negligent design rather than intentional structure, but the user's experience of it is the same.

Applying it

  • Make the commitment escalation path an explicit design-review artifact: list every commitment the user makes from first step to endpoint and ask — can the user at step 1 foresee step 5? If not, the structure crosses the line, by the same criteria that separate persuasion from manipulation (serving the user's own goals, truthful and complete information, easy reversal).
  • Preview the path's shape at the entrance: the trial page states the post-trial default renewal and price; the permission page lists what will be requested later — a ladder with a visible endpoint is a legitimate path.
  • Give every step an independently refusable option: step 3's permission is not pre-checked because step 2 was accepted.
  • To validate: show users who have never used the product only the step-1 screen and ask what it will want from them next. When the anticipated endpoint is significantly milder than the real one, the ladder is hiding its destination.

Related

  • Same group: P2.06.1 A small commitment raises acceptance of a later larger one · P2.06.3 Users must be able to exit a commitment at any time · P2.06.4 Public commitments are harder to revoke than private ones · P2.06.5 Investment the user paid for herself becomes a sunk cost · P2.06.6 Authored commitments bind harder than passively checked ones · P2.06.7 Consistency pressure makes users dismiss new counterevidence
  • Nearby: P2.03.2 Endowed initial progress strengthens completion intent · P2.08 Persuasion vs. manipulation · P2.11 Progress feedback and completion drive
  • Search terms: escalating commitment · foot-in-the-door · sludge

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/P2.06.2