| 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 | Do not trigger camera, microphone, location, photos, contacts, notification, Bluetooth, clipboard, motion, or storage permission prompts on launch, sign-in, onboarding, or unrelated navigation before the feature need is visible. | 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 | Treat permission prompts without context as an anti-pattern because users cannot make an informed choice when the resource, benefit, immediate task, and consequence of denial are unclear. | 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. | Use notification preferences when users need to reduce noise without missing important mentions, assignments, security notices, incidents, reminders, or followed-object updates. |
| 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. | A research signup screen asks whether the user consents to being contacted for follow-up interviews, names the research team, shows what contact data is used, offers Yes and No thanks buttons, and links to withdrawal. | 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 single Notifications off switch disables email, push, badges, and mention banners without saying whether security alerts or approvals still arrive. |
| Good UX | A user declines camera access for receipt scanning, uploads an image instead, and can keep using expense entry. | A user taps Scan receipt, sees why camera access is needed for scanning, grants access, scans the receipt, and can later revoke camera access from settings without losing account access. | 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 declines partner sharing and can still complete checkout; the service records no partner-sharing consent and shows how to change the choice later. | 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 denies a first-launch permission prompt because it appears before the app explains the feature, then cannot find how to turn the feature on later. | 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. | The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account. | 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 user is not signed in and the next step is authentication rather than authorization. | 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. | Provide manual address, saved place, search, or assisted alternatives for users who cannot or do not want to share device location. | Use a labelled region or dialog title that names the consent purpose, not a vague privacy heading. | Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone. | 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. |