Researching with service teams at Trust & Design #0
To find out what do next we’ve spoken to people building services, everything from charities to startups to government to international companies. Here’s what we’ve found out so far.
The group picks the pattern
Privacy, security and transparency decisions are made by groups. I hesitate to say ‘teams’ as everyone involved doesn’t always fit the typical idea of a service team. Yes, sometimes it is a team of researchers, developers, designers, product managers working in the same space each day. But often the whole group is larger and more distributed. It might include lawyers, central security teams, information governance officers, policy advisers and so on.
The nature of these decisions varies too. Sometimes it’s more collaborative, with different disciplines working together to find what works. That might include teams working in an agile way, meaning people building services are more empowered to make decisions. Other times decisions will be made centrally for the people building a service to follow. That also has advantages, including things like consistency and saving time.
Any tool we build should account for these different situations. It should help inform discussions and decisions, or help people challenge others about how to build trust into their service. But it should also be useful for scaling what works within an organisation.
People copy patterns they trust
There’s no bigger sign a pattern is trustworthy than seeing it live in a service. Nearly everyone we spoke to told us this. When we asked people what makes a good pattern, or where they find them, people told us they just copy what other services do.
Not only that, but people building services are busy. They make hard decisions pretty quickly. Easy, widely-used patterns will often win-out against taking time to work out a different approach. If a pattern is harder or slower to build than, say, terms and conditions or passwords, it won’t be used.
Privacy and security norms are really important too. People making services look at competitors or similar services to see what users expect (and what their peers are willing to try). As security and privacy is taken so seriously, there’s less experimentation and testing to find what works best or iterate what’s already out there.
This means that people need to see patterns elsewhere before they adopt them. We need to make that part of what we build.
It also highlights that people building services don’t just need a tool, but time and space to show and discuss new patterns as they emerge. Which is exactly what the Trust & Design meetup is for.
Patterns combine design and technology decisions
Unlike other design patterns, most privacy and security patterns come with technology decisions. For example how can you have a pattern for private messaging without including asymmetric encryption and public-private key pairs? You can’t.
During our research some people said they wouldn’t use a pattern unless they knew how the technology behind it works. They needed all this information to compare their options. Doing this now can be very hard.
This tells us that whatever we build has to help people compare technology and design approaches.
What patterns we need
We’ve also been reflecting on the Data Permission Catalogue we released last year. What’s missing, and how might it be organised into themes or problems?
Internal consent workshop at IF
What we found is that there are quite a few patterns missing. These range from intangible interfaces and data portability, and options for two factor authentication and consenting on someone’s behalf to off-line patterns like document shredding.
This also showed us that people are rarely try to solve just a privacy problem or transparency one. That patterns and the place they live needs to helps teams think about transparency, accountability, security and privacy in relation to each other.
Prototyping and testing our assumptions
We’ve got a pretty clear direction about what to explore next. We’re going to build some prototypes, including:
- Single pages for each pattern
- Categorising patterns by the problem they solve
- Links to research that support each pattern
- Case studies of live services where patterns are used
- Technical information
- Development history for a pattern
- Challenge pages for problems still without patterns
Over the next couple of months we’ll be taking these prototypes to several events and service teams so we can learn how to iterate them.
If you’re interested in trying the prototypes and helping us improve then, I’d love to hear from you - email@example.com