Explain what refusing will cost

What it is

A permission consequence and recovery map connects platform authorization status and product request lifecycle separately to functional effects and available recovery. A platform can return denied, restricted, selected-content, one-time, while-in-use, or approximate states; “decide later” is usually a product lifecycle state in which the request was not shown or was deferred, while the underlying permission may remain not determined. Copy names the affected feature, what still works, when the choice can be revisited, and how to recover without turning loss into a threat.

Consequences must come from current authorization state and capability dependencies, not merely from the button someone clicked earlier. Settings, device policy, and platform state may change outside the product, so the interface has to reread the fact.

Why it happens

When copy covers only the benefit of allowing, the effect of denial or limited access often appears later as a failed task. People interpret an unresponsive control, missing items, or reduced precision as a defect because the causal permission state is invisible. Showing the specific loss, unaffected capability, and recovery path at decision time and again at the affected task prevents that silent failure.

Authorization is neither permanent nor strictly binary. Platforms may distinguish not determined, denied, restricted, one time, while in use, always, approximate or precise, and selected or full access. A user, administrator, or system can also change state outside the app. Consequence copy must consume the platform's current result and combine it with feature dependencies and the ability to request again or open settings. Treating “not now” as permanent denial, or limited access as total loss, produces the wrong remedy.

Studying it

Build transition tasks around first deferral, explicit denial, selected-content scope, reduced precision, one-time expiry, settings revocation, regrant, and administrative restriction. Ask participants to predict which capabilities stop and which remain, then recover when they encounter the feature later. Measure state comprehension, first correct route, recovery completion, settings round trips, repeated prompts, dead-end actions, help seeking, and perceived threat.

Run the study on a real platform or a faithful authorization state machine rather than swapping static text alone. Control feature dependency, settings-link availability, and eligibility to prompt again. Limited-scope cases should reveal whether the product falsely reports a total failure. Accessibility evaluation includes state-change announcement, focus return, refresh after coming back from settings, and non-color distinctions between available and unavailable functions.

Where it stops holding

Consequences should be accurate without becoming exhaustive. An obvious, low-risk direct dependency can be concise; background delivery, data-range, and precision effects that are hard to infer need explicit treatment. When access protects a sensitive resource, specificity must not confirm that a particular object exists. Recovery is also platform-bound: when another system prompt is unavailable, explain the settings route; when no stable deep link exists, give current, actionable steps instead of a dead control.

“Decide later” means the request does not complete now, not permanent refusal. Limited access should let supported tasks continue. A truly required capability can stop honestly, but unaffected surfaces should remain and the copy should not threaten. Revoking a device permission is also not identical to withdrawing legal consent; governance must still address existing data, retention, deletion, and later processing.

Applying it

• Maintain two orthogonal tables: platform authorization status records not_determined, denied, restricted, limited, one_time, while_in_use, full, and precision or data-range variants; product request lifecycle records not_shown, deferred, requested, completed, and related states. Combine both with capability dependencies to derive affected features, retained capability, prompt eligibility, and recovery, without treating deferred as a platform result.
• Before the request, state the direct effect of denial or limited scope. Do not nag after the choice. When the affected feature is invoked later, show current state, the missing capability, and one executable recovery route while preserving a back path or lower-capability mode.
• Reread system state at launch, foreground return, return from settings, and before the affected task. Update capability flags and copy atomically. Do not show an Allow button when the platform cannot prompt again; if deep linking is unavailable, provide settings steps appropriate to the supported platform version.
• End-to-end test every state and transition, including selected-content changes, one-time expiry, out-of-app revocation, and administrator restriction. Monitor silent failure, state misclassification, dead settings routes, repeated asks, and recovery completion. When status is unknown, use neutral language rather than claiming denial or absence.

Related

• Same group: T2.07.1 State the specific purpose, not a generic reason · T2.07.2 Never overstate necessity to win the grant
• Adjacent: T2.05.2 Empty states need an explicit next action · O1.10.2 Withdrawal should be no harder than giving consent
• Search terms: permission denial consequence · partial authorization · permission recovery