This post looks at several examples where permissions are asked for in a poorly structured way (Google Calendar on Web, Android Clock, WhatsApp on Android) or disregarded/not asked for entirely (IvyExec).
IvyExec is an online platform claiming to connect professionals with high end job opportunities and career advice
This post is less about any individual product and more about how and when permissions are asked of the user.
While the increasing amount of user data that products gather is helpful in ultimately building better products, there is a cost to obtaining that data, particularly if users feel as though their data is being harvested to exploit them or without asking their permission.
This cost is exacted not just on the products that behave badly, but across the entire ecosystem of digital products and services when users can no longer differentiate between good/bad actors or good/bad consumers of their data. Queue GDPR and it’s anti-data harvesting sentiment.
Unlike the remedy in this case, most applications either ask for permission to use user’s data first or don’t ask at all and simply abuse whatever data the user was required to give the application in order to sign up.
This is unlikely to be a successful strategy going forward in building a positive relationship with an application’s users due to the historic and continued abuse of user’s information.
While there are a potentially unlimited number of ways in which applications abuse user’s trust and data, there are several that are fairly common.
Every individual that has an email address suffers from email abuse by the organizations to which they have given their email.
The best actors at this point don’t subscribe you by default, but if they do, they allow an opt out with one click.
The worst offenders are like IvyExec below, which do not give you the option to opt out, and instead sign you up for every category of content they possibly send. In this case, I was signed up for 11 separate email notification streams by default!
In this case, I immediately lost trust in the entire application and would never use it again because it lost my initial trust.
Android permissions have progressed markedly over time, becoming more granular and forcing applications to ask user’s for their explicit permission when granting access to particularly sensitive data.
Unfortunately, as these requests have become more granular, they have also become harder to decipher what exactly is being requested, why it is being requested, and if denying it will impact the application.
In this example below with Spotify and the Android Clock application, I needed to grant The Clock app access to my Spotify account data (Note - Which data isn’t detailed here by default, you have to tap to see the data requested.)
Have we reached the point where I need to grant the Clock app permission to access my Spotify account just so I can use a song as an alarm?
I understand technically that Spotify and the Clock app are simply operating within the Android Permission Framework, but at a certain point, we need to admit it is broken.
Android WhatsApp Permissions
In this case, I already have zero trust in any Facebook ecosystem application, but due to several groups I belong to, need to download WhatsApp to stay up to date.
Because I have no trust, I am by default unlikely to accept any request of the application. This is a dangerous paradigm to have for a company that depends on harvesting consumer data to sell for a profit.
WhatsApp is filled with dark patterns, from constant attempts to hijack your address book to the below example, where I am unable to view images in chats unless I give WhatsApp access to my devices storage. This is unnecessary and hostile to the user.
Google Account Permissions
Google does as good of a job as it can in notifying users when an application needs to access information or you are about to connect an application to your profile.
However, it is hard to tell exactly what data is being requested, how it is being used, whether this will change in the future, and how, if at all, I will be notified of these changes.
In this example, when I simply wanted to add a conference invite from Zoom to my calendar, I needed to grant it permission to “Manage My Calendar". I understand why it might need that permission technically, but is this really necessary? It could also offer to spin out an ICS file for me to import, no connection required and much more user friendly.
TLDR -> Build trust first!
Building trust first allows you to to accomplish two objectives key to product development:
Gather the data you need to continue building great products without resorting to dark patterns or tricks.
Encourage users to link and contribute data to your product that enhance the product’s functionality, because they trust that you will take only what is necessary for that aspect to function.
One way to build trust is to engineer your application to request as little from the user as required while providing as much value as possible to them.
Give your users more than you take, especially at first as the user is forming a relationship with your product.
Continue to do this little by little, bit by bit, as the relationship with your user grows over time.
In addition, another way to build trust is to ensure your ask of the user is proportional to the value you provide to them or will provide.
For example, is it worth it for me to give WhatsApp access to my entire address book just to see an image? Unlikely - I’ll continue to use it without seeing the images which reduces the value of the product because the UX is poor. I doubt this was a conscious decision on behalf of the WhatsApp team.
Another example, is it worth it for me to stay subscribed to every piece of content from Ivy Exec when I know nothing about what that content is or how valuable it will be? Unlikely, because I just signed up for the service.
In both cases, the value the product was providing or would provide wasn’t proportional to the ask of me (the user), resulting a poor experience.
Building trust with your users, particularly as users become further disenchanted from bad experiences within the digital ecosystem, will be key to keeping those users from churning over the long term.