Legal documents should not be written by lawyers for lawyers; they should be useful, engaging and designed for the end user. But it seemed that we weren’t the only ones to think this. When we read the regulations, it turned out the EU agreed.
Here’s how we did it.
Step 1: framing the problem
When it comes to privacy notices, the requirements of GDPR are heavy and the consequences of non-compliance enormous (potentially 4% of annual turnover). We knew therefore that there would be an inherent tension between making the policy engaging and readable, and at the same time robust and legally watertight.
Lawyers know that when it comes to legal drafting, it’s much harder to be concise than wordy. Specifically, it’s much harder to be concise and preserve legal meaning than it is to be wordy. But the fact remains. Privacy notices are suffered as downside risk protections or compliance items, rather than embraced as important customer communications at key touchpoints. So how to marry the two?
Step 2: changing the design process
We took issue with two things. First, it seems unusual that lawyers are the only people internally with significant input into the process. No marketing, no content editors, no designers. Second, we found that businesses are almost never crunching data on usage of privacy policies or, better, just asking readers of the policy for feedback. The changes under GDPR need attention from legal, but there is a more fundamental design challenge at play.
Rather than the standard process, we decided to start with the end user and work backwards and started a design sprint (more about this here on our privacy notice with multiple iterations, rapid prototyping and user testing.
Similarly, this was not going to be a process just for lawyers. We put together a multi-disciplinary team co-led by me and, legal information designer Stefania Passera, with input from our legal counsel Adam, Tom (our head of content), Alice (our marketing manager) and Anton (our front-end developer).
Interested in a design-first contracts solution? Request a demo
Step 3: choosing design patterns
We made too many design decisions in the process to mention here. But here are three that we think made a difference:
Problem 1: general information overload
Solution: layering information
One of the first things we learned was that most users of privacy policies feel overwhelmed by the sheer quantity of information in them. Forget the legalese, forget the small print – quantity alone sends readers to sleep. According to researchers from Carnegie Mellon university, if people actually read all terms and conditions they’ve had to accept in their lifetime, it would take an estimated 76 days. Model that out for privacy notices and it’s a similarly life draining number.
Problem 2: what the hell are you talking about?
Solution: conveying meaning through icons
With this in mind, we built a set of icons that we thought would enhance our customer’s understanding of our privacy notice in both the summary and the full policy.
It was actually fairly easy to find a nice icon set but it was hard to find exactlythe right icon – icons that would genuinely enhance meaning. So we asked people. Typically we showed at least 2 examples of potential icons to user testers and asked them to choose what made the most sense to them (example below). Sometimes these results were decisive and where there was a tie in the number of votes, it just required some judgement from us.
Problem 3: when is my data collected?
Solution: privacy journey diagram
We started reimagining this process of data collection as a ‘privacy journey’, starting with the very first time you land on our website and ending when you leave the Juro service (though we hope this doesn’t often happen) and this informed our choice of design pattern (inspired by Margaret Hagan and Helena Haapio). Here’s an early sketch of our thinking, showing the sequential nature of where data is collected.
The real ‘light bulb’ moment came when we realised that there were in fact two clear tracts of data collection happening in parallel: data that our customers actively give to us and data that is passively collected automatically. If we could show both, could we give a snapshot to our users of what their ‘privacy journey’ with Juro might look like?
Step 4: user testing
The Article 29 working group recently put out guidance around what constitutes transparency. “In advance of ‘going live’, data controllers may wish to trial different modalities by way of user testing (e.g. hall tests) to seek feedback on how accessible, understandable and easy to use the proposed measure is for users”, they say.
Some like Marie Pôtel-Saville were both users and legal design experts (bonus!) and she and I are hosting a free webinar on this topic on 18 May (details here).
Step 5: iterate
Doing this well is really hard and we made lots and lots of mistakes. You’ve got to be humble about your assumptions and just try some stuff out (which is something we as lawyers rarely have the luxury of doing). Make no mistake, this is time-consuming work and it can be quite a rabbit hole without good discipline and a clear structure to the process. But rapid prototyping and learning from these mistakes is what can really drive good design outcomes.
This article was originally published here by ArtificialLawyer.