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
- O1.05.1Lengthy terms go unread in practice
- O1.05.2Blanket consent cannot express granular preferences
- O1.05.3Take-it-or-leave-it access is not a free choice
- O1.05.5Small mobile screens further constrain understandable consent
- O1.05.6A simplified summary can omit decisive exceptions
- O1.05.7Repeated requests produce habitual acceptance rather than understanding