| UI or UX | UI + UX - Contextual operating-system or browser permission request for device resources, powerful browser features, private user data, or local capabilities | UI + UX - Specific opt-in decision for optional data use, participation, communication, sharing, or training | UI + UX - Durable permission administration for users, groups, roles, inherited access, effective access, and revocation | UI + UX - Guided workflow for regaining or routing around missing access | UI + UX - Authorization and access-boundary state | UI + UX - User-controlled rules for notification type, channel, frequency, timing, privacy, and exceptions |
| UI guidance | 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 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. | Render permission sharing as an access-management surface with the protected resource, current direct grants, inherited grants, groups, guests, anonymous or link access, role or permission level, effective access, pending changes, and revoke or save actions. | Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task. | 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 | 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 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 sharing when authorized owners or admins need to grant, change, audit, or revoke durable access to a space, site, repository, folder, project, board, dataset, environment, or sensitive object. | Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial. | 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 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. | 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 repository access page lists teams, outside collaborators, deploy keys, and direct users with Read, Triage, Write, Maintain, and Admin roles, showing that only Admin can manage access. | A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval. | 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 asks for location, contacts, photos, and notifications on first launch before the user knows why any resource is needed. | 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 permissions page shows only individual names and Remove buttons even though group membership and parent folder inheritance still grant access. | A blocked report only has Retry, so the user repeats the same denied request. | 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 denies precise location, chooses approximate location instead, and the app still shows nearby pickup points with lower accuracy. | 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 space admin removes Maya from a direct grant but sees she still has View through the Contractors group, so they remove the group grant or ask a site admin to update group membership. | A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report. | 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 microphone access and the app loops the same system prompt every time they tap anything in the support screen. | A user clicks Next to finish onboarding and unknowingly opts into marketing because the consent copy was bundled into the terms paragraph. | A repository admin removes a collaborator but forgets a deploy key with write access because the access page treated machine credentials as unrelated settings. | A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure. | 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 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. | The product needs a user's active agreement for optional data use, marketing, research participation, personalization, partner sharing, AI training, or sensitive-data processing. | Owners or admins need to manage durable access to spaces, sites, repositories, projects, folders, datasets, boards, environments, or sensitive objects. | A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue. | 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 decision is consent to optional data use rather than access to a device or browser resource. | The choice is only about non-essential cookies or device storage; use cookie banner. | The user is requesting access after denial rather than administering access. | The user is unauthenticated and the next step is sign-in or session extension. | 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 | Contextual request state tied to the user action that needs the resource. | Pre-consent state with optional processing off and the core task still understandable. | Default access list state with users, groups, guests, anonymous access, roles, and effective access. | Recovery start state with original blocked task and current account. | Whole-object access denied state. | Default notification preferences state. |
| Accessibility burden | Use a labelled region or dialog title that names the resource and feature, such as Allow location for route check-in. | Associate every checkbox or toggle with a complete purpose label and consequence description. | Use labelled tables or grids with column headers for principal, source, role, capability, status, and actions. | Move focus to the recovery heading when the workflow opens from a denial. | 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 | Asking for multiple resources at launch before the user has attempted the relevant feature. | Treating continued use, scrolling, closing, or inactivity as consent. | Showing only direct users while group or inherited access remains active. | Offering Retry for an unchanged authorization denial. | Treating authorization denial as a generic retryable error. | Offering one master notification switch for a complex collaboration product. |