Choose permission request when the corrected flow asks in context, names the resource and feature, invokes the system prompt from a deliberate user action, handles grant and deny outcomes, and provides manual entry, manual fallback, or settings recovery.
Choose permission request when the corrected flow asks in context, names the resource and feature, invokes the system prompt from a deliberate user action, handles grant and deny outcomes, and provides manual entry, manual fallback, or settings recovery.
Practice the judgment: Imagine this situation: A first-run onboarding checklist asks for location, notifications, contacts, and photos before the user chooses any task. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Permission prompt with no context | Permission request | Location permission flow | Consent prompt | Permission denied state | Notification preferences |
|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Anti-pattern for platform permission prompts shown without a feature-triggered rationale, fallback, or recovery path | UI + UX - Contextual operating-system or browser permission request for device resources, powerful browser features, private user data, or local capabilities | UI + UX - Permission-gated current-location request and recovery flow | UI + UX - Specific opt-in decision for optional data use, participation, communication, sharing, or training | UI + UX - Authorization and access-boundary state | UI + UX - User-controlled rules for notification type, channel, frequency, timing, privacy, and exceptions |
| UI guidance | Replace a contextless permission prompt with a contextual feature gate that names the resource, task, timing, choices, fallback, denial outcome, and settings recovery before invoking the system prompt. | Render a permission request as a contextual feature gate that names the resource, user action, immediate benefit, system prompt timing, available choices, and fallback before invoking the OS or browser permission prompt. | Render location access as a task-scoped flow with purpose text, current permission state, requested precision, scope, native-prompt handoff, granted fix, denied recovery, manual fallback, stale-coordinate labels, and stop-sharing controls. | Render a consent prompt as a focused opt-in decision that names the requester, purpose, data involved, optionality, benefit, consequence of declining, withdrawal route, and consent record before the user chooses. | Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed. | Render notification preferences as a structured matrix or grouped settings surface that shows notification type, source, delivery channel, device, frequency, quiet-time rule, preview privacy, override, and current saved state. |
| UX guidance | Help the person reach a clear task outcome. | Use permission request when a feature needs operating-system or browser authorization for resources such as location, camera, microphone, photos, contacts, notifications, Bluetooth, clipboard, motion sensors, or other powerful features. | Use a location permission flow when current device coordinates materially reduce effort or improve a location-dependent task and users can understand why location is needed before the browser or OS prompt appears. | Use consent prompt when the product needs the user to knowingly agree to a specific optional data-processing purpose such as marketing, research participation, AI training, personalization, partner sharing, or sensitive-data use. | Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action. | Make consequences explicit: what stops, what still arrives, which devices and channels are affected, when changes apply, and which admin, OS, or workspace policies override the user's choice. |
| Good UI | A receipt scanner waits until the user taps Scan receipt, explains camera is needed only for the scan, then offers Scan with camera or Upload file. | A field service app asks for location only when the user taps Start route, explains that current location will verify arrival, then opens the system permission prompt and offers manual address entry if declined. | A route check-in says Use current location to confirm you are at Gate B, offers Use current location or Enter address, accepts approximate location for city-level help, and labels the returned fix as accurate to 42 m. | An AI writing tool asks whether the user wants workspace snippets used to improve future suggestions, shows included data types, keeps the default off, and records the consent version after opt-in. | A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account. | A notification preferences page groups Mentions, Assigned work, Followed threads, Security, Digest, and Marketing, with columns for In-app, Email, Push, Banner, and Digest frequency. |
| Bad UI | An app opens with location, contacts, photos, and notifications prompts before any feature is selected. | An app asks for location, contacts, photos, and notifications on first launch before the user knows why any resource is needed. | The home page triggers the browser location prompt before users choose any location-dependent action. | A modal says By continuing you agree to personalized offers and partner sharing, with a large Continue button and a small privacy policy link. | A denial page says Something went wrong and shows Retry even though the user lacks a required group. | A preference changes email only but the label implies all notifications stopped. |
| Good UX | A user declines camera access for receipt scanning, uploads an image instead, and can keep using expense entry. | A user denies precise location, chooses approximate location instead, and the app still shows nearby pickup points with lower accuracy. | A user taps Check in nearby, grants Allow once, sees the current fix and accuracy, confirms the place, and the app discards coordinates after check-in. | A user consents to a beta research study, sees what data will be reviewed, receives a saved confirmation, and later withdraws from the account privacy page with the same purpose label. | A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner. | A user keeps mentions and assigned-work banners on, moves repository watch updates to daily digest, mutes marketing email, and sees a preview of what will still notify them during quiet hours. |
| Bad UX | A user accepts a vague request believing it is for nearby search, but the app also enables background tracking. | A user denies microphone access and the app loops the same system prompt every time they tap anything in the support screen. | A user chooses delivery estimate and the app demands precise location even though postal code entry would work. | A user clicks Next to finish onboarding and unknowingly opts into marketing because the consent copy was bundled into the terms paragraph. | Every workspace control is disabled after one missing permission, including safe navigation and read-only tasks. | A user disables email for a noisy project and still receives duplicate push and desktop banners because those channels live in separate hidden settings. |
| Best fit | A product currently asks for device, browser, or app permissions before the relevant feature context exists. | A feature needs operating-system, browser, or device authorization to access location, camera, microphone, photos, contacts, notifications, Bluetooth, clipboard, motion sensors, storage access, or another powerful feature. | Current device coordinates materially improve a task such as nearby search, route start, check-in, delivery estimate, safety sharing, field work, or support diagnostics. | The product needs a user's active agreement for optional data use, marketing, research participation, personalization, partner sharing, AI training, or sensitive-data processing. | A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource. | Users receive enough notifications that they need control over type, channel, device, frequency, timing, or source. |
| Avoid when | The permission is requested after a clear feature-triggering action with resource-specific rationale and fallback; use permission request. | The decision is consent to optional data use rather than access to a device or browser resource. | Typed address, postal code, saved place, or map selection is simpler and less invasive. | The choice is only about non-essential cookies or device storage; use cookie banner. | The operation failed for network, server, validation, data, or timeout reasons after permission was granted. | The product has only a few low-volume notifications that can be handled by defaults and inline controls. |
| Required state | Cold-start prompt state before the user chooses a relevant feature. | Contextual request state tied to the user action that needs the resource. | Unsupported browser, blocked iframe, missing permissions policy, insecure context, or disabled location services state. | Pre-consent state with optional processing off and the core task still understandable. | Whole-object access denied state. | Default notification preferences state. |
| Accessibility burden | Expose the resource, task, and fallback as text before the system prompt rather than relying on platform icons or button order. | Use a labelled region or dialog title that names the resource and feature, such as Allow location for route check-in. | Label Use current location, Enter address, Retry, Open settings, Stop sharing, and Clear location controls visibly and programmatically. | Associate every checkbox or toggle with a complete purpose label and consequence description. | Move focus to the permission message when it replaces page content or blocks a workflow. | Group preferences with headings and fieldsets for event type, delivery channel, device, and frequency. |
| Common misuse | Requesting permissions on first launch because analytics show users may need the feature later. | Asking for multiple resources at launch before the user has attempted the relevant feature. | Prompting for location before users choose a task that needs it. | Treating continued use, scrolling, closing, or inactivity as consent. | Treating authorization denial as a generic retryable error. | Offering one master notification switch for a complex collaboration product. |