O2.06.5Consent interruption timingdesignresearch

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

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O2.06.5