← All writing
Policy · · 7 min

GDPR is a design brief

Several clauses in here are interface requirements wearing a legal hat. The audit turns out to be the actual deliverable.

Privacy Forms

Friday is the deadline and my inbox has been extraordinary. 41 emails in one day this week, all variations on “we’ve updated our privacy policy” and “we’d hate to lose you,” from companies I could not pick out of a lineup. One of them was a skip hire firm in a county I’ve never been to.

Which is funny, and it’s also the clearest possible demonstration of what’s gone wrong with how this has been handled, because every one of those emails is an organization discovering, three weeks before a deadline, that it has no idea who’s on its list or why.

I’ve spent a decent chunk of this year on this with clients, all of it as the person building the thing rather than the person advising on the law, and the thing I keep wanting to say in meetings is that most of what’s being asked for here is not a legal question. It’s a set of statements about interfaces, and I’m the one who builds those.

I should say plainly, and I mean it rather than saying it to be safe, that I’m a developer and not a lawyer, that none of this is advice, and that what any given business actually has to do depends on things about that business I’m not qualified to assess.

The law is mostly a list of UI requirements

Strip out the parts about lawful bases and processors and transfers, which are genuinely legal questions, and look at what the regulation says about consent specifically. It has to be freely given. Specific. Informed. Unambiguous, given by a clear affirmative action. Granular, so separate purposes get separate consent. As easy to withdraw as it was to give. And you have to be able to show that you got it.

Read that list again as a brief for a form and it’s completely unremarkable. No pre-ticked boxes. No bundling four things into one tick. Plain language rather than a link to a PDF. Separate checkboxes for separate things. An unsubscribe that works in one step. A record of what was agreed and when.

Read the consent clauses as a brief for a form rather than as law, and they're completely unremarkable. Most of them are things a decent designer would have argued for anyway.

Almost all of that is stuff I’ve argued for on projects and lost, on the grounds that a pre-ticked box converts better. It does convert better. It converts better because it collects people who didn’t agree to anything, and a list full of those people is what produced 41 emails in my inbox this week.

Unticked, unbundled, in words

Concretely, the change on most of the forms I’ve worked on this spring:

signup.html
<!-- before -->
<input type="checkbox" name="marketing" checked>
<label>Keep me updated with news, offers and information from our partners</label>

<!-- after -->
<input type="checkbox" id="email-offers" name="email-offers">
<label for="email-offers">Email me about offers, about once a month</label>

<input type="checkbox" id="post-catalog" name="post-catalog">
<label for="post-catalog">Post me the spring catalog</label>
HTML

Three differences and each one is a decision somebody had to make. The box is empty, so ticking it is an act. The two purposes are separate, because “news, offers and information from our partners” is three things and “our partners” is a sentence doing a lot of hiding. And the copy says roughly how often, because “informed” is the word in the regulation and a person cannot be informed by the word “updates.”

The other half of it is that transactional email is not marketing. “Your order has shipped” doesn’t need a tick and never did, and I’ve watched more than one client nearly stop sending order confirmations out of panic. Separating those two in the system was a bigger job on most projects than anything on the front end.

Minimization is a form-design principle

The bit I’ve enjoyed most, and the bit I’d keep even if the law vanished tomorrow, is data minimization. You collect what you need for the purpose, and nothing else.

Which is a design instruction, and it’s the one I’ve been trying to give clients for years with no leverage at all. Why is date of birth on the newsletter form. Why is there a phone number field on a contact form when nobody has ever rung anyone back. Why does the inquiry form ask for a full postal address when the inquiry is “do you do evening classes.”

Every field you don’t collect is a field you don’t have to store, secure, disclose on request, or delete on request. It is also, and this is the part that gets it signed off, a field the user doesn’t have to fill in, and shorter forms convert better. That’s a rare case where the compliance answer and the commercial answer are the same answer, and I’ve used it fairly shamelessly.

The audit is the actual deliverable

Here’s what the work has really been. Not the banner, not the policy page. Sitting down with a client and writing a list of every piece of data the site collects, where it goes, and who else can see it.

Nearly every client has been surprised by their own list. Not because they were hiding anything, but because a website accumulates third parties like a coat accumulates pockets. The analytics. The heatmap tool someone trialed in 2016 and never removed. The chat widget. The font service. The two ad pixels marketing added directly through the tag manager without telling anyone. The embedded map. The embedded video, which sets cookies on load whether or not anyone presses play.

That list is a useful artifact and it has changed things on every project where we’ve made one, usually by deleting three or four things nobody could explain. I’d now do this on any project regardless of regulation, and I’d charge for it, because it’s the only document anyone has that says what the site actually does.

What I think is theater

Plenty, honestly.

The re-permission emails, mostly. If you had valid consent you didn’t need to send one, and if you didn’t, emailing the list you shouldn’t have is a strange way to fix it.

The consultants who’ve been selling small businesses a compliance package with a DPO appointment in it. A florist with a contact form does not need what a bank needs, and the regulation is scaled, and a lot of fear has been converted into invoices this year.

And the banner, which is a whole thing in itself and which I’ve been getting increasingly grim about, so I’ll write that one separately once I’ve calmed down.

What I hope survives

The deadline is on Friday and roughly nothing will happen on Saturday. There’ll be no wave of enforcement against small firms, the sky won’t fall, and in a year most of the panic will look silly.

What I hope survives is the audit habit, because writing down what your site collects is the sort of thing that’s obviously correct and that nobody had a reason to do before. It took a regulation to make anybody spend an afternoon on it, which is a bit of an indictment, but I’ll take the afternoon.

Read similar posts
6 min

The input types nobody uses

A 60 KB JavaScript date picker, and a plain text input for the phone number. Exactly the wrong way round in both cases, and the most common configuration I see.

7 min

Analytics is a moral question

Everybody spent this summer migrating their analytics. Across four client projects, nobody once asked whether we should be collecting any of it. The question on the table was how.