Friction must exceed impulse yet stay below genuine need

What it is

Usage friction has a two-threshold window: below impulse strength, it fails to stop involuntary opening; above genuine-need strength, it blocks legitimate use and invites abandonment or bypass of the tool itself. The design goal is not "the more, the safer" but calibrating friction into the window above impulse and below need.

Why it happens

Impulse and need are motives with different time signatures. Impulse rises fast and decays fast — delay discounting means a few dozen seconds of waiting substantially lowers its strength; genuine need is stable and persistent, for which waiting is a minor cost. That time gap is the design space: time-based friction beats identity-based blocking. A door that takes thirty seconds to open effectively deters impulse (the door has not opened, and the thing already no longer feels worth doing) while remaining acceptable to genuine need (thirty seconds for a function truly wanted). Hard blocking distinguishes neither: the same wall that stops impulse also stops need, breeding bypass — the tool gets uninstalled, the escrowed password gets reclaimed — and the intervention collapses wholesale. The waiting window itself dulls with habituation (users learn to wait mindlessly), so it needs periodic recalibration; the general principle of repeated stimuli losing force is covered elsewhere, and only its conclusion is used here.

Where it stops holding

The two-threshold model presumes impulse and need are separable and differ in time. In strong-dependence states — impulses lasting hours, or use that can no longer be attributed — windowed friction fails; what is called for is professional help, not interface dosage. Friction must also not spill onto innocent paths: one door should not treat a work check and a feed session at the same height. The dosage window varies by person; any single global value necessarily lands outside the window for part of the user base, misfiring and under-blocking at once.

Applying it

Make friction time-based rather than identity-based: a pre-launch waiting screen (a few to a few dozen seconds, showing today's intent or a breathing cue), not an immediate password lock. Let the user adjust the wait, and support recalibration with data — surface "the share of recent launches abandoned after waiting": a rising abandonment rate says the window is catching impulse; abandonment near zero plus growing complaints signals habituation or misfires. Keep hard limits as a user-chosen last resort, off by default with no preset value. Verification: track the composition of the waiting queue — the healthy state is impulse-type openings abandoned at a rising rate while need-type openings complete undiminished; when the two indicators move in opposite directions, the window is misplaced.

Related

• Same group: P3.09.1 Time spent is not harm; purpose says more than volume · P3.09.2 Retrospective statistics have no power over use that already happened · P3.09.3 The effective intervention point is session start, not mid-session
• Adjacent: P3.04.2 Restriction tools are easily bypassed · A5.16 Habituation and prompt fatigue
• Search terms: friction · waiting screen · delay discounting