After a denial, the rest of the product must still work

What it is

After a permission is refused, features that do not need that capability must still complete. Location denied: search by typed address. Notifications denied: see updates when the app is open. Contacts denied: type a number. Locking the whole app, showing a blank wall, or forcing quit after one No turns an optional grant into an admission ticket. This entry is only about whether the product still goes through. It is not about how to explain the fallback, and not about using repeated dialogs to force an Allow.

Why it happens

A permission is a capability switch, not a product license. People refuse a sensor or a data set and assume the rest of the interface still honors the original contract. If refusal breaks the main path, the decision stops being "evaluate this capability" and becomes "keep this product at all," with pressure from sunk registration and content rather than from real necessity. Degradation localizes the dependency: no location, type an address; no camera, upload a file; no notifications, use an in-app inbox. When localization fails, refusal is no longer a privacy choice. It is a penalty.

Studying it

Run an authorized group and a denial group on the same product; the denial group has the target permission off at the system layer and then attempts the main task.

Independent variables: whether the refused permission is labeled core, whether denial locks navigation, whether an alternate input exists. Dependent variables: main-task completion, time to complete, reach of unrelated features, attribution of failure to "the app is broken" versus "I turned a permission off."

Lab participants told they must finish will go turn the permission on, so real abandonment is invisible. Remote tasks fit better. Do not treat grant rate as the only success metric—good degradation can leave denial-group completion high on the rest of the task; that is the goal, not a defect.

Where it stops holding

When the capability is a physical precondition of the current step (no camera, no live ID scan; no microphone, no call), that step cannot complete—but other regions of the app (history, settings, already-downloaded content) should still open. Security policies that forbid degrading without a grant (some enterprise containers, payment identity checks) should not offer a fake "refuse and continue." Unavailability because the device is offline, or because the permission has not been asked yet, is a different failure, not post-denial degradation.

Applying it

• Draw a dependency map for each permission: which screens, APIs, and background jobs actually read it. Every entry not on that map must remain tappable and completable after denial.
• Put an alternate on the main path: typed address, file upload, in-app message list. The alternate must not call the same permission API again.
• Do not clear the navigation stack, show a full-screen "unusable without this permission," or kick the person to login from the denial callback.
• Verify by turning the permission off in system settings, cold-starting, and tapping every top-level entry on the main path. Any unrelated entry that is dead is a defect. Then compare task completion: the denial group should not lag the authorized group on steps that do not use the capability.

Related

• Within the group: H4.03.2 The fallback has to be stated, not implied · H4.03.3 Repeated permission dialogs are a dark pattern
• Adjacent: H4.02 Purpose Explanation · H4.10 Visibility of Permission State · O1.05 The Usability Dilemma of Informed Consent · H6.09 Anonymous and Guest Mode
• Search terms: graceful degradation · permission denial · capability fallback