Mobile UX Design: How to Request Permissions from Users Correctly

Original author: Nick Babich
  • Transfer
image

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 leave and which to delete.

Does this user behavior mean that these applications are poorly designed? Not always. But the first experience of interacting 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-ups asking for permission:

● access to location data

● access to contacts

● access to the camera

This negatively affects the experience of interaction and causes the desire to remove the application. To deter a user, the application must begin to interact with them before they have to request permissions. This article will show you the right way and help you 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 comment or explanation. Common errors are either too early or too frequent requests. And yet, many applications do just that: they give the user a permission request right away as soon as he opens the application. For example, Inbox from Gmail asks for permission even before acquaintance with the service, without any special need, without giving any additional information.

image
Image: Inbox by Gmail

By submitting a permission request, you expect all users to give a positive response. To achieve this, you need a query strategy. It depends on the transparency and relevance of your request. Important permissions should be requested immediately; minor permissions can be requested while working with the application.

image
Scheme for compiling permission requests. Image: Material Design

When to request permission


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

Simple rule: Do not request access when this is not really necessary.

At the initial stages, request only important permissions.

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

image
Image: Google Hangouts

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

Conclusion: Make it clear to the user what the application is doing (from the description or previous similar experience) and request at the initial stages only important permissions expected for the user.

Request permission during work


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

image
Image: thinkwithgoogle

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

How to request permission The

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

A simple rule: Make it clear to the user what they will get if they give permission.

Additional explanations

About permissions, the purpose of which is not obvious, you need to tell more. If your application has a walkthrough, use it to explain what the application does and why you need certain permissions.

image
Image: Material Design

Another good way is to explain the purpose of permissions during the course of your work. This helps maintain user interest and helps them understand the purpose of the request. Try to explain to the user that he will give this permission.

image
Image: Google Maps

Prepare the user for the 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 app needs permission.

image
Image: Foursquare

“Warning” message before a direct request

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

Cluster is a good example of an application using this technique. Cluster respects the following sequence: context submission, warning, and finally the permission request itself. Using pre-dialogs has virtually solved the failure problem for Cluster.

image
Alert is a dialog box system that gives an idea of ​​an upcoming request. Image: Cluster

Ask at the time of action.

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

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

What to do with permission denials A permission

denial can interfere with the function's normal operation. This should be brought to the attention of 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 due to a denial of critical permission, explain why it is needed and give a link to the settings where the user can give consent.

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

image
Image: Google Hangouts

Conclusion


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

Also popular now: