Permission prompt with no context

Problem Context

• The prompt requests an operating-system, browser, or app-level permission for a device resource or powerful feature such as location, camera, microphone, photos, contacts, notifications, Bluetooth, clipboard, motion sensors, or storage access.
• The user has not yet chosen the feature that needs the resource, or the UI does not name the task and benefit before the system prompt appears.
• The product may use first-run onboarding, account creation, a splash screen, a fake setup checklist, or a broad modal to collect permission for speculative future use.
• Denial may be mishandled through repeat nags, blocked flows, settings dead ends, broad consent assumptions, resource mismatch, or loss of unrelated product access.

Selection Rules

• Flag this anti-pattern when a permission prompt appears before the user starts a resource-dependent feature or before the interface explains why the resource is needed now.
• Flag it when vague copy such as improve your experience, stay connected, or enable full functionality hides the resource, task, fallback, or denial outcome.
• Flag it when one action triggers a different permission than the visible feature implies, such as a scan action triggering contacts or a store finder triggering background location.
• Flag it when multiple permissions are requested together without separate feature-specific rationale and separate recovery paths.
• Use permission request for the corrected pattern when the product can ask in context, name the resource, invoke the system prompt deliberately, and handle grant or denial.
• Use location permission flow when the context problem is specifically current coordinates, precision, stale location, active tracking, stop sharing, or location fallback.
• Use consent prompt when the choice is optional data use rather than OS or browser resource access.
• Use permission denied state when the user is authenticated but lacks an account role, license, share, policy, or owner-granted authorization.
• Use notification preferences when the user is managing message topics, channels, digest, quiet hours, or subscription settings after OS-level access is handled.
• Use privacy settings when the user is reviewing durable account-level resource, data, or sharing controls rather than reacting to a just-in-time permission ask.

Required States

• Cold-start prompt state before the user chooses a relevant feature.
• Vague rationale state where the copy hides the resource, task, or fallback.
• Resource mismatch state where the system prompt asks for a different resource than the UI described.
• Bundled permissions state that asks for multiple resources as one broad setup step.
• Feature-triggered correction state showing the exact resource and task before the system prompt.
• Least-access alternative state with picker, upload, manual entry, approximate access, one-time access, or continue-without path.
• Deny without punishment state where unrelated work remains available.
• Previously denied or settings-required state with concise recovery instead of another prompt loop.
• Repeat nag and blocked-on-deny bad states.
• Mobile compact state where context, resource, primary choice, and fallback remain visible.

Interaction Contract

• The product must not invoke the platform prompt from page load, app launch, passive onboarding, timers, or unrelated navigation.
• The pre-prompt must name the resource, user-triggered feature, immediate benefit, denial outcome, and fallback before the system prompt is invoked.
• Each permission ask is scoped to one feature or clearly separated feature group; bundled prompts require separate explanation and separate choices.
• The requested resource must match the visible action and copy.
• Dismissing or declining the contextual explanation must not trigger the system prompt.
• Denying the permission must preserve unrelated navigation and eligible non-resource tasks.
• Previously denied, permanently denied, revoked, blocked, or limited states must show a settings route or lower-access fallback rather than loop the same prompt.
• The UI must distinguish permission request from consent, account authorization, notification topic settings, privacy settings, and approval gates.

Implementation Checklist

• Inventory every system permission and map it to the exact feature action that first needs the resource.
• Remove first-run, splash-screen, onboarding, sign-in, page-load, and unrelated-navigation permission triggers unless the feature itself is being started.
• Write resource-specific rationale copy that names the task, resource, benefit, choice, fallback, and settings path.
• Split bundled resource asks into separate feature-triggered requests or lower-access alternatives.
• Add denial, dismissal, previously denied, permanently denied, limited, revoked, unavailable, and settings-required branches.
• Provide fallback routes such as manual address, upload file, paste code, type contact, chat-only mode, continue without notifications, or open settings.
• Test cold start, feature-triggered ask, grant, deny, dismiss, repeat visit, permanent denial, resource mismatch, bundled permissions, compact layout, keyboard order, and status messaging.

Common Generated-UI Mistakes

• Requesting permissions on first launch because analytics show users may need the feature later.
• Asking for location, notifications, contacts, and photos as one setup checklist before explaining any task.
• Using vague benefit copy instead of naming the resource and feature.
• Triggering a system prompt from a custom modal close, page load, hover, timeout, or background script.
• Treating denial as a reason to block the whole product.
• Looping a custom prompt or browser prompt after denial.
• Requesting a more invasive permission than the feature needs.

Critique Questions

• What exact user action made this permission necessary now?
• Can the user understand the resource, task, benefit, fallback, and denial outcome before the system prompt appears?
• Is the requested resource the least powerful option that works for this task?
• What does the product do after deny, dismiss, limited access, revoked permission, or permanent denial?
• Can users complete the core task through a manual or lower-access route?
• Is this a device permission, optional data-use consent, account authorization, notification preference, privacy setting, or human approval decision?