Aleth Gueguen ‘Looking at Design through a GDPR lens’

Gerry: Hello, and welcome to Bringing Design Closer.  My name is Gerry Scullion and I’m a service design practitioner based in Dublin City, Ireland.  Today, I caught up with Aleth Gueguen, a GDPR legal specialist based on Nant, France.  We chat about all things GDPR related and run through a typical research scenario of gathering data as we research, storying that data and also deleting that data and all the implications from a GDPR perspective as we research.  

Learn more about GDPR

• https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/
• I also did this map https://gdpr4saas.eu/the-gdpr-at-a-glance for a first understanding of the regulation
• The searchable GDPR https://gdpr.algolia.com/

Aleths details

• https://gdpr4saas.eu/
• Aleth on Twitter

We speak about informed consent and also, how we as a design community can actually work better with legal teams, to ensure that we don’t get caught out at the last-minute with some legal requirements and risk disrupting the beautiful experience that we most likely have designed by interrupting it with pop-ups all for compliance.  Anyway, let’s get straight to it.  Aleth, a very warm welcome to Bringing Design Closer.  How are you?

Aleth: I’m fine, thank you for inviting me to your podcast.  

Gerry: Absolutely, no problem.  We were delighted to have you here.  I know there are people in the Slack channel, as well, that are really interested in this podcast in particular.  Today, we’re going to chat about the exciting topic of GDPR.  I’m being a little bit funny when I say that.  Let’s start off by telling us a little bit about yourself and what you do, Aleth?  

Aleth: I’ve been doing bespoke development for business, like business application for SMBs in the manufacturing industry.  When the GDPR kicked off two years ago, I was very interested first as a personal interest, then my client asked me, well, we are not sure about that, can you help us with that?  I said sure because I already had a very serious interest in privacy and data protection.  It was a good starting point.  

When I started helping my client, I also noticed that a lot of other developers and SAAS business owners had questions, a lot of questions about GDPR, about how you go with that, what thing you have to do, what thing you have to not do.  I started putting together a workshop, talking in conferences, in meetups.  Whenever someone asked a question about GDPR, I try my best to make things clear.  

Gerry: Yes, which is great.  

Aleth: Yes, in fact, when you are a developer, someone who’s used to writing code, reading GDPR is the same as reading specs for a new language or a new package, it’s the same.  

Gerry: It’s kind of ironic because in times past, the legal terms have been confusing.  GDPR hasn’t actually made it any better.  It’s still confusing.  

Aleth: Well, I wouldn’t say that because I think the GDPR made a lot of effort to be very straightforward, to have very few legal jargons.  It was an endeavour of the European commission to make sure that the GDPR was readable.  In fact, it’s quite clear.  

Gerry: It is quite clear.   We’re going to get into that a little bit more in around the tactical implementation of GDPR, because I know the community, everyone has been chiming in on this, because there are lots of questions and that’s where my statement came.  It’s not entirely clear.  It might be clear to understand it, but it’s not clear how to execute it.  

Aleth: Yes.  

Gerry: That’s what we’re hoping to clear up today a little bit more.  Aleth, what do you think prompted GDPR?  Where did it come from?  

Aleth: First, let me tell you that GDPR had been in the making since I think it was 2012.  

Gerry: Okay, it’s been on the horizon since then?  

Aleth: Yes, it took four years to put every country in Europe in the same page to write this regulation, what prompted it is because people were aware, a lot of personal data was harvested across every country and services and product.  It was starting to a problem.  Especially for Europe.  Europe has this history of being very sensitive to privacy, protection to privacy.  It’s a sense of history.  Yes.  I think it was a history of things to have Europe put this regulation.  Also, a country also have privacy regulations.  It’s not only Europe.  Canada has one, Switzerland, New Zealand.  Some other countries, Japan just passed one, so it’s not only Europe.  

Gerry: Yes, which is good.  

Aleth: I think it’s a sense of history now.  

Gerry: What do you mean?  

Aleth: Like, we don’t remember when the first car went into production and on the road, it was a hundred years before.  At some point, you had to put on some regulation because cars are dangerous.  Now, we’re 20 years into internet and all of these marvellous things happening.  There’s a dark side of it.  We need some rules.  

Gerry: Yes, which is a great Segway.  Speaking of rules and maybe describing things, how would you describe GDPR in layman terms?  If you had to speak to a child and say, “What is GDPR, how do you describe it?”

