When a consent prompt interrupts the task affects whether users respond hastily
Aliases: consent prompt timing · in-flow consent · privacy interruption timing
What it is
Consent interruption timing concerns whether an interface couples optional consent to avoidable progress loss or asymmetric recovery after a person has invested effort, faces a deadline, or fears losing state. A request during payment, navigation, or creation is not coercive merely because of its location. The question is whether refusal or deferral unnecessarily destroys unrelated input, prior progress, or baseline capability that does not depend on the requested data.
Why it happens
A modal occupies visual and action channels and forces a switch from the person's goal to the organization's decision. Sunk effort, timeout loss, and fear of lost input compress reading and comparison, while immediate continuation after acceptance rewards acquiescence. Relevance and pressure are separate: a request can concern the current feature yet remain coercive because refusal damages progress.
Studying it
Randomize or counterbalance prior investment, preservation of unrelated state after refusal, and whether the decision can be deferred while holding copy, options, functional dependency, and participant composition comparable. Measure comprehension, click latency, state loss, resumption cost, abandonment, and delayed choice stability. A change in acceptance is only a clue; it supports a pressure account when it tracks loss or forced immediacy under controlled conditions and alternative content or capability explanations are excluded.
Where it stops holding
Urgent security, irreversible publication, or required confirmation may warrant interruption while preserving unrelated task state. If a feature genuinely depends on the requested data, refusal may reasonably leave that feature unavailable; the interface should retain baseline capabilities that do not depend on the authorization and explain the dependency accurately. The target is avoidable loss and asymmetric recovery, not a screen location by itself.
Applying it
- Mark high-loss points such as pre-payment, post-form, live navigation, and unsaved creation, then test whether refusal or deferral causes avoidable additional loss.
- Permit lossless refusal or deferral where data dependency allows; keep unrelated work available through a nonmodal request when feasible.
- Autosave unrelated form, scroll, media, and navigation state; explain any feature boundary that genuinely follows from missing authorization.
- Use randomized or counterbalanced tasks to separate location, loss, and deferral, evaluating comprehension and recovery rather than inferring coercion from acceptance alone.
Related
- Same group: O2.06.1 Path asymmetry · O2.06.2 Preselected consent · O2.06.3 Repeated prompting · O2.06.4 Visual weight · O2.06.6 Order and default focus · O2.06.7 Visual parity
- Adjacent: O1.05.4 Timing of consent · O2.01.3 Permission-request trigger timing
- Search terms:
consent interruption timing·task interruption cost·resumption lag
Cards in the same group
- O2.06.1A longer refusal path than acceptance is manipulation
- O2.06.2Preselection treats no response as consent and conflicts with informed consent
- O2.06.3Repeated prompting until acceptance is a dark pattern
- O2.06.4Much greater visual weight for acceptance than refusal is design inducement
- O2.06.6Option order and default focus systematically affect choice outcomes
- O2.06.7A good consent interface gives acceptance and refusal complete visual parity