Brenden Mulligan is a co-founder and designer at Cluster, a web and mobile app which enables users to create private social
networks around interests and experiences. Brenden previously created and sold ArtistData and Onesheet.
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.
Turning permissions back on in an iOS app
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.
HeyDay educating users why they should give permission
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”.
Pre-permission Dialogs
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.
Using the iOS dialog for pre-permission
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.
A custom, educational pre-permission overlay
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%.
Photos
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.
Contacts
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.
Push Notifications
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.
No comments:
Post a Comment