From a series of posts on making digital services worth trusting. In this post I describe why intelligibility and understanding are important design constraints.
Right now, companies usually prioritise making services easy to use. Information about how data is collected and used is frequently hidden in places where it’s unlikely to be read, let alone fully understood.
This is unsustainable. What can teams do instead?
5 questions to answer in interfaces
At IF, we think how and why a service uses data should be visible in the interface. People should be able to understand what’s going on in the background. (I’ll write about what kinds of data I think should be available in another post.) We believe that making the flow of data intelligible and understandable can challenge where power sits.
Here are some questions we think are worth answering:
How does the service make money? This tells people the true value exchange taking place. If the company’s business model is to sell data, they’ll likely be looking for opportunities to collect more of it.
How does the service make decisions? Making this clear at the point of use helps people understand how the service works. This is especially true for services that use automated decisions. Prototypes we made with the London School of Economics made it clear how Flock calculated insurance quotes.
Has training data been tested for bias? Publishing the results of bias checks is increasingly important as more critical services are digitised and data dependent.
How will data be used? Informing and reassuring people how data about them will be used, and what options or opportunities they have to change that. For us at IF, this is basic data hygiene in service design.
What policies or laws apply to this service? Legal frameworks may apply to both private and government services. Understanding these can help give people agency over the services. Under GDPR rules, individuals have the right to data portability. IF prototyped some examples, for the ODI, of how portability rights could be exposed to people throughout a service - including at times when people’s rights compete.
When should you explain?
TL; DR: in the user journey.
This means testing prototypes, and taking into account users with various incentives, accessibility needs and degrees of digital literacy. Those prototypes may not be exclusively screen based, for instance posters or letters.
Sometimes, making services understandable needs the right words in the right place, or a particular visual emphasis. It might involve designing to “expose the seams” as we tested while designing a fictional mental health chatbot with innovation studio Comuzi.
What do we test next?
These sorts of questions are a good start, and getting it right isn’t easy. We need, as an industry, more ways and opportunities to test the right moments to explain to users how services collect, use and store information about them. We can start to do these in short sprints, but knowing how much friction to introduce is going to take sustained use, in live services.
Thanks to Jess Holland and Ella Fitzsimmons for their work on this post.