From a series of posts on making digital services worth trusting. This is 2 of 3 in a collection of posts looking at permissions as a key part of a trustworthy service. In this post I describe what we’ve learnt at IF about how to design permissions that give people agency.
People should have agency over how data about them is collected and used.
At IF we’ve been collating and publishing a catalogue of patterns for data sharing since 2016. We’ve created it because tech teams need new, practical, patterns if we want to see more trustworthy services.
We frequently design new patterns in our work for clients. I’ve illustrated examples of best practises that bring to life some of the hard problems around data, privacy and design. They’re not meant to be ‘right’; they’re meant to provoke conversations that spur action.
Here’s our list of best practises so far:
1. Permissions should be part of the design of the service
a. How you ask people for permission needs to be context specific. Consent and transparency are part of the design of a service, not an additional thing.
b. Meet people where they are, whether that be over a digital channel or a paper one. People’s journey may start with a check-in screen, continue on mobile and finish on paper.
2. Present people with real choice
a. No dark patterns or nudges. How the service uses data shouldn’t be hidden away.
b. Rather than one all-or-nothing choice, permissions need to be broken down and separated. People should be able to grant access to some data while keeping other data private.
c. Giving permission should be a positive action. There’s no default assumption of consent until users untick a box.
3. People change their minds - design for that
a. Digital channels should make it easy for a user to say yes or no, and change their mind later
b. It’s clear how to object to the process
4. Make software that explains what’s happening
a. The pattern should be informative, intuitive and easy to understand.
b. Personalised according to individual preferences to help the user understand what the data could be used to do.
c. Consent to access data is requested in an appropriate context, both to prevent overwhelming users’ decisions when onboarding, and to make clear why this specific access is needed at this time.
d. Consistent, without being uniform.
e. Gives information about what’s happening at point of use
5. Design for minimalist and non-permanent data use
a. Gathers the least amount of data that will allow the service to function as needed.
b. Doesn’t get in the way of any user.
c. Can be revoked.
d. Makes it clear that data is not held indefinitely.
e. Enable digital proofs, over data sharing.
6. Design for relationships, not just ‘the user’
a. Not everyone is in a position to make informed choices about what happens to data about them, so give the choice to delegate decision making to trusted third parties.
b. Support people acting on someone else’s behalf.
c. Considers data that represents multiple people.
d. Protects a vulnerable user.
7. Create evidence that addresses power imbalances
a. Help people understand what happened to data about them for a given event and to help them make changes later.
b. Keeping a record of the permissions process means the organisation can’t later deny it happened.
c. Should become part of how a service is measured.
d. Tell people what difference they made by choosing to share data.
8. Design to support people’s rights over data
a. Helps people access and use their rights, especially those from GDPR
b. Lets people set boundaries that are good for them
At IF, we think it’s crucial that permissions are designed intentionally, as part of services. Privacy shouldn’t be a luxury only few can afford or choose.
To enable this, as a community of technologists and designers, we need more invention and play to make permission patterns that create services respect people’s rights. There are some examples of best practises here, but it should be the norm, not the exception. The prize? Services that people understand and are empowered by.
In the next and final permissions post, I describe a possible future.