Obtaining App Permissions the Right Way and Humanizing the Process
Remember all those times you discovered a new app, took the efforts to download it from the App/Play Store and opened the app, only to be greeted by a bunch of annoying back-to-back permissions prompts? We’ve all been there.
Yes, I understand that apps these days need multiple permissions to do things the smart way, engage users and perform core use-cases. And then there are apps like Uber and Snapchat that run with location or camera access permissions at their core, forcing users to grant them even if it was denied initially.
iOS allows an app to throw a permissions prompt within the app only once. On Android, attempts are not restricted but after the first attempt, a ‘Never Ask Again’ checkbox shows up.
Once this chance is lost, requesting the user to manually grant permissions via Settings makes it a tedious process and has had minimal conversion. Save this chance. Use the right context, copy and triggers before prompting. Do Permissions the right way.
Permissions while Onboarding
This is one of the most commonly implemented methods across iOS and Android. Android classifies Notifications and a couple of other permissions as normal, thus toggling them on by default during the app install. But on iOS, all permissions need to be manually approved – I picked a couple of popular apps that request for permissions during onboarding:
LinkedIn and Meetup wait for the user to login and once successfully authenticated, notification access prompts up while the feed loads in the background, neatly utilising loading time. On the other hand, Any.do prompts for notifications access instantly on app open, blocking content on the welcome screen and the social login buttons.
If you had a visitor ring your store’s doorbell, would you first let them inside to experience the store or ask them to answer a series of questions at the doorstep?
Multiple other apps (Soundcloud, Ola, WeChat, PhonePe) greet users with prompts like Any.do, leading to friction in the login process, poor visibility of onboarding content, thus restricting a user from experiencing the app on his/her first visit. One or all of this eventually could lead to a frustrated user who drops off the app without even getting to experience it.
Paytm’s prompts for 3 notifications back to back are further overlapped by the Login Modal, leading to 5 notification prompts in total.
All of this before a user can enter their credentials or understand what is happening in the background. 🤷
Permissions when needed
Across multiple applications, permissions like location access, contacts, microphone etc are put to use only after the user carries out certain events or lands on a specific screen – for the first time.
- A cinema booking app needs access to your contacts to share the booking confirmation code with your friends only after the user makes their first ticket purchase.
- A bank’s app needs access to your location only when you try to find branches/ATMs nearby for the first time.
And so on. If the permission prompt is thrown after the right action, the user understands the context real-time and is tempted to grant the permission instantly.
View SMS permission on Android is used to auto-fill the confirmation code sent via SMS. Zomato prompts for this only when the user arrives at the login screen and has requested for the code while FreeCharge’s prompt happens right after opening the app, even before the user reaches the mobile number screen.
On the Zeta app, location permission is a non-core feature that is used only when a user tries to discover/make payments to stores nearby. Instead of the request being done when the user lands into the appropriate screen, it shows up during a new user’s signup process, blocking the text fields that I’m expected to fill. Ugh.
Humanizing Permissions and Copy
Across most permissions, iOS allows apps to display a custom line of text in the permissions prompt. If this is utilised well, the user is first informed about the need for it leading to higher chances of granting it. Keep your copy dead simple, ELI5.
It’s super interesting how Whale, a Q&A app saves up the notification prompt request until the user views an influencer’s answer for the first time. Further, it uses context on a custom prompt with the name of the person.
Simple language, custom context and informs the user how they’d be benefited. Why would anybody not grant this?
Educating with Custom Prompts and Background Area
Since there’s only one attempt to directly request for permissions, multiple apps use custom prompts to educate users before the system prompt is thrown to them. Since custom prompts do not have design limitations and can include images, videos and text, they help in educating users much better in certain use cases.
However, a commonly discussed point around this is that using custom prompts leads to two prompts per permission request and might not be the best way to educate the user, especially when your app requires 2+ permissions.
A few apps circumvent this by utilising the background area to convey text, visuals and explanations as the system prompts are being displayed. Couple of examples from MakemyTrip/iOS and OLX/Android below:
Across multiple companies, business and growth teams make use of notification permissions to engage users with targeted push notifications and is thus considered a critical one. Considering the critical role it plays, it’s only obvious to handle it the right way and request for it at the right time.
Other permissions that are not a part of an app’s core functionality or business decisions, but only used to enhance experiences have to be requested for only when needed with appropriate copy, unless you’d want to use them for syncing data in the background even if the feature is never used.
Remember, you get only one chance to throw that prompt. Do it right.
Prodgasm is a collective of product experiences that make users go 😍 or 💩. Visit http://prodgasm.com to view or submit your own. To be notified on more posts like this, scroll down and follow the Prodgasm publication.