Aleth: Okay.  I would describe it, if you want to have something private, you should have the right to have it private.  Then if you are not so much a child, but someone who is building product, it’s just if you are building a product, just put yourself in the shoes of the user.  Ask yourself, if it was my data, would I be okay with what I’m doing to do with it?  It’s a basic of what is GDPR.  It’s having a fair and honest use of data.  We need data to do business services.  No question about that, but the question is how you use it.  Is it a fair use?  

Gerry: Yes, and how you transfer that knowledge to the customer or the person using the products or services.  

Aleth: Yes, and this is where you come handy.  

Gerry: As a service designer and UX design people who are listening to this, there’s quite a lot of other practitioners, psychologists and anthropologists and ethnographers, all part of the community here.  What we’re going to do is, say, take a typical scenario of a research project, I guess, I’ll probably be displaying a little bit of my own process, but just say, for argument sake, we’re going to do six qualitative research sessions.  In those sessions, we were going to do some home visits.  I was going to do some contextual enquiry and I was going to be shadowing people around their homes.  

During the course of those research sessions, I had a consent form, the people were aware that I was going to be capturing some information, so I might take a photograph of them, which could be stored on a digital device.  I may use a Dictaphone to record the audio while I’m in the presence of those people.  I also may use my camera to take pictures of artefacts in the home, such as the environment.  There may be other people in the background of some of those photographs.  

Then I ask them a series of questions and I might get them to complete a paper survey that they fill out and they complete their name and so forth, and their date of birth in that paper survey.  Then I take that research and I bring it back to my office, I take pictures of them and I put them onto a Google Drive or a Dropbox or a box system.  I share it with my team.  Then we might extract some of the data, some of the sentiments and the quotes onto a shared Google Sheets.  

Again, I might, well, I more than likely will de-anonymize the data, so I’m not including their name.  the photographs will be stored somewhere digitally, so we can actually use them for when we’re playing back the scenarios to the stakeholders, the people who are involved on the project.  They’re stakeholders, they’re not doing the work, so to speak.  Then afterwards, we create our insights and we move forward with the project.  

Just saying, if that’s a typical scenario and there are probably a few gaps there, I know people are saying, “You forgot this.” If that was as typical scenario, and you can see, we’re capturing artefacts and digital artefacts and paper artefacts there, what are the risks there from a GDPR perspective on what I’ve gathered.  

Aleth: In fact, you are capturing a lot of things.  It can be sometimes really intrusive if you are in people’s home and taking photograph of their interior and other people.  If you want to respect the GDPR, all of this capture and data, if they are personal data, it must be recorded in some capacity.  

Gerry: What constitutes personal data?  

Aleth: In the GDPR sense, which is different from the personal notification information of the U.S.  for example, in the GDPR sense, what constitutes personal data is any piece of information by itself or if cross with other data can identify a physical person.  It’s very wide.  It means photograph, it means GPS location data, notification phone number, social security number.  Any piece of data which can make you identify someone.  If in time you will store or college this piece of data, so you must have legal ground.  

Meaning, you cannot collect anything, either because people consent to it or because you are executing a contract.  You have to seek legal ground.  You must make sure that you are always inside the law when you are handling personal data.  Then I get the sense that in your qualitative survey, it may be the case that sometimes you collect some very sensitive information like political opinion or religious belief, am I right?  

Gerry: It depends.  

Aleth: It may happen.  This data is a special category of data.  

Gerry: If it were open-ended questions in a paper survey, say, what are your thoughts on this?  They wrote out some very explicit information on what they felt to answer the question, so their sentiments or their emotions regarding a politician or trust of an organisation.  They didn’t name themselves in that open-ended text.  Would it be right to assume that open-ended texts needs greater consideration from a GDPR perspective?  

Aleth: Yes, if it includes this kind of very sensitive information and it’s not anonymised.  If it’s anonymised, it’s quite different.  If you can pinpoint the person who has said that, yes, you must handle it with really great care.  

Gerry: What about the storing of the digital artefacts?  This is a big one because it spreads?  

Aleth: Yes, we are talking here about European people.  It’s different for other parts of the world.  For European personal data, you’re not supposed to send them overseas, outside of Europe.  

Gerry: Okay, so even like a digital service, like a transcription service that could be based in America, if you’re going to send those files, upload them to another server in America, that’s breaking GDPR?

Aleth: Well, America is complicated.  I would consider very much right now other possibilities to stay in Europe.  I know it’s not very easy, it’s not going to be right now, but start to consider it because things are going to be more and more complicated.  Plus, you have to have a good grasp of what you do with this data.  Okay, so you upload to some cloud somewhere, the data should not stay there forever.  You should have a way to delete it, supress it after…

