Priming users to grant mobile apps permission

Priming users to grant mobile apps permission

Gaining access to your mobile app users' data requires a delicate balance of timing and education. As we’ve seen, mobile app users are increasingly hesitant to grant apps permission to access their personal information. 

For those who work in the mobile space, that's a chicken-or-egg type of problem. Users might need to grant access to their data before your app will work fully and correctly, but asking them to grant that permission requires trust. And that trust takes time to build... but users will abandon apps that take too long to set up. Tricky stuff.

One school of thought advocates sending permission requests out as soon as users open the app—requests that, to some, will feel premature.

Here’s the thing: You wouldn’t propose marriage on the first date (we hope). Why would you badger users with the big ask before demonstrating some kind of value?  

Permission requests can be a big pill to swallow—but that’s why priming users first helps. It can also lower abandonment rates while increasing trust. 

The most popular apps use a few simple tricks to increase users’ trust and reduce abandonment. And because many of them require small tweaks, you can quickly implement these 3 strategies within your own app.

Request device access only when needed

Timing is everything. Just as you wouldn't expect a stranger to give you access to their wallet, relying on users to grant permissions before they trust your app is destined to fail. Avoid asking for access until you truly need it.

The one exception? If permission is critical to the functionality of the app. Navigation app Waze, for example, asks the user for location access immediately after the app is opened for the first time.

Since this ask is critical (it's impossible to offer accurate directions if you don't know where the user is) and contextual (the user knows Waze is a navigation app before installation), people are more likely to grant the request for location access.

Secondary permissions are those that aren't critical to the app's functionality. It's best to tie those permission requests to a particular task or feature, only asking for access once the feature is used for the first time. Users are much more likely to grant the request when actively trying to use a particular feature.

Another example is the language learning app Babbel. They don’t ask for microphone access during the initial onboarding lesson. They let users see the value of the app first. 

But once users reach the point in regular lessons where speaking practice is an option, they're asked to grant the app access to their mic. This request works because it's contextual, users are motivated, and they have the chance to decline it if they prefer.

Knowing when to ask users for access is not enough. You have to also let them know the benefits of granting more permissions.

Educate users and explain the benefits of granting permissions

Your onboarding sequence is an excellent opportunity to educate users and demonstrate the benefits of your app. You should approach permission priming in the same way. Each time your app requests a new permission, it's important to make clear to the user why the request is being made and what benefits the user will get in return.

In their onboarding videos, personal training app Zova explains how push notifications will unlock daily health and fitness videos and nutrition tips, helping users get more value from the app.

Be specific about why you're asking—make sure users know how granting permissions will benefit them. For example, Starbucks uses a modal to explain how turning on location services allows users to quickly find nearby stores and access regional menus.

By providing context and education to prime users before requesting access, both Zova and Starbucks cam turn big asks into thoughtful requests.

Now, even though you're asking at the right time and in the right way, there's always a chance the user will still say no. Let's look at what to do when a user denies your permission request.

Make it easy for users to deny a permission request—and change their minds

Making permissions optional goes a long way toward building trust and putting users at ease. Some users will inevitably deny a permission request, and it's essential you handle those denials effectively.

Whenever a user denies a permission request, describe the effect their refusal will have and the benefits they'll forgo by denying permission. If the app can't run because the user has denied a critical permission, explain this and prompt users to re-enable the permission.

Scooter rental app Bird, for example, cannot run without access to the users' location—if a user denies location access, the app displays a warning explaining the problem, and prompts users to allow location access before letting them continue.

Sometimes, denying even secondary permissions can alter the entire user experience. 

Meditation app Headspace relies on push notifications to help users form beneficial meditation habits. But instead of forcing users to enable notifications, Headspace reminds users of the benefits they're missing out on at the end of each meditation session and allows them to opt into notifications and reminders.

The lesson here: don’t overlook permissions optimization as a way to truly enhance the user experience and add value. Be sure to provide feedback whenever a user denies a permission request, and make it as easy as possible to get back on track.

Respect your users

At the end of the day, we spend a lot of time with our favorite apps. Taking the time to respect your users’ boundaries can go a long way toward building the type of good will that turns regular users into raving fans.

As you build out your onboarding process, think about how you can work permission priming into your mobile app. Make sure you're never surprising users with unexpected requests, educate them on the benefits those permissions will unlock, and make it easy to change their minds. Treat your users with respect—they'll reward you for it in the end.