Mobile UX-Design: How to correctly request user permissions

Did you know that the average application loses 80% of its daily active users within 3 days after installation? In most cases, people install the application, open it and delete it. Users try many applications, and within a few days they decide which ones to keep and which ones to remove.

Does this user behavior mean that these applications are poorly developed? Not always. But the first experience of interaction with the application plays a key role in creating the impression as a whole (good or bad). The last thing users want to see when opening a new application is an endless series of pop-up windows requesting permissions:
')
● access to location data

● access to contacts

● access to the camera

This adversely affects the interaction experience and causes the desire to delete the application. To retain the user, the application must begin to interact with them before they have to ask for permissions. This article will point you to the correct path and help avoid common mistakes in organizing permission requests.

Develop a strategy

The worst thing you can do for your application is to bombard the user with permission requests without any comments or explanations. Common mistakes are both too early and too frequent requests. And yet, many applications do just that: they ask the user for permission to go straight away as soon as he opens the application. For example, the Inbox from Gmail requests permission even before it becomes familiar with the service, without much need, without giving any additional information.


Image: Inbox from Gmail

By submitting a request for permission, you expect all users to respond positively. To achieve this goal, you need a query strategy. It depends on the transparency and relevance of your request. Important permissions should be requested immediately, minor ones can be requested during the work with the application.


Permissions Requests Composition Scheme. Image: Material Design

When to request permission

One of the key factors determining the user's response to a request is when it appears.

Simple rule: Do not request access when there is no real need.

At the initial stages, request only important permissions.

For many applications, access to any data is vital. For example, if an application depends on an SMS service, it will be useless without access to this service. Fortunately, the user expects that the messenger will need permission to access the SMS, so you can request it immediately.


Image: Google Hangouts

If functions require more than one permission, request only those permissions and nothing else.

Conclusion: Make it so that the user understands what the application does (from the description or previous similar experience) and request only important permissions expected for the user at the initial stages.

Ask for permissions during work

In most cases, when a user experience begins with a series of permission requests, you risk losing the opportunity to engage the user. It is better for applications to request permissions during the work and explain what they will give. When users are already involved, they are more likely to give permission.


Image: thinkwithgoogle

Conclusion: The user is more likely to give permission if he is requested during the execution of a specific task.

How to request permission

The application must, at each request, explain why it needs this or that permission, either in the name of the function or in the comment. Remember: if you want a positive answer, you need to ask politely.

Simple rule: Make it so clear to the user what he will get if he gives permission.

Additional explanations

About permissions, the purpose of which is not obvious, you need to tell more. If your application has a step-by-step guide, use it to explain what the application does and why you need these or other permissions.


Image: Material Design

Another good way is to explain the assignment of permits during work. This allows you to maintain the interest of the user and helps him understand the purpose of the request. Try to explain to the user what the permission will give him.


Image: Google Maps

Prepare user for request

This can be done by adding a background image that will explain the permission request. Foursquare prepares users with a background image that explains why the application needs permission.


Image: Foursquare

“Warning” message before direct request

On iOS, you can request a default permission only once for each function. The worst thing that can happen is if your user refuses permission at the system level, because changing this solution on iOS is very difficult. It is best to “warn” the user about the upcoming request before it appears on the screen.

Cluster is a good example of an application using this technique. Cluster observes the following sequence: context submission, warning, and finally the request for permission itself. The use of preliminary dialogs has practically solved the problem of failures for Cluster.


“Warning” is a system of dialog boxes giving an idea of ​​the upcoming request. Image: Cluster

Request at the time of action

Dialogue with the user works even better than the context feed. It makes the request expected by the user and thus prompts him to give consent in order to ensure the operation of the corresponding function. Wait for the feature to activate to request permission. When a user wants to use a feature, for example, a camera in Cluster, its activation will be followed by a request for access to photos.


Ask users for permission only when they try to use the feature. Image: Cluster

What to do with permission denials

Denial of permission may interfere with the normal operation of the function. This needs to be communicated to the user when he gives a refusal.

A simple rule: in case of refusal of permission, you should always give feedback.

Critical Permissions

If the application cannot function because of a failure in the critical resolution, explain why it is needed, and give a link to the settings where the user can agree.

Below you see an example of the Google Hangouts screen, explaining that permission is required for the application to work.


Image: Google Hangouts

Conclusion

All applications are different, but we always need to think at what point the user will need access to different parts of the phone and data, and make the request be expected. Improving user experience is endless. Do not miss the opportunity to prepare the user so that he gave permission! Always test to find out what suits you best.