Gerry: Like, one week.  

Aleth: Well, the shorter the better, but any kind of personal data you are storing for any purpose, it’s not forever.  You cannot store any personal data forever.  

Gerry: Okay.  Should that be outlined in the consent form?  Whenever they’re signing the consent, presumably, it should include the types of artefacts that are going to be captured and the length of time and the location of where they’re going to be stored?  

Aleth: Yes, in fact, it’s more than that, you should provide the people you are collecting the information, the personal data, you should provide them with all the information they need to make an informed consent.  Meaning, what is the purpose of the data you are collecting, how long you’re going to keep it, what is the legal ground, how they can ask for the data.  You know what?  They have the right to ask for that data.  You have to provide them all of it.  

Gerry: Best practice might be at the end of the session, showing them what data they’ve captured.  

Aleth: Yes, that would be great.  

Gerry: Then basically being explicit about what they’re going to do with that information moving forward?  

Aleth: Yes, absolutely.  Make sure they understand they have a right to access the data, ask for it to be supressed or for it to be updated/modified because they consider that the opinion has changed and it’s no longer accurate.  Plus, you have on your side an obligation to make sure the data is secured.  

Gerry: Yes.  By secured, let’s talk a little bit more about that, because my version of security is two-step authentication on all my data.  That may vary from practitioner to practitioner.  What’s your understanding of what secured data is?  

Aleth: Well, we have to move a big step upward.  Meaning, first, you have to have a good grasp about what is security in general?  Meaning, how you manage your password.  How you manage your devices, what is the general policy of your organisation concerning IT in general?  Also, choosing provider you are confidently aware they are sufficiently secure.  Usually, if you are using these big cloud providers, they know how to do security, there’s no doubt about that.  There are other problems about that, but not about security.  

Also, you have to think about who will access the data inside your organisation.  Basically, not everyone should have the right to access every data.  This is very important because especially if you are collecting sensitive data or very personal data that should not be accessed by everyone in your organisation.  You should have a proper policy, chart of right, of what you should do to make sure that only the people who are directly concerned by the data access it or have the right to copy it or disclose it to third-party.

Basically, we are talking about the organisation of your department of research, of customer research, but you understand this is a general endeavour for the whole organisation.  GDPR cannot be for just one department.  

Gerry: Absolutely.  I guess in what we’re speaking about here is more around the understanding phase of the customer or the person using the products or services.  Just moving on, say, in the scenario that I had given you there, where greater understanding has arrived, and the organisation designs a better product and experience off the back of those insights.  Now, what I’m going to move onto is the execution of GDPR.  Just from speaking to people in the Slack channel for the podcast, I know from my own experience, it seems that a lot of websites and products and services are pushing the configuration for those executions onto the people using the products and services.  

Aleth: Yes.  

Gerry: I arrive on a new website and I get a pop-up and hit accept and then half the time I don’t even read it.  I know from reading a lot about GDPR, that’s not the desired experience.  

Aleth: Yes, you’re right.  It’s extremely surprising for me about how people can bend something very simple, which it is, it’s accepting, the premise was, don’t put cookies and other tracking stuff on people’s device without them accepting it.  It’s written black and white on the regulation, you should do it in an unobtrusive way.  All this pop-ups and things, which hide options, it’s not GDPR.  Really not.  

Gerry: How could they get consent in an unobstructed way, just looking at it from the perspective of a product or service, they’ll be like, “Well, we need to notify then, we need to alert them.  We don’t have any identification of them, so we can’t email them.”

Aleth: This thing is, there is this concept, which the GDPR built upon, which is the privacy by design framework, which states seven concepts and one of the concepts is privacy by default.  By default, people should not have to take any action to have the privacy respected.  Meaning, you should not have these popups saying: Accept to let us put some cookies and tracking.  This is not the way it should be.  Not only for cookies, but for example, in mobile app, which is very common, you download this mobile app and you have to accept a bunch of authorisations.  You should not have to do that.  By default, you should always default by the most privacy.  

Gerry: Basic privacy.  

Aleth: Yes.  If you think one step further, you understand that it is going to be very complicated for some organisations, which rely heavily on ads, because all of the ad system is based on spying on people.  

Gerry: Yes.  What are the things that we can do better at?  

