How to be friendly to ask for mobile phone privileges

Last week it seemed as if nothing had happened, and it seemed impossible to talk about it. Is it not good? Friday and the youngest partners meet, the popular drink spicy, chat on the ground, is really happy.

When it comes to eating, after yesterday's haircut, I bought a fried chicken row at the store door, which is not a habit of change. Since the small barber changed the boss, cut hair more and more dissatisfied; Since the chicken restaurant changed the boss, the chicken row is also more and more unpalatable, and think of the past often called takeout, such as ramen restaurant noodles, the big plate of chicken ah, as well as the Northwest Museum of a variety of snacks or every summer will be addicted to the barbecue, all have no previous good.

Only one or two years of time, the good has become bad, this thing reminds me of "base", Danmotsle to Sheton study psychological history of the decay of the repeated emphasis ... I do not feel that I am overly sensitive in the details of my life, and feel that it is getting worse, and that it is getting worse.

Today, this article, in recent days to see in the transfer of another version of the translation, relatively condensed some, also quite good-looking; I learned mine, I did mine. The ideas and concrete methods elaborated in this paper are worthy of consideration and reference by all the designers. Surgery "may not be applicable to all products, but the" Tao "is all through a reason. Enter the translation below.

Cluster was the first iOS native app I ever designed, and the whole story has taught me a lot of things I haven't considered in the past web design. In the Web world, you usually just need to create pages for users to browse or use, and on iOS, in addition to guiding users to download and use your apps, you often have to ask them for various permissions, such as getting a location, or accessing contacts, cameras, photos, and so on.

In the process of designing cluster, we spend a lot of thoughts in many subtle and variable interactive links, in order to enhance the user's satisfaction and trust, and "How to ask permission from the user" is one of our focuses.

In this connection, our conclusions can be summed up as follows:

Do not ask the user for permission unless you currently need it.

The right to claim is to give the user a clear idea of what the benefits are after the authorization.

Importance of one-time successful access

For many applications, failure to gain access to the system means that the overall functionality and experience are compromised. For example, the application of the LBS class, if the user is rejected when requesting permission, then the application is basically equivalent to useless. In addition, if message push plays a subtle and important role in your application, allowing users to maintain habitual use, the failure to gain access may lead to loss of users.

Worse, clicking on "Not Allowed" is easy, and to undo this decision is not easy, users need at least the following five steps to open the authorization, and in the application is difficult for users to list these detailed steps, but also to help them directly into the relevant settings interface, users can only rely on their own to explore.

1. Back to System 2. Go to setup 3. Locate the "Privacy" setting item 4. Go to "photo" 5. Find the application that requires authorization and turn on permissions

In other words, if the user refuses the authorization for the first time and makes the application unusable, then the application itself is hardly likely to explain to the user how to fix the problem. So we have to do our best to ensure that users can click "OK" the first time they ask for access rights.

Two common design patterns

For access permission, we usually meet with two design patterns.

Request immediately upon initial loading (not recommended)

Everyone should have seen the pattern. You download a good application, first open, the interface immediately jumped out a hint: "Can we send you a message?" And then another hint: "Can we access your camera?" And then again, "Can we access your address Book?"

Unless users are familiar with or trust this product, they are more likely to click "Not allowed". This way and walk down the street and pull a guy and ask, "Can you date me?" Almost.

We used this approach in the first edition of the cluster, with fewer than 40% of users agreeing to authorize it.

Let users know the benefits (second best)

This is slightly better than a mindless claim to the user, but the effectiveness is still low.

As shown in the figure above, the heyday application is described in the prompt box for benefits that can be obtained after authorization. What's more, they ask the user for permission in the final step of the feature introduction, which allows the user to have a general idea of the functionality of the application before deciding whether or not to authorize it (assuming that the user does read the feature description), and thus more likely to pass the authorization.

Our cluster, after adopting this approach, has a one-time increase in the number of authorized users from 40% to 66%.

For some specific applications, if only in the above two ways to choose, so that users understand the benefits before deciding whether to authorize, than simple questions to be more effective.

Our exploration

We continue to explore the way that cluster to the user and find two ways to make the Permission dialog box appear as much as the user wants to say "good".

Pre-Licensing dialog box

The trick is to show the user the Pre-Licensing dialog box we created before the system pops up the licensing dialog.

As mentioned earlier, it is a bad situation for users to deny application authorization at the system level because it is cumbersome to reopen the authorization. However, if we ask beforehand before the system level authorization dialog, we still have a chance to let them say "yes" even if the user refuses.

For cluster's photo access authorization, 46% of those who clicked "disallowed" in the "Pre-Authorization" dialog box clicked "OK" in the next system-level authorization dialog.

