Explain the purpose before the system dialog

What it is

A pre-permission prompt (permission priming) uses the app's own UI, before the system authorization dialog, to say which capability will be requested, which in-progress task it serves, and what happens on refusal. System dialogs have almost no copy. Once they appear, the only moves are Allow or Don't Allow, and Don't Allow is often remembered by the platform. The pre-prompt supplies the context the system sheet cannot, and offers a "Not now" that does not burn the system channel. This entry is about having a layer before the dialog. It is not about how specific the copy must be, and not about forbidding inflated claims of necessity.

Why it happens

The system permission alert is the OS's trusted surface. The app cannot change the title or the buttons; it can only squeeze in a short purpose string. At that layer people are doing binary risk management, not learning the product. The pre-prompt splits the decision into two beats: understand "what I am doing," then face the system's "allow or not." The first beat can still be "later" without calling the system API, so hesitation is not written down as a lasting denial. Without a pre-prompt, the system dialog is asked to educate, persuade, and authorize at once; when education fails, the authorization channel pays.

Studying it

Compare "call the system dialog immediately" with "show an in-app rationale first," and measure understanding separately from authorization.

Independent variables: presence of a pre-prompt, availability of "Not now," delay between the pre-prompt and the system dialog. Dependent variables: allow rate on the system dialog, accuracy of later purpose restatement, share choosing "Not now," abandon rate on the pre-prompt itself.

A pre-prompt can raise allow rate, or it can merely move refusals onto an app button. "Left on the pre-prompt" and "saw the system dialog and denied" have to be separated, or an apparent lift is just filtering out people who would have refused. In the lab the pre-prompt is read; in a real product a long one is dismissed as another launch ad.

Where it stops holding

If the permission is already on in system settings, the pre-prompt is extra friction—go straight into the feature. If the pre-prompt is a full-screen that cannot be skipped, it stops being an explanation and becomes a gate; "Not now" has to be a first-class control. Assistive-technology users depend on the system alert's standard roles; the pre-prompt needs its own heading and focus order, not only visual hierarchy.

Applying it

• Insert a screen or card before the system permission API: name the capability, the current task, and what still works on refusal; the primary button then fires the system dialog.
• Give "Not now" equal visibility with Continue, and guarantee it does not call the system API.
• Serve only the system dialog that is about to appear; do not stack other permissions on this layer.
• Verify with an offline walkthrough: after tapping "Not now," the system dialog must never have appeared. Then pause uninvolved people after the pre-prompt, before the system sheet, and ask what the system will request and what it is for. If they cannot state the purpose, the pre-prompt failed.

Related

• Within the group: H4.02.2 Name a concrete feature, not a generic purpose · H4.02.3 Do not inflate how necessary the permission is
• Adjacent: H4.01 Timing of Requests · O2.01 Permission-Prompt Information Design · O2.02 Explaining Data Use
• Search terms: pre-permission prompt · permission priming · purpose string