Design for data
‘Design with data’ is a pretty compelling principle. But we also need to design for data. The relationship between our models for data storage and access are inextricably linked to the services themselves: the database designs the service, the service designs the database. When designing services, we need to understand the material we’re working with to design the right thing.
So we need to think much more about what data services collect, what needs that data meets, how permissions should work and what other services might need that data — and we need to do that thinking right from the start.
I’ve been talking to a bunch of people about this recently, including Harry Trimble from the Government Digital Service. Here are some of the principles we’ve started using as we design for data.
1 Keep other services in mind
Services rely on other services’ data to work. We’ve all been in the situation when we cannot update, renew, check, prove or cancel something, due to a lost reference number, missing computer records, an expired password and so on. These are often frustrating services to use. They don’t have to be.
The reason for these frustrating services is often because of the service that first made the data: getting a licence, registering a thing, setting up an account. Part of this challenge is technical, but most of the challenge is in learning more about how and when users will next use their data. Knowing this will mean more informed decisions as to what data your service collects; what its data infrastructure is; its consent models for using data.
People are already working like this: the UK Government is changing how it’s fishing licences work. The team are looking at how fishing licences are checked, updated and renewed, to inform the design of how users’ licences are issued and stored in the first place. Let’s be more like this team and make it easy for users to access their own data, when they need it.
2 Collect minimum viable data
A service is not a marketing tool. Services meet users’ needs. Statistics are not a user need. If having some user’s data doesn’t meet their needs, a service shouldn’t collect it.
Working at the NHS Gambling Clinic, an Alpha asking-for-help service was made and it needed to do two things: One get a user’s contact details so a face-to-face assessment can be booked. Two, know if a user’s might harm themselves or others. The service asks for about gender, sexuality, relationship status, disability. Does knowing someone’s gender help delivery of this service?
The more personal data a service collects, the more complicated it is to make and the more expensive it is to build and maintain. Services should collect just enough data, no more.
3 Be transparent
Services should be transparent about what data is being collected, used and stored about its users and why. Is the data essential for the transaction to be completed? Is the data being shared with other organisations or services? If so, for what purpose?
A step further would be for organisations to publish open data about the way their services use data about their users and the impact it’s having. Millions of engaged users is the best protection that users have against misuse of their data.
As more organisations look to using machine learning to provide better services, being transparent about the data they use and being accountable for it is really important.
4 Get consent
The data type a service collects changes the consent model it should use. The ODI’s data spectrum groups data into three different types: private, shared and open data. It’s useful because it begins to unpack what access should be given to different types of data and, therefore, what design pattern should be used to get permission to use or share that data.
This links back to what the user needs were to collect the data in the first place. A good example of this sharing your driving licence – users can share a one time code to their driving licence that’s valid for 21 days. It’s useful in many situations, for example when you go abroad you should only need to give a car hire company access to your licence to cover the time you’re hiring a car. Using better consent models with attributes like expiry times means that services can meet more user needs and users have greater control of their data. Services can give users access to the right data at the right time.
5 Put users in control of their data
Services should be designed so that users can stop sharing their data, or revoke access to their data. A simple example of this is the sharing function in Google Drive that lets users remove other users from a shared folder or change the sharing status of a link.
It’s in moments of change like moving house, going through a divorce or experiencing the death of a loved one where the needs of a user change. In a digital age, those needs often link back to their data. For instance, to stop sharing a bank account with an ex-partner or remove certain levels of access. Services should be designed around those moments, to help users make the best decisions and meet their needs. It means that services must be connected to what’s possible with the underlying technology.
6 Separate the data
Separate data from transactions and services. Go one further; separate different types of data. Separate data about things from data about people. For example, separate fishing licence numbers from contact details, this would make licences faster, simpler and securer to check and renew. You can check if a car is safe to drive, without having to view the owner’s address. Let do more of this.
Separating services and data will mean meeting more user needs. Separating open and private data will mean meeting more still.
How users join up these separate parts when they need to is the next tricky bit.
We think these principles begin to unpack how we can design data-driven services that understand, and are responsive to, user needs. The next step is to put this thinking into practise, so we can find out about the principles we don’t know we need yet.