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.

Using counterfactual explanations to show how different wind speeds and weather conditions could have contributed to a cheaper quote Image by (IF: CC-BY)
  • 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.

If data describes multiple people, what happens when their GDPR rights compete? And how do product teams design for those cases? ‘Friendshare’ is a prototype social media service from a report IF did with the ODI last year that explores the right to data portability, when data describes multiple people.

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.

Also from IF’s report on data portability with the ODI, this prototype is a letter telling a resident their data has been deleted when they move house.

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.

Using text wrapping and underlining to acknowledge key points of data entry is an example of ‘exposing the seams’ and showing the inner workings of an automated decision. (IF: CC-BY)

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.