Cluster is the first native mobile app I’ve designed, and the experience has taught me a lot about things to consider that aren’t necessarily a concern on the web. When creating a web app, you’re just building a page a user visits. But when creating a native experience, you’re not only asking them to download something but also probably asking them to give you access to their location or personal data. It’s a completely different relationship.
Because of this dynamic, we’ve spent significant time at Cluster on small interactions that increase users’ comfort and trust. One area we’ve focused on in particular is how we ask iOS users for access to things on their phone.
Our biggest takeaway: don’t ask a user for access until you really need it, and make sure it’s crystal clear what they will get in return.
Getting Access the First Time is Critical
For many apps, not getting access to a phone’s sensors or data can change the entire user experience. For example, if an app depends on where the user is standing, declining access to location could render the app useless. More subtly, if push notifications play a critical role in getting your user to form a habit of using your app, declined access could lead to you losing them forever.
Making it all worse is that when a user taps “Don’t Allow”, there is no easy way for them to reverse that decision. It takes 5 steps to grant access later, and there’s no way to help a user navigate to the right screen besides actually listing the steps out.
In other words, if the user denies access, the app won’t work properly — and it’s nearly impossible to explain how to fix it. This means developers need to do everything they can to get users to tap “Allow”.
The Two Most Common Approaches
There are two common methods we’ve seen apps use when asking permission.
The Initial Blitzkrieg (Not Recommended)
We’ve all seen it. You open the app for the first time and *POP* “Can we send you push notifications?” then POP “Can we access your camera?” Then “Can we access your contacts?”
Unless the user is already familiar with the app — WhatsApp probably doesn’t suffer from this problem, for example— they’re probably going to tap “Don’t Allow.” It’s like walking up to someone on the street and demanding they go on a date with you.
The first version of Cluster took this approach, and only about 30-40% of users accepted.
The Benefit Explanation (Sub-Optimal)
This method is significantly better than the Initial Blitzkrieg, but still not as effective as it could be.
Here, HeyDay tries to explain to a user the benefits they’ll receive by giving the app access. Then, when the user is educated enough, the app pops the question. Using this type of dynamic worked for us.
When educating the user about Cluster before asking for notifications access, acceptance increased from less than 40% to 66%.
The dynamics of certain apps may force them to only be able to use the above methods. If so, explaining to a user why access is important is so much better than just asking them for it.
How Cluster Approaches this Problem
Over time, we’ve learned to ask our users for permission when, and only when, we absolutely need it and we think the user can clearly relate how this access will benefit them.
We’ve re-engineered Cluster using two methods to only show the system permissions dialog once a user has told us that they intend to say “Allow”.
We’ve had a lot of success asking for permissions using our own UI before popping the iOS dialogs.
As stated above, the worst possible thing is for a user to deny permission at the system level, because reversing that decision in iOS is very complicated. But if we ask them before the system does and they say no, we still have the opportunity to ask them again in the future when they are more likely to say yes.
For photos alone, 46% of people who denied access in a pre-permissions dialog ended up granting access when asked at a better time later.
This is simpler than you think. You can design your own dialogs, or use an additional iOS dialog for this.
Double System-Style Dialogs
In an older version of Cluster, when we asked for photo access, we would essentially ask them twice.
The first dialog (shown in the middle above) would set a local flag in the app that they’d said no, but it didn’t set it as “Deny” in the OS. That means if we want to ask them sometime in the future, we hadn’t burned our only chance.
Only 3% of users who clicked “Give Access” clicked “Don’t Allow”, meaning less than 2% of total users denied access at a system level.
Even though it seems annoying to ask twice, we almost completely eliminated the possibility of a user tapping “Don’t Allow”, leaving the door open for us to win them back in the future. And for what it’s worth, in live user tests, not a single test subject hesitated (or expressed confusion) when the second dialog appeared.
Educational Pre-permission Overlays
When asking for Contacts access, we wanted to do a little more educating, and the standard system dialog didn’t give us enough room or flexibility to fully explain what was going on, so we built our own that let us include an image.
So we first showed them a dialog about why we needed the access, and gave them the choice to use the address book, or enter contact info manually themselves. And of course, we’d only show the system permission dialog if they specifically chose “Use Address Book”.
Like above, it was a bit of a pain to ask them twice, but when presented with the iOS dialog, no one ever hit “Don’t Allow”. Plus, when the people who tapped “I’ll Enter Contact Info” realized what a pain it was, we had another prompt that let them connect their address book at that point.
Using pre-permission dialogs made the “Don’t Allow” problem almost disappear. It was exceptionally rare that a user didn’t give us access at a system level when asked. This was a major win for us. There was much rejoicing.
User Triggered Dialogs (The Most Successful)
Even though users weren’t denying access at the system level, we were still getting our share of users who didn’t make it to the system dialog because they didn’t want to give us the access at all. What the pre-permission dialogs had done was mitigate the times where the user wasn’t expecting it, not necessarily making more users accept it. We knew we could do better.
When we deconstructed the problem, we realized that users still weren’t expecting to be asked, so we found a way for them intentionally trigger the prompts, which in testing real flows with dozens of people has gotten permissions allowance close to 100%.
In previous versions, the first step in creating a new space in Cluster was to add photos. That meant we asked for photos access right after they hit “Create Cluster”. This resulted in the user granting photo access 67% of the time. But this could be improved.
We decided to move photo uploading back a few steps until they were a little more aware of what a Cluster was, and made them actually tap a camera icon and “Choose Photos” before we asked for access.
Asking users for photos access after they tapped a camera and “Choose Photos” increased the acceptance rate from 67% to 89%.
At this point, the user intended to upload a photo they’d previously taken, so giving the app access to their photos was a no brainer.
We asked ourselves what the biggest user benefit was from granting contact access. It was similar to what we were getting at with the “I’ll Enter Contact Info” manually action in our pre-permissions dialog. But in that case, they hadn’t felt the pain yet, so the benefit wasn’t as clear.
Ultimately, we decided to let them see how empty the contact adding process felt without the permission granted. Now, when they don’t see their friend show up in search, there is an action below that says “Show results from iPhone contacts”. Users generally tap this when they don’t see their friends in the list.
We found that since they are clearly trying to access their own address book, 100% of users accept the Contacts access when prompted.
Cluster is used to build small private spaces with friends. We asked ourselves, what would our users get value out of push notifications? The answer was knowing when their friends were active in the space they’d created.
So when a user sets up a space for the first time and invites some people, we ask a very logical question: “Would you like to be notified when the friends you just invited join?”. If they click “Notify Me”, we show them the standard iOS access dialog. If they say “No Thanks”, we let them move on.
During user testing, we saw a 100% success rate in iOS push notification permission after tapping “Notify Me”.
What We Learned: Context is Critical
Clearly every app is different, but really thinking about when the user would naturally need access to different parts of their phone, and making sure they expect to be asked, has made a drastic improvement to the success of these system dialogs.
Thanks for reading this! If you got value out of this article, I would really appreciate you hitting the recommend button below. And as always, please reach out on Twitter @mulligan if you have any questions or comments!
In addition to releasing the above info, we’ve tried to share tools we’ve created to help everyone build and manage better apps. Here are a couple other resources.
LaunchKit’s Screenshot Builder makes it easy to create gorgeous, custom images for your App Store page and export them in every resolution Apple requires. Learn more here.
If this article resonated with you, I’d highly recommend reading The right way to ask users to review your app: How Circa News got 90% 5-star ratings. It distills down a similarly complex yet crucial topic for app developers and I think you’ll find it very useful.