GDPR, DATA HANDLING, AND USER FLOW

WHAT IS GDPR AND WHY DO I CARE

GDPR stands for “General Data Protection Regulation”. It is a European law covering data usage, collection, and protection. Businesses engaging in any international data handling (such as the Discovery Center collecting the email address of an EU citizen) need to make sure their data handling processes are GDPR-compliant.

For that reason, compliance was a firm requirement of the Discovery Center Interactive, so I dove into researching how the law related to our emerging solution.

An aside about me before we all dive into this. I love digging into things. Like, a lot. Once I decide I need to learn a thing, I really have to learn the thing. I’m able to find most things interesting, no matter how unsexy, especially if there’s a problem to solve. And GDPR, well, it’s not sexy. But the larger conversations around data privacy? Sign me the heck up.

Still with me? Let’s continue!

Once we validated our concept of Discovery Center visitors sending a message to Partners, I knew our design would handle different levels of visitor data throughout the process. We also knew from the start that minors would be using this interactive.

We worked from the assumption that anonymity would make sending messages more appealing to some users, so filling out a name and location was always optional. But even the body of a message from an un-named user could contain enough personal information en masse to be considered personally-identifiable information. Thus, we needed to consider how to handle message data even in the absence of a name, location, or email address.

A second issue was the user’s age. Anyone under the age of 13* cannot give their consent to an entity to collect personal data, so storing anything entered by a minor was right out - that is, if the data is identifiable.

But GDPR gives options for handling data. Data lacking consent, such as from a minor, can be collected as long as it is irreversibly anonymized. At this point in my research, I created three categories of data relevant to our needs:

1. Data from an adult, given with consent: may be linked to an individual, collected, and stored by Gates.

2. Data from an adult, without consent: may be collected if anonymized.

3. Data from a minor: cannot give consent; all data must be anonymized.

This made something else clear: we needed to have some manner of age confirmation mechanism so the system could identify the type of data it was dealing with. The Discovery Center has a large number of student groups, so I knew many users would be under 13. Although other interactives in the museum simply include fine print, I wanted active age confirmation.

*GDPR considers a minor anyone under 16, but allows member-states to go as low as 13. As other interactives in the Discovery Center use age 13, I stuck with that.

FIRST PROTOTYPE: IMMA LET YOU FINISH, BUT

This early version of the design included age confirmation when a user hits “send”, after writing their message. Participants in our first round of usability testing found the process confusing and irritating. As I looked at the flow again, I could see why.

Imagine a user writes a thoughtful message to someone, perhaps even shares a personal story, then is bombarded with an age confirmation out of nowhere, when they just want to send their message. Or, a young person inspired to write a letter to a doctor working on the other side of the world turns away without sending, because they’re only 10. It didn’t help that the language in the first prototype was unnecessarily negative - we risked turning people away regardless of backend data handling.

While I felt it was important to have active age confirmation, I didn’t want it to be at the expense of anyone sending a message.

I needed to figure out a flow that allowed all users the satisfaction of sending their message - regardless of which data category they were in.

A BETTER FLOW: THE SYSTEM DOES THE HEAVY LIFTING

Between anonymizing data and the concept of user sessions, I realized there was nothing preventing all users from completing the entire process of sending a message - age confirmation could come later.

What I came up with works like this:

1. A user writes a message and taps “send”. The message is marked “pending” in the backend - it will send no matter what, but the system needs a bit more information to know how to handle the data.

2. After hitting “send”, the user is on the Thank You screen. This is also where they can choose to join the Gates email list. Any user, regardless of age, may enter their email at this stage and choose newsletter options.

3. Once the user selects “submit”, an age confirmation modal appears. Whether they entered and email address and depending on their age confirmation answer determines how the data (message and email) is handled.

   • If the user entered an email address and is 13+, their message is sent and all message data is stored alongside/linked to their email address.

   • If the user did NOT enter an email address, their message is sent, and regardless of age confirmation message data is anonymized and stored with Gates.

   • If the user is under 13, their message is sent, and all message data is anonymized before being stored. If entered, email addresses are purged.

Here’s what this process looks like in the design:

One wrinkle with this process is with the subgroup of users who entered an email address but are under 13. The system as-is will purge the email address and never send a newsletter as implied. Younger kids might never remember or notice (or even have a valid address) but a 12 year-old might well remember and wonder why they never got their email.

A potential solution would be that for this subgroup, after tapping “no, I am under 13”, the modal would transition to an option to have a parent or guardian enter their email address instead. But considering many kids come to the Discovery Center with school groups (no parent or guardian present), we would need a simple action to skip this, with a brief and friendly “FYI” explaining why we can’t send them an email. If time and resources had allowed, I would have tested this with this user group to make sure the language was clear and understandable, without being off-putting or condescending.

JUST ONE MORE THING: TIME OUTS AND DATA PRIVACY IN PUBLIC

We weren’t quite done, though. There was one more data handling challenge to address. In a pubic space, what happens to someone’s data when they walk away in the middle of the process?

This one’s a bit easier than age confirmation. I specified time-out modals to appear whenever the interactive was idle for a certain amount of time. That time depends on whether data has been entered or not. If data hasn’t been entered, the time before the warning appears is longer. If data has been entered, the time is shorter.

When the timer runs out, the interactive returns to the welcome screen. Any data entered without completing the entire process is purged.

And that’s it! Thanks for coming to my TED talk!

(Did you really read all that? Good for you. Have a cat gif.)