Permission Requests
Ask at the moment the permission is needed, say what it enables, and make declining survivable.
Definition
A permission request asks for access to a device capability or personal data. In most platforms the system prompt can be shown once, which makes the timing and the preceding explanation more important than the wording of the prompt itself.
Mixed evidence. Real research exists, but findings conflict, effect sizes are small, or the jump from the lab to interface design is contested.
On this plate
Reach for this when
- Requesting notifications, location, camera, microphone, contacts or health data.
- Grant rates are low and the feature depends on access.
Common mistakes
- Asking on first launch, before the reader knows what the product does.
- Firing the system prompt with no explanation, spending the single attempt.
- No functioning path for people who decline.
- Refusing to accept a decline, which turns a permission request into a deceptive pattern.
The same request, three ways
| Weak | Better | Best | Why the last one wins |
|---|---|---|---|
| Allow notifications? | Turn on notifications to stay updated | Get a message when your delivery is 10 minutes away? | Describes a specific benefit at a moment it is wanted. |
| Allow location | We use your location to improve the experience | Use your location to show stores near you? You can enter a postcode instead. | Names the alternative, so declining is not the end of the task. |
| Allow contacts access | Find your friends | Find people you know? We check contacts on your device and do not upload them. | Says what happens to the data, which is the actual concern. |
The sequence that works
- 1
Wait for intent
Ask when the reader takes an action that needs the permission, not on first launch.
- 2
Explain in your own interface first
A pre-prompt you control can be shown again. The system prompt usually cannot, so spend the explanation before it.
- 3
Trigger the system prompt only when likely to be granted
If the pre-prompt is declined, do not fire the system prompt. Keep the option available in settings.
- 4
Make the declined path work
Postcode entry instead of location, email instead of push. A feature that is unusable without the permission is a design failure, not a consent problem.
Asking at the right moment
- 1
Wait for the moment of need
Ask for location when the reader taps find nearby, not on first launch.
- 2
Explain before the system asks
One sentence saying what it enables and what happens if they decline. The system prompt cannot be customised, and you only get one.
- 3
Let them decline without penalty
Describe the path that still works. A product that breaks on refusal is asking for a revocation later.
- 4
Offer the route back
Anyone who declined and changes their mind needs to find the way to enable it, which is usually buried in system settings.
In practice
- i.
One attempt, spent on first launch
TimingA notification permission requested before the reader had used anything was declined by most people, permanently. The same request after a first successful action, with a sentence of context, is a different conversation.
Local chart
WRT·014 · Region III · Grid F1
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Principles behind this
The reasoning this solution is an application of.
- Default EffectBIAS·004 · Cognitive bias
- Framing EffectBIAS·003 · Cognitive bias
Commonly confused with
Close enough to be mixed up, different enough to matter.
- Deceptive PatternsPRIN·011 · Principle
A pre-prompt that informs is good practice. The same pattern that refuses to accept a decline is not.
Check your work
Review passes that test whether this was done properly.
- Design Ethics ChecklistCHK·010 · Checklist
Related concept
Connected closely enough to change how you apply this.
- OnboardingPAT·014 · Pattern
- MicrocopyWRT·001 · UX writing