With a week to go until updated data regulations (in the form of GDPR) come into force, you’ve undoubtedly been receiving an increasing number of emails from various companies. These companies have your data stored in their systems for any number of reasons. Maybe you actively subscribed to their newsletter or perhaps you bought a product from their online store. You could also have been auto-added to their system because you once downloaded a piece of content or had a receipt sent to your email inbox instead of receiving a printed copy.
Whatever the reason you ended up in their system, these companies want you to stay there. Under GDPR, they have to ensure you’re there because you have given your explicit consent.
I believe that GDPR will create a distinct competitive advantage for those companies who invest in crafting great user experiences around what “explicit consent” actually looks like. These companies will build relationships based on transparency, honesty and long-term trust. The latter is especially important in 2018, considering the increased media attention regarding digital privacy.
GDPR is a strict piece of regulation and whilst it’s not particularly difficult to understand, it’s certainly harder to implement. It requires an extraordinary team effort and companies are investing a lot of money to ensure they get it right – after all the penalties for compliance failure are steep. Take Facebook, for example. Damage to overall trust obviously costs them user numbers however the potential financial penalties are immense… it could be fined up to 4 per cent of its annual global revenue, or €20m, whichever is higher, if it breaches the rules. If you stop to consider who holds a lot of data about their customers, banks are another obvious example. In short, the regulatory payday as a result of breaches across many industries is likely to be considerable.
Implementing GDPR requires close collaboration across organisational departments. Its requirements should be dealt with like any other product or feature in your company’s roadmap. The resulting changes should be subject to iteration and user-testing in order to both comply and create the best experience for your users along the way.
Hopefully your company is already en route to GDPR compliance, but have you figured out how to translate regulation into the proper front-end experience the user deserves?
The below outlines some of the essentials to consider along the way as well as what I believe should be part of internal GDPR UX guidelines.
Firstly, companies need to explicitly explain what the data is that they want to collect. Your customers should have a very clear understanding about exactly what it is they’re consenting to. For example, if you need to collect data for a certain feature of your product or service – for example data about a person’s facial characteristics for face recognition technology then you should be clear about this. Inform the user, in short, about how such a feature works – everything they need to know about how and why this data is intended to be captured must be included. If relevant, include links to where the user can dive further into the details.
How it’s processed
You should briefly describe how the data is used and for what purpose. Be transparent.
Users must actively opt-in to have their data collected, stored and used. No pre-ticked checkboxes allowed! As UX designers, our job is to lead the user in the direction we want, e.g. to create higher conversion rates by using prominent call-to-action buttons, for example. Looking through GDPR glasses, we have to think a bit differently. We want the user to make a properly informed decision when they move forward. It is important to avoid creating bias around the decision by creating more prominent call-to-actions for accepting consent requests. The user’s options must be given equal visual prominence.
Caption: On the left, you can see that a user has to actively check the box themselves to opt in. On the right, the company has pre-checked the opt-in box for the user which is not explicit consent/active opt-in.
Clearly separate terms and conditions from consent requests
Agreeing to terms and conditions and giving consents to various activities are not the same thing. These should be clearly separated and easily distinguishable from each other. They must provide individual opt-ins for consent.
Caption: To the right you can see that the consent for agreeing to the terms, collection of location data, name and address is grouped. This is not allowed. These must be clearly separated as in the example to the left.
Allow customers to consent separately for different types of data collection and processing. Help the user to have full control of their consents and permissions by creating an easily understood overview of each activity you need and want their consent to carry out.
Caption: From a best-practice point of view, it’s no longer good enough for a one-size fits all approach to data collection. If you need a user’s address, consent for this should be captured separately to needing to know a person’s location whilst in app, for example. This is a win-win situation for the user and the company collecting the data. For example, if consent for location or address is captured together and a person opts out of this entirely, the company loses two valuable data sets instead of just one.
Make it easy to withdraw
Users have the right to withdraw their consent at any time. When users consent, they should be informed where and how to withdraw. It is likely they will forget how to do this after the first time they see this so it’s the company’s responsibility to make withdrawal options easily accessible at all times. A good practice could be to provide permission options in context of data about you being used.
Caption: An overview section such as the one to the left should be easily accessible at all times in your service. To the right you can see that the user is offered withdrawal option in the context of using a map which has personal information stored about the user.
Your organisation and any third-party relying on the user’s consent must be clearly named.
For example, if there are third-parties relying on and using users’ consented data, it’s not ok to just say “third-parties”. They must now be clearly named.
Caption: To the right you can see that the company are grouping the consent for sharing personal information with third parties. The user doesn’t know who they are, which is bad practice and not compliant with the regulation. To the left, the third parties are clearly named. In addition, the user is offered granular choices about whom to share this information with.
Other good practices that are important to consider around GDPR include:
You should, of course, ensure language around communicating new data policies and consent is as easy to understand as possible. This should be an important consideration when it comes to any user communications, but , it’s especially important for GDPR which involves a heap of choice and it’s actually something users aren’t, for the most part, used to being in control of. Avoid complex phrasing when explaining reasons for consent.. Team up with your copywriter and compliance officer to work out some good pieces of text that also fit in with the UI experience and user flow.
Use illustrations or real examples which clearly show how a particular feature that is dependent on consented information would or will work in practice. This helps to manage user expectation and assists them to making informed decisions. For example, if you’re planning on running personalised ads, it could be helpful to the user if they could actually see an example of how what they could expect to see with and without the personalisation.
I am not professing to be an absolute GDPR expert but I do know a bit about user experience. The above suggestions have been put forward by placing the user at the very heart of the core GDPR requirements.
Aukaworks closely with banks who have a lot riding on their execution of GDPR compliance – and indeed the user experience that accompanies this compliance.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.