If you have an idea for a future app that will represent your tech startup, you probably have a vision of how the user should feel while using the app. What app designers often forget is that privacy regulations intervene with the ideal user experience, which is crucial when the users have an app in their hands for the first time.
External privacy alerts
If we ignore the gaming segment, most commercial apps operate with a certain level of data exchange. This by default means that the user will exchange their in order to get an added value out of the app. Since, unfortunately, there are malwares that act as apps which can infect a mobile device, each device has built-in alerts that warn each time an app wants to access user data. Likewise, any online service that the app needs to access will warn the user that there is a request for their data.
In order to comprehend the privacy implications of your app, you must ask yourself which methods the app can best collect data from the user with. We can vaguely divide a user’s data sources into three categories: device data, manually entered data, and account associated data.
Device data – If you’re planning a fun and interactive new mobile app idea, it’s likely your app will use some images as an input. Those images must be sourced from the device’s gallery or camera. As a safety measure, the user’s device (be it iOS or Android) will ask the user to give an explicit confirmation for the app to access the device. As a smartphone user, you have noticed these default alerts when downloading any new app. Once access is confirmed, the device will remember this decision and will not intervene in the app’s UX.
Manually entered data – If the application has built-in purchase options, the most delicate piece of data the app will collect is the payment instrument information. To ensure that the credit and debit card information is handled discretely, each app must comply with PCI DSS (Payment Card Industry Data Security Standard). PCI compliance implies that no credit card numbers should ever be saved in some kind of database. To ensure that a certain credit card can be associated to a user in an unfortunate event of a purchase dispute, the standard is to store only the last four digits of a buyer’s payment card.
Commercial apps usually require some information about the user in order to give valuable insight back. An example would be an app that suggests recipes – in order for the app to give relevant recipes, the users must enter their preferences and thereby trust the information about their eating habits to the app provider. What happens with the collected data must be transparent to the user. This is regulated in the Terms and Conditions text the user is asked to accept during registration for the app. The users should be aware that their data is now owned by the app provider, but they do not need to be warned when typing in the data that they’re doing just that – typing in information in an app.
Account data – by the term “account associated data” we recognize all the data that is pulled from services with which allow for the so-called “login with” option – like Facebook, Gmail or LinkedIn. From the development perspective, it is very easy to have this option. By integrating e.g. the Facebook Account Kit, users don’t have to come up with a new username and password, but instead, use their Facebook login credentials to register to your app. This has huge implications because the user trusts his entire Facebook account the app owner. The users will be explicitly warned about the fact that they’re allowing the app to access their Facebook data. Of course, you as the app owner know very well which data your app is collecting, but the user might have a negative reaction to Facebook’s default alert message saying “APP would like to access your public profile and friends list”.
Each data sources your app can use should be considered when planning, from either a UX or legal standpoint.
Internal privacy alerts
The “smart” component in smartphones implies there is some information about the user the device can use in order to provide relevant and personalized output. In order to have engaging UX, the app will have to store some data. Any data that an app provider holds means responsibility. The users trust their data to the company who services the mobile application. It’s understandable that there are many governmental and international laws regulating this responsibility. There is a universally-adapted and highly imperfect way of regulating privacy implication between the user and the app provider – it takes form as the well-known “Privacy policy” text. This copy is mandatory, but it does not list specific data protection measures – which play in the hand of the app provider, but not the user.
Be it for the sake of satisfying the legal framework or protecting themselves, app providers must come up with “contracts” which the users must accept in order to use the app. These contracts are more commonly distributed in the form of “Terms and conditions” copy which the users must accept. The specific content of the terms and conditions text can be generically pulled from services as terms feed. Depending on the complexity of the app, it’s generally recommended to app providers that they consult a lawyer when creating the terms and conditions text. For most users, the term “Terms and Conditions” is an association to the checkbox they have to tap-on when creating an account with some online service.
To conclude, privacy alerts are a part of the initial user experience. Users will navigate for the first time through the app and as they do, steps will be interrupted by mandatory privacy and terms alerts that require their confirmation. We have found that a tutorial (short video or a few slides) is a great and informal solution for introducing the app’s purpose to the user without worrying privacy alerts. Reach out to our team to learn more!
Janko is the Project Management team lead at FarShore. He says that Project Management is just like riding a bicycle: it gets exciting once things start going downhill.
