30 Jun 2014

Approaching Design

By Lily

When we talk about “Tech for Good” we are often talking about technology that makes the delivery of essential public services such as education and healthcare better and more accessible. However the mix of technology and public services has a long, dark history of  shadowy contractors and many many millions of public money wasted on creaky and inflexible technology. These services:

  1. Don’t get used
  2. (Because) They take no account of the context of their users
  3. (And) Are not properly understood by the providers of the service.

I’ve been reading a lot about design and public services this week, Future Gov, GDS and Snook have some excellent blogs on the subject. It’s something that many of the teams that come to us have to learn fast.

So how can we ensure our teams are building technology that avoids these traps? One of the things we spend a lot of time probing for when selecting teams is their design approach.

This is not about the appearance of their website but whether we think that they will spend time learning every last thing about their users: not just demographics, but their routines, their likes and dislikes and their needs. Will they build something that is genuinely appropriate for the technology owned by the user group they are targeting? Will they continue to test their products from first iteration to long after the launch?

If you’re about to embark on building something (pretty much anything) here are some good ways to get started:

  1. Talk to the people you think might be your users. Lots. Be patient and open, have conversations without agendas. Go to them, wherever that may be in their homes, community centres. Spend time in unglamourous places (hospital waiting rooms, community centres, the street).
  2. New perspectives are important, but don’t underestimate the power of local knowledge and experience. However well you think you might understand the problem you are trying to solve, there are probably things you are missing. Listen carefully and talk as little as possible.
  3. Record your findings – if possible with a voice recorder rather than taking notes, this means you are getting the whole story not just the bits you have decided are important, you might discover, playing it back, key information that you weren’t expecting.

But what are you actually talking about? Here are three important bits of information to get from your users:

    1. What is the need? This normally doesn’t involve asking “Is X a problem for you? – but talking about their issues and routines more generally. Watching their body language as well as what they say. Being very aware of confirmation bias coupled with the fact people are apt to tell you want they think you want to hear.
    2. Understand the context in which this need exists. ie what technology do your users own and understand? What space do they have in their daily routine to make use of your solution? What touchpoints can your solution tap into that will be most accessible to them?
    3. Remember to ask if you can you come back to them for more information later. Once you’ve built something go back and test it with these people. You can find some great tips on how to do this from Alice Tyler.

Once you have this information you can build vastly improved products and services. When you have a really good understanding of your users your solutions can become not only useful and relevant but something that fits seamlessly into their lives, and makes those lives noticeably better. Something that is easy, accessible and delightful, something that people actually enjoy using.

  • Photo from GDS flikr, drawing by Paul Downey