Have you ever opened an app for the first time and immediately got attacked by a string of pop-ups asking if the app can use your location, have access to your photos or send you notifications? This is something I see time and time again and unless the App Store page makes it really obvious as to why the app might be asking you these questions, then the average user is most likely going to say no or decline access.
According to Google, as many as 25% of app users open an app once and never return. This can be down to a number of things, from bugs and crashes to poor user experience. However, poor onboarding plays a massive part in whether users continue to use the app or delete it. One vital part of onboarding is how app providers ask users for permission to use or gain access to certain services or areas of the user’s device, and how they can make the app feel safe and secure to use.
When to pop the question?
There are several ways in which a provider can ask the user for permission, but designers and developers need to ask themselves, how important are the permissions? And how clear is it to the user as to why the app is asking for permissions?
Image by Google Material Design
Some apps ask for permissions upfront before the user has even had any interaction with the app beyond downloading it. One example would be Viber.
Before the user has even had a chance to read what is written on the welcome screen, he is welcomed by a native permissions request popup. Should he allow this? The user won’t necessarily know because the app hasn’t explained why it needs to send notifications. The user will be facing questions such as: if I allow push notifications, am I going to get spammed by the app? If I don’t allow them, does it affect my experience of the app?
It is likely that such obstacles have a negative effect on the user, as they don’t know what to do or whether to trust the app or not. Not a great first impression.
This doesn’t mean that you can’t ever ask the user upfront. It just means that the app should give the user a chance to digest what the app experience entails, what the app does and how it might work before asking permission to access services on the user’s device.
How to pop the question?
After assessing the clarity and importance of the app’s permissions, these are ways in which apps can ask permission from the users.
1. Educate up-front
If your app has an onboarding process to welcome the user, then why not utilise this moment to explain why the app might ask for permission?
Example by Rolo
2. Ask up-front
If it is extremely obvious to the user as to why the app would be asking for permission, then it’s ok to ask up-front. For example, if a user downloads a maps app then it’s pretty obvious as to why the app is asking the user to use their location.
Example by iOS Apple Maps
3. Ask in Context
This means that if the app doesn’t require the user’s permission until a certain part of the user journey, there is no point in asking the user until they get there. For example, I might be using a photography app. If I wanted to take a picture, this should be the point at which the app should ask me if it can access the camera. Then, if I have taken the picture and want to save it, it makes sense for the app to ask me once Ive tapped ‘save’ if it can access my photos. This means that the user understands why the app is asking for these permissions and the app doesn’t have to ask as soon as the user opens it for the first time.
Example by Camera+ (When tapping ‘save image’, the app asks for permission to access my photos)
4. Educate in Context
If an app’s feature is less dependent on the user’s permission in order to work, then you can educate the user as to why they should accept the permission for that feature when the need arises. For example, I might have lots of updates within a social network app and the app might ask if I want to be notified about these updates when any come through. I may also not want to receive notifications, but if the app can tell me why I would benefit from accepting the permissions, I’d be more inclined to accept.
Example by Vine
When trying to make the user aware that they might be missing out on a particular feature or set of features, it’s important not to be intrusive. The user has declined the permission for a reason, so don’t make them feel bad because of it. Instead, if a feature doesn’t work, then explain to the user why it doesn’t work, giving them a reason to accept the permission and a link to the device settings to accept the permissions. If the app doesn’t give the user a reason to accept the permissions, then the likelihood of the user accepting is slim. However, users should never be forced to accept in any case. Messaging should be subtle and not in the way of the user’s interaction with the rest of the app.
If a denied permission renders the app unusable, then the user must be prompted to accept the permission and turn it on in the device settings. Otherwise, the user will not be able to use the app or will just delete it as a result. Generally, apps shouldn’t rely on user permissions in order to work, but there are certain cases where they do. If the user has to accept the permissions for the app to function properly, then the app should make it very clear and very obvious that the app won’t work without the user accepting the request. The app should explain why it won’t work and what the user has to do to benefit from using the app. This can be done by providing a link to the device settings.
How to handle denied permissions
Even after making sure that apps are asking the user’s permissions in the best possible way, some users still decide to decline them. This shouldn’t be an excuse to make the user’s experience any worse as a result. Depending on the app, there are multiple ways to handle denied permissions and ways to get the user to realise why they should have accepted the request to begin with.
Firstly, it’s important to understand the difference between a critical and a non-critical permission.
A critical permission is something that will render the app almost useless without the user granting access to service or area of the device. For example, this could be a Sat-Nav app. If the user declines the permission for the app to use their location, then how is the app going to work correctly? The answer is that it won’t.
A non-critical permission is usually for features which enhance the user’s experience, but aren’t absolutely mandatory. For example, push notifications are important to some users and aren’t to others, such as with a news app that updates on breaking news via push notifications. It depends solely on whether the user feels they will benefit from them.
Users can react to permission requests in many different ways. The important thing to take away from this is that if your app requires the user’s permission to access certain parts of the user’s device, then you must think about whether it is obvious as to why it is asking for permission. When it comes to designing the user journey, it’s worth keeping this information in the back of your mind, but sometimes you don’t know how it should be implemented until the user journey has been completed. Just remember to always consider whether your app should educate up-front, ask up-front, educate in context or ask in context and it will make all the difference when it comes to the user experience and gaining the user’s confidence in using your app.