O1.05.4Just-in-time consentdesignresearch

Request timing determines whether attention is available

Aliases: contextual consent · consent timing · in-context permission

What it is

Just-in-time consent places notice and choice when the relevant processing is about to occur and its purpose is intelligible from the current task. Identical copy at launch, before a consequential submission, or after first feature use meets different attention and understanding. The useful window is neither so early that context is absent nor so late that processing has begun; proximity to an arbitrary click is not enough.

Why it happens

People prioritize maintaining the active task goal. At first launch they may lack a model of an abstract feature, while payment, recovery, and urgent action consume resources needed for reading and comparison. A request near the relevant action, with permission to pause, links data, purpose, and benefit causally. If it blocks a path that cannot reasonably be interrupted, contextual relevance becomes leverage and people may click simply to restore progress.

Studying it

Holding copy and options constant, experiments can place the request at launch, feature entry, immediately before upload, or after task completion. Outcomes include reading behavior, purpose comprehension, choice stability, resumption cost, and later surprise. Dual-task measures or workload scales can estimate available resources but should be paired with task performance. Uptake is not the main criterion: a better-timed request may reduce acceptance while improving prediction and consistency.

Where it stops holding

Repeated prompting is unsuitable for every operation. Continuous sensing, background sync, and security monitoring may require one comprehensible activation moment plus persistent state cues and review. Notice delivered after processing cannot support prior choice. A high-pressure moment can be contextually relevant yet lack conditions for free decision; optional processing should then wait rather than exploiting urgency.

Applying it

  • Map each optional purpose to the first event at which its value is understandable but before data are generated or sent.
  • Avoid payment confirmation, failure recovery, and urgent-help steps; allow dismissal, deferral, and continuation of the original task.
  • Explain the start, stop, and background state of continuous processing instead of replacing visibility with repeated prompts.
  • Test identical copy at several triggers and ask participants to explain the purpose and predict flows; select using comprehension, resumption, and delayed regret rather than maximum uptake.

Related

  • Same group: O1.05.1 Lengthy terms go unread in practice · O1.05.2 Blanket consent cannot express granular preferences · O1.05.3 Take-it-or-leave-it access is not a free choice · O1.05.5 Small mobile screens further constrain understandable consent · O1.05.6 A simplified summary can omit decisive exceptions · O1.05.7 Repeated requests produce habitual acceptance rather than understanding
  • Adjacent: O2.01 Permission-prompt information design · O2.06 Consent-interface design and abuse
  • Search terms: just-in-time consent · consent timing · interruptibility

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O1.05.4