A Designer's Guide to GDPR

Making sense of all of the changes GDPR brought with a practical, actionable set of Do's and Don'ts.

8 minute read

Originally written for and edited by Prolific Interactive

Disclaimer: Nobody who contributed to this overview of GDPR or the accompanying checklist is a lawyer. This does not constitute as legal advice. This is by no means an exhaustive list. Please consult a legal professional for specific questions.

Recall the Great Privacy Update of 2018: Your inbox was flooded with emails from apps and websites you didn’t even remember having an account with, and maybe for the first time in history, privacy policies became a meme. This momentous occasion was spurred by the enactment of the General Data Protection Regulation (better known as GDPR), the European Union’s landmark regulation on data privacy.

Finalized and announced in 2016, GDPR went into effect May 25, 2018, forcing many companies to adjust how they store and transfer data, how they ask users for consent, and what information they disclose to users. And GDPR doesn’t mess around: violators are slapped with hefty fines: €20M or 4% of the company’s worldwide annual revenue, whichever is higher.

I’m going to say that again: If you violate GDPR, you will be fined a minimum of €20M.

Now that I have your attention, let’s start with this handy quiz the BBC put together to gauge your familiarity with GDPR and identify gaps. The quiz certainly doesn’t cover everything, but it should give you an idea about any blind spots you may have.

Who does GDPR apply to

A discussion about GDPR would be incomplete without covering exactly who and what it applies to. There’s a misconception that because the World Wide Web is accessible to everyone everywhere, all companies need to comply with GDPR. Thankfully that isn’t true, but it might apply to more situations than you think.

Forbes does most of the work for us in clarifying who GDPR applies to:

The second point is that a financial transaction doesn’t have to take place for the extended scope of the law to kick in. If the organization just collects “personal data” — EU-speak for what we in the U.S. call personally identifiable information (PII) — as part of a marketing survey, then the data would have to be protected GDPR-style.

In case you’re still scratching your head, here are the basics:

One point of clarification, however, is that GDPR does not apply to any EU citizens living or vacationing abroad. If an EU citizen uses your product or service while on a trip in the USA, you’re not liable. Ultimately, this makes sense: an EU regulation should only apply to companies and individuals in the EU. Many companies decided to be compliant just in case, though, as it’s better to update your policy than get slammed with multi-billion-dollar lawsuits.

Also, being GDPR compliant can make for a better overall experience and enforces some user-friendly design decisions, so you may want to consider being GDPR compliant anyway.

How to be GDPR compliant

GDPR compliance can be broken down in many ways, two of which we’ll cover here. For a fuller picture, check out our “GDPR Do’s and Don’ts” checklist that provides a list of action items, features to offer, and design practices that are no longer permitted. In this article, we’ll focus on Consent and Data Rights.

When I began investigating consent under GDPR, one of the first things I noticed was that one of my favorite sign-up tools was no longer allowed. Next time you see text above a “Sign Up” button that says something along the lines of, “By signing up for this service, you agree to our Terms & Conditions and Privacy Policy”, and doesn’t provide an action that users need to take (a checkbox, toggle, etc), know now that that’s not GDPR compliant and could be grounds for a lawsuit. In fact, you need a separate user action for each type of consent you’re asking for.

What exactly are the types of consent? There isn’t a clear definition here, but you’re better off erring on the side of caution. Consenting to your T&C doesn’t necessarily include consenting to receive email. You can no longer ask for access to data you don’t absolutely need for your service to function (e.g., no asking for contacts unless you need their contacts), and you need to ask for these permissions in the context of what the user is doing (e.g., don’t bombard them with requests upon first signing up; ask for specific information when they first access that part of the app).

Data Rights

GDPR has clauses around what they consider “data rights” as well, such as the Right to be Informed, the Right to be Forgotten, and the requirement of having a Data Protection Officer. The DPO is essentially a new role at your company (who must report directly to senior management) and is responsible for ensuring you’re GDPR compliant. This person can have other functions and can be external to the company as well, but that direct line of communication to decision-makers is essential.

The “Right to be Forgotten” is a requirement that’s caused a lot of trouble for companies with existing legacy data. Essentially, any user (current or previous) at any time has the right to request companies completely erase all of their data. While fairly simple to support from a design standpoint, this can be a significant challenge for engineering, especially if your data isn’t currently structured to allow for that erasure. It’s not really an issue for websites, which usually have a fairly simple data structure, but if you’re building an application, your data model needs to account for this.

GDPR has a bias toward transparency, which includes the Right to be Informed. On top of needing to disclose what data is being collected and processed, and by whom (yourself and any external/3rd party resources), you need to maintain versions of your Terms and Conditions and Privacy Policy and track when users consent to them. Users have a right to know exactly what they consented to and when, and to be notified of any changes to those policies.

If at all possible, I would recommend setting up one, centralized place for users to find all of this information. yourdomain.com/GDPR is probably a good place to start, where you can list contact information for your DPO, all of the Data Controllers (any person or company that stores, processes, or transmits user data), your policies on the various Rights of the GDPR, and your current Terms, Conditions, and Privacy Policy (or all previous versions if you’re ambitious). Those T & C and PP, by the way, need to be well-designed, with a clear information architecture, so no more giant-block-of-text, either. SurveyMonkey is an excellent example of well-designed (and versioned!) Terms of Use.

Why GDPR makes a better product

While it might seem like a lot of hoops to jump through, GDPR regulations actually make for a better experience for your users, and adhering to them ultimately produces a superior product. Constraints are fundamental to design, after all.

GDPR enforces some of Nielsen’s Heuristics. By providing increased transparency about how data is stored, processed, and used, as well as greater ease opting in and out of certain permissions, you increase “user control and freedom”. Having well-designed, clearly-worded terms, conditions, and privacy policies help your product “speak the user’s language”. Improved permissions and controls also help users prevent, diagnose, and recover from errors as well.

And GDPR is all about context. By providing just-in-time consent, you establish a clear association between the information you’re asking for and why. We’ve all seen (and abandoned) apps that hit you with a flurry of permissions requests on your first sign-up. By asking for location permission when a user first accesses the map feature of your application, not only are you compliant, but you’re helping the user understand why you need it.

GDPR is also about control. There’s no reason to hide the exit (or anything, really) from users. If someone wants to get off of your service/platform, they will. The harder you make it for them, the less likely they are to ever return or recommend your service. This peak-end rule can be a powerful tool in your design arsenal and should be taken seriously.

In Closing

There’s certainly no shortage of resources around GDPR and compliance, so don’t stop here. Our checklist tries to be as actionable and direct as possible, but it’s certainly not exhaustive. And we’re always happy to start a conversation about helping you on the journey to compliance.

Additional Resources

Originally written for and edited by Prolific Interactive

Posted on October 9, 2018 in User Experience
Tags: [gdpr] [design] [product strategy] [prolific interactive]

All User Experience posts: