Discover how to boost app retention by mastering the art of permission requests. Learn strategic timing and context to engage users effectively.

Did you know that the average app loses 80% of its daily active users within the first 3 days post-install? Most people download an app, open it once, and delete it. This happens because users try out a lot of apps but decide which ones they want to delete within the first few days.

Are these user behaviors a result of poorly made apps? Not always, but the first interaction with the app plays a key role in creating an overall impression (either good or bad). When users open a new app, the last thing they want to see is multiple popups in a row asking for permissions:

• App Would Like to Access Your Locations
• App Would Like to Access Your Contacts
• App Would Like to Access Your Camera

This action has a very negative impact on user experience and usually leads to the app being discarded. The app needs to be able to keep in touch with users before asking for permission in order to retain engagement. This article will help you avoid common pitfalls in your permission request logic.

Build a strategy

When it comes to requesting permission, the worst thing an app can do is bombard users with permission requests without any notice or explanation. Asking your users for permission too early or for too many things at once is a common mistake. And yet, many apps still do that — right up front, as the first thing the user sees when opening the app. For example, Inbox by Gmail asks for permissions even before its onboarding tour, with no additional information or context.

When you send permission requests, you expect all users to accept them. To achieve this goal, you should build a permissions strategy. The strategy depends on the clarity and importance of the permission type you are requesting. Critical permissions should be requested up front, while secondary permissions may be requested in context.

When to ask the user

One of the biggest factors that determine whether users accept or deny your requests is when they occur.

A simple rule: Don’t ask a user for access until you really need it.

Ask up-front only for critical permissions

For many apps, not getting access to data can change the entire user experience. For example, if an app depends on an SMS service, declining access to the service makes the app useless. Luckily, users expect a messaging app to request SMS permissions, so requesting it up-front makes sense.

When more than one permission is needed for a feature to work, ask for those permissions and nothing extra.

Takeaway: Make sure the user clearly understands what the app does (based on the app’s description or previous familiar experience) and ask up-front only critical permissions that the user expects the app to request.

Ask for permissions in context

In most cases, if a new user experience begins with a set of permissions requests, you may be missing a critical opportunity to engage users. Apps should ask for permissions in context and communicate the value the access will provide. Once users are engaged, they will be more likely to accept your requests.

Takeaway: Users are more likely to grant permission if asked during a relevant task.

How to ask the user

Apps should clarify why each permission request is needed, either through the feature name or an explanation provided. Remember, if you want to get a Yes answer, you have to ask nicely.

A simple rule: Make sure it’s crystal clear for users what they’ll get in return for accepting the request.

Benefit explanation

Permissions that are less clear should provide education about what the permission involves. If your app has a walkthrough, use it to explain what your app does and why unexpected permissions will be requested.

Another well-done example is explaining permission in context. It helps gauge user interest and improve comprehension of the permission. Try to explain to a user the benefits they’ll receive by giving the app access.

Priming during the request

You can do this by providing a background image that explains the permission request. Foursquare primes users by providing a background image that explains why the app needs that particular permission.

“Primer” Message Before Actual Permission Request

You can only trigger the iOS default permission request once per feature. The worst possible thing is for a user to deny permission at the system level because reversing that decision in iOS is very complicated. In most cases, it’s better to “prime” your users to accept requests before the actual iOS permission request screen appears.

Cluster is a good example of priming before the request. Its flow includes a context-building screen, a primer, and finally, the permission request. Using pre-permissions dialogs almost eliminated the “Don’t Allow” problem for Cluster.

Ask in the context of action

User-triggered dialog works even better than a context-building screen because users are expecting the request and are more likely to allow permission when they want to use the feature it enables. Wait until a feature is invoked to request permission. When the user taps a feature like a camera in the Cluster app, that triggers the request for photo permissions.

How to deal with denied permissions

Because denying permissions may prevent a feature from working as intended, whenever permission is denied, it should be explained to the user.

A simple rule: You should provide feedback whenever permission is denied.

Critical permissions

If the app can no longer run because critical permission has been denied, explain why that permission must be allowed and offer a link to open Settings so the user can allow it.

Below is an example of Google Hangouts screen that explains that permission is needed for an app to function.

Conclusion

Clearly, every app is different, but you should think about when the user would need access to different parts of their phone and data and make sure they expect to be asked. Improving the user experience is an ongoing process. Don’t miss the opportunity to prepare your user to accept permissions! Test each case to see what works best for you.

About the Author

Nick Babich is a software developer and author of a blog dedicated to usability.