Design a useful app even when permissions are declined

Make camera, location and notification requests specific, optional where possible and recoverable.

A phone offering an alternative input beside a paper guide.

A permission prompt is a decision point in the customer journey. Some people decline because they do not understand the request; others have a considered preference. The app should remain coherent in either case. List the permissions each feature needs, explain the immediate benefit and decide what the customer can still accomplish without granting access.

Map permissions to visible features

A parcel collection app may use the camera to scan a code, location to suggest a branch and notifications to announce arrival. These are separate benefits. Asking for all three at first launch makes it harder to judge any one request. Android's location documentation distinguishes types of access, while its notification guidance explains that user choices affect availability. Use current platform behaviour as a constraint, then design requests near the action that needs them. Avoid broad wording such as Improve your experience when a precise explanation is available.

Provide a practical alternative

A customer who declines camera access may still be able to type a collection code. A branch finder may accept a suburb instead of device location. Make these alternatives visible enough that refusal does not resemble a broken app. Where a capability is essential, explain the limitation and offer a route to adjust settings without repeatedly interrupting unrelated work. Do not claim that permission is mandatory for the entire service when it is needed only for a convenience feature. This distinction helps customers make an informed choice and reduces avoidable support calls.

Test changes after the first decision

Permission state can change outside the app. Test a person granting access, later withdrawing it in settings and returning to an unfinished task. The screen should detect the current situation and preserve appropriate progress. Consider limited access as well as a simple yes or no, such as approximate location. Keep any guidance about settings accurate for supported devices and avoid hard-coding a long sequence that may change. During review, ask whether a user can complete the core service with the minimum necessary access. Unused permissions should prompt a product discussion rather than remain by habit.

  • Which visible feature benefits from each permission requested by the app?
  • What alternative lets a customer continue after declining optional access?
  • Does the experience remain understandable if permission changes between visits?
  • Can the business explain why every requested capability is still necessary?

Further reading

Discuss your software project with 110s

Related Insight