Aleth: What I’ve seen, and it’s also stated very clearly is, do it by layering the information.  Meaning, you just provide enough information independent of the context.  So, the user using your service know just what they need to know.  If they need to know more, there is a link or some other way to have more information, but the basis, just provide just enough information.  You need an email, so let us know your email because we need it because we need to have conversation with you further down the line.  That’s all we need to know.  If you need more information, then maybe you need some ID or something more specific.  Just say, why do you need that?  

Gerry: Yes, it’s interesting because what I’m going to ask next is something that I know a lot of designers and developers have experienced first-hand.  Certainly, a lot more over the last maybe year/year and a half, since GDPR was implemented.  That is, when you’re designing new products or services and many instances of competing with IT departments, or technology departments and really challenging to get the very best experience for the people using the products or services.  

At the 11th hour, the legal person walks into the room and states that they need to do something different.  Suddenly, there’s no competition.  Legal trumps every argument in the building.  My question, and it’s probably a loaded question, but what role do you feel design can play when working with legal to prevent that from happening?  

Aleth: Yes, it’s a very good question.  I think everything is in your hand in the sense that you should have a good understanding of the GDPR, because of the way legal says things are like legal.  

Gerry: Yes, black and white, binary.  

Aleth: They have a consideration about legal risks and probability of being sued.  Say, don’t consider the user experience, so quality of the service, the business.  I think not only you as UX or service designer, but also developer, it must have a good understanding of the GDPR, so they can discuss with the legal, because at the end of the day, legal will not bring a user to your service.  Users are using the service.  

Gerry: Absolutely.  What are the implications if you don’t comply or if you’re caught out with some sort of non-compliance?

Aleth: Well, the implication can be very tough.  Well, it’s not if you are collecting email address and that sort of thing, let me tell you an example that happened in France this year.  It was a startup that was providing an STK for mobile application to collect location data.  This startup was selling this location data to other companies to show ads in the mobile app.  They were doing it without the consent of the people.  The [inaudible 00:25:27], which is the data protection authority in France put up a warning.  A warning was: Make it right or we will fine you.  It took the startup almost one year to put everything together and develop, in fact, a constant management platform.  

Gerry: Right.  

Aleth: It can be very tough.  It was a small company.  They did it.  They did it and they lifted some misdemeanours.  

Gerry: It was a huge setback for them?  

Aleth: Yes, sure, absolutely.  What is the risk?  If you are collecting very important data and you are not having the consent of people, where you don’t have the legal ground.  You have a sneaky business thing, it can be very risky.  Then after that, you can be fined, and fines are really huge.  It’s on purpose the fines are huge.  It’s because you want them to be effective.  

Gerry: Absolutely.  

Aleth: It’s not if you are collecting emails for a newsletter, you are not at risk, even if you don’t do it very right, but look at what kind of data you are collecting, what you do with it, and to which third-party you are disclosing it.  This kind of stuff.  

Gerry: Yes, so you’re not selling it and so forth, but being transparent.  

Aleth: Yes, absolutely.  

Gerry: Just going onto the last point, we’re nearly finished here now.  You mentioned about developers and designers learning more about GDPR, are there any books or websites that you’d recommend for people to familiarise themselves with to get more across GDPR?  

Aleth: Well, my website: gdprforus.eu has lots of resources, which is a good start, in fact.  I think there is some of my talk which are available on YouTube.  There are slides, slides of my talk are on my website.  In fact, I always say, just read GDPR, the first 14 chapters.  It’s not that complicated to read.  You can do it in two evenings or three evenings.  Just to have some understanding of what it is about.  

Gerry: What’s the website they go to get that from?  

Aleth: Just Google: GDPR.  

Gerry: Okay.  I’ll try and find that, and I’ll put a note in the show notes.  Aleth, thank you so much for your time.  

Aleth: Thank you, too, for having me.  I hope it’s a little clearer for all of your people.  Do not hesitate to ask question.  Even you can email me if you have some questions.  I always try to be as helpful as I can because I think this is a huge step for privacy and it’s going to be complicated for quite a long time to just be compliant.  

Gerry: Yes, I’ll put a link to your Twitter, as well, in the show notes, so people can reach out to you on Twitter, as well.   Aleth, thank you so much.  There you have it, thanks for listening to Bringing Design Closer.  If you want to learn more about the other shows on the This is HCD Network, feel free to visit: thisishcd.com, where you can also sign up to our newsletter or join our Slack channel, where you can connect with other human-centred design practitioners around the world.  Thanks for listening and see you next time.  

End of Audio