The implementation is simpler than you think. You can add an additional iOS System dialog box, or design a custom interface to implement the "pre-authorization".

1.iOS system-style Pre-licensing dialog box

In an earlier version, we tried this way, which was to ask the user two times using the iOS System Style dialog box, and the first was our additional "Pre-licensing" dialog:

The Pre-Licensing dialog box (the one in the middle of the image above) pops up when you first need to access the photo, and the text is "This allows you to select photos from the album and add to the group," and two buttons are "now not authorized" and "grant". If the user clicks "Do not authorize now", the application does not take this behavior as the system level "deny authorization", but will ask in the future when needs to carry on two times the request, in which, we further explained to the user: "Cluster will only upload and share the photograph which you selected".

Users who have been in a rush to deny authorization for the first time still have the opportunity to understand and change their decisions, and according to statistics, only 3% of those who first clicked on "grant" clicked "not allowed" in the second interview.

While this dual-validation model may seem annoying, at least it's a relatively effective way for us to be able to get those who first denied the authorization. And according to our tests, none of the tested users showed hesitation or confusion when they saw the second dialog box.

2. Pre-authorized floating layer with guidance

In the link to ask the user for access to the Address book, we want to show the user more descriptive information to ensure that more users can authorize the application to access the Address Book. At this point the system dialog is not enough, and the flexibility is not enough, so we designed a floating layer:

When the user decides to invite friends, we will first through such a floating layer (as shown in the middle of the image above) to give the user two choices: first, from the system's address book to select Friends, one is to manually enter each other's contact. We let users know that the first approach is more convenient, but requires authorization, which enables users to know as much as possible about what is going to happen next. Those who choose to "Use the Address book" are largely aware of the situation and make authorization decisions, so it is more likely that the authorization will be confirmed directly in the next pop-up Request Permission dialog box.

Similar to the previous one, the dual-questioning pattern feels like a bit of a hassle, but in this case the user can be more informed and few people will click "Not allowed". And those who have chosen to enter the contact manual manually still have a fallback to choose to use the Address book again.

User-triggered Permission dialog box (most successful way)

The "Pre-licensing" model described above, in essence, is more about reducing the likelihood of unauthorized users; we think there is still room for optimization. By deconstructing the problem, we realized that the above approach did not change the "user does not expect to be asked for permission" reality, so we continue to explore and try a way to let the user intentionally trigger the authorization.

Access photos

In previous versions, the first step in creating new spaces in cluster was to add photos. This means that the user clicks "Create cluster" and immediately sees the prompt to get access to the photo. At the time, the statistics were that 67% of users would give authorization. We think there is still room for improvement in this figure.

We decided to postpone the uploading of the photos for a few steps, until the user first understood what the cluster concept was, how to play it, and then the desire to try it out on their own initiative, click on the camera icon, then "Select Photos", and then ask for permission.

This change increases the rate of access to photos from 67% to 89%.

Because at this time, the user has intended to upload photos, given the application to access the photos of the rights is a natural thing.

Access Address Book

We have asked ourselves, if users agree to use Access to their contacts, then what is the greatest benefit they can get? In the "Pre-licensing" mode that you have used, we allow users to manually enter the contact info of the friends they want to invite, and want to use this to motivate them to choose the "Address Book" approach, At the same time authorize applications to access the phone address book. This way of thinking is right, but the problem is, before the user to choose, they can not feel the manual mode of "pain", the corresponding will be difficult to see the benefits of authorized access to the Address book.

In the end, we decided to use the manual input mode by default in the addition of friends, and first let the user taste a little "hard", and let them feel how empty it is to add a contact without access to the Address book. When a user manually enters a contact name, he or she finds no query results and sees an option to "match the results from the iphone address Book." At this point, users will be more active to click on this option, then we will ask them to access the Address Book permissions.

This change allows access to the directory access rate reached 100%.

Push message

Cluster This app can help users create small private spaces within their circle of friends. Again, we ask ourselves, what is the maximum value that a push message can bring to the user? The answer is to let users know the dynamics of their friends in small spaces.

When the user creates a private space for the first time and invites some friends, we ask them a question that fits the logic of the day: "Do you want to be prompted by the message after they accept the invitation to join the space?" If the user chooses "Prompt me", the dialog box that requests the push information permission will be presented, and if they choose "No, thanks", we will skip this step.

The data here is the same as before: 100% of users choose to authorize after clicking "Prompt Me".

What we've learned: context matters

Of course, each application is different, but the truth is interlinked: To get the user's authorization right, you have to think carefully about when and how the user will really need to use the data from their mobile phone, and make sure that the user is expected to be asked in the correct context, and that the application can think what it wants.