Product and UX Content
Permission Request Copy Review
Explain why a product requests access, what it enables, how information is used, what happens if the user declines, and where permission can change.
Free editable Markdown · Content designers, privacy teams, and mobile product teams ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Permission facts
- Feature and user task
- [Enter]
- Platform permission
- [Exact name]
- Data or capability accessed
- [Enter]
- Purpose and necessity
- [Explain]
- Scope and duration
- [Enter]
- Processing/storage/sharing
- [Verified summary]
- Narrower alternative considered
- [Enter]
- Qualified owners
- [Product/privacy/security]
Request moment and copy
- Contextual trigger
- [User action]
- Why the purpose is clear now
- [Explain]
- Pre-prompt heading
- [Enter or None]
- Explanation
- [What access enables]
- Primary action
- [Enter]
- Decline or not-now action
- [Enter]
- Basic behavior after decline
- [State]
- Privacy destination
- [Verified route]
State map
- Full permission
- [Product behavior]
- Limited permission
- [Behavior where supported]
- Denied or dismissed
- [Behavior]
- Request again rule
- [Platform/policy]
- Enable later path
- [Settings/help]
- Revoked access
- [Detection and message]
- Unavailable or restricted
- [Alternative]
- Shared-device concern
- [Enter]
Review and monitoring
- Approvals and build
- [Enter]
- Trust and task signals
- [Denial, completion, complaint, incident]
- Update trigger
- [Platform, processing, feature, policy]
- Copy matches actual data processing and platform terminology.
- The request appears only at a relevant moment.
- Decline remains visible and non-punitive.
- The flow works with keyboard and screen reader.
- Long localization and system-prompt sequence were tested.
How to use this template
- Verify the permission's necessity, data scope, duration, product use, and narrower alternatives.
- Choose a contextual trigger and define full, limited, denied, revoked, and restricted behavior.
- Draft an accurate purpose explanation and consequences without coercion or unsupported privacy claims.
- Obtain privacy, security, product, accessibility, and platform review and test every state.
- Monitor task success and trust signals and reopen review when behavior or platform rules change.
Establish necessity, scope, and timing
Work with product, engineering, security, and privacy owners to identify the precise device or account permission, data accessed, duration, processing, and feature dependency. Ask whether a less intrusive method can provide the same outcome and whether access can be limited to selected files, approximate location, one session, or another narrower scope. Trigger the request when the user starts the relevant task, not automatically at launch. If the feature can work in a reduced form after denial, plan that path. The organization should be able to justify the request without relying on persuasive wording.
Prepare users without manipulating them
Where a contextual explanation is useful, state what the user chose, why access is needed, what the product will do, and what declining means. Use the platform's terminology accurately and ensure the pre-prompt does not falsely offer a choice that the system prompt ignores. Avoid shame, false urgency, confusing button symmetry, or vague claims like “improve your experience.” Link to current privacy information where appropriate without forcing readers to leave the task to understand the basic purpose. Do not promise that data never leaves the device unless qualified owners have verified that full claim.
Test decline, later change, and platform states
Map first request, allow, limited access, deny, dismiss, ask again where permitted, settings change, revoked access, unavailable hardware, and restricted account states. Confirm that the product detects current permission and does not repeatedly nag after denial. Explain how to enable access later with platform-appropriate guidance and an alternative task route where available. Test screen readers, focus, localization, shared devices, and sensitive previews. Monitor completion, denial, settings changes, support complaints, and privacy incidents rather than optimizing permission acceptance alone.
See the fields in context
Fictional example: photo selection
MomentLeaf and its mobile behavior are invented and do not describe a real permission flow.
- Task: A fictional user chooses a profile image.
- Scope: Offer the imaginary platform's selected-photo option before requesting full library access.
- Explanation: State that access is used to choose the image, not vaguely “for a better experience.”
- Decline: The user can continue with initials and choose a photo later.
- Revocation: The fictional settings page explains the current state without repeatedly reopening the system prompt.
Frequently asked questions
Should a pre-permission screen always be used?
No. Use one when it provides necessary context; an extra screen that merely pressures acceptance adds friction.
Can the app ask again after denial?
Follow platform behavior and policy. Explain a relevant later need without repeated coercive prompts.
How much data use should the prompt explain?
Give enough for an informed immediate choice and link to detailed current privacy information where appropriate.
Is acceptance rate the main success metric?
No. Measure whether users complete tasks with informed choice, including reduced-access paths, complaints, and incidents.