Data infrastructure is about building the foundations for the way government uses data. Not just now, but in the future. This work deals with some very technical, system-level infrastructure, so why are we doing user research? Surely you only need to worry about that for citizen-facing services?
Well, no. Whatever you build, wherever you build it, there will be always be users, be they citizens or other people working in government. And if the service doesn’t meet user needs, it will fail. There are a few risks with data infrastructure in particular. We’ve found that if you don’t take account of the diverse needs of users across government, you risk making dangerous assumptions. It’s easy to start building for an idealised data future, rather than the reality of how data is actually being used today.
In this post, I wanted to share 5 lessons we’ve learnt about making data infrastructure user-centred.
Most government service teams don’t really care about data, they care about their service
If we want to get people to change their data habits and use the new pieces of data infrastructure we’re building, such as open registers, we can’t just tell them to do it. We need to show people how we can help them to improve their service. Understanding this means that we’re learning to make the infrastructure relevant and adoptable because it addresses the real-life problems that services face, rather than just asserting how we’d like people to be using data. That would be our need, not theirs.
Sourcing and updating data still relies on people
We’d all love to think that there’s a world of fancy data updates and verification processes magically operating somewhere in government. The reality is, finding and updating data still relies on people talking to people. If someone wants reference data, such as a list of prisons, they’ll probably ask someone in their team. If we don’t take account of this behaviour among users, we impede their chances of finding and using the data sources we’re developing.
In government, spreadsheets are the default model for data
Microsoft Excel is everywhere in government. Most civil servants aren’t using specialised data formats. They’re looking at data in Excel. So when they are searching for and investigating whether a dataset is useful to them, they need to see it in a way they’re used to: a spreadsheet. Even if the underlying structures we’re creating are richer and more flexible, we’ve learnt that spreadsheets need to be an option for users who prefer to consume data in this format.
Use metadata sparingly
We thought it would be a great idea to include helpful metadata, so users understand the data before they use it. If you’re unfamiliar with the term, metadata is data about data, such as who created it or why it was created. But most users prefer to see the actual data first before finding out more about the dataset. They may want to see a small amount of specific metadata, like who created the data and when it was updated. But mostly it’s about checking out the data first. Showing users too much metadata upfront is overwhelming and doesn’t reflect how they assess the value of datasets.
Using any third-party data source is about balancing risk and reward
Most services rely on data. However when teams store their own copies of data, such as lists of prisons or schools, it can be difficult to keep it up to date. Out of date data can lead to a poor service experience. So data specialists advocate fetching data from reliable sources using automated services like APIs (application programming interfaces). However, during our research we found many service teams still prefer to store their own copies of data. Understanding this has altered how we serve data in our services. For example, with open registers, users can choose to download the latest copy of a register rather than use the API. This gives them the benefits of using up-to-date data, without any risk.
Does any of this sound familiar?
If you’re building services with data, we’d love to know if these lessons resonate with you. Equally, if you’re using external data in your service, either open or from another government department, we’d love to speak to you to make sure the infrastructure we’re building meets your needs. Get in touch via email.
Follow GDS on Twitter, and don’t forget to sign up for email alerts.
5 comments
Comment by Sian Thomas posted on
Cliff, this is really interesting. In the Food Standards Agency we have very close links between those responsible for data and Information and Knowledge Management. They are all my teams! After all, the whole point of data is to generate tangible insight and knowledge that can be acted upon.
Comment by cliff van dort posted on
the synergies with the provision of library and information services today is spooky! We could have a lot to learn from each other.
Providing services/resources for the user and not for us is a lesson we have had to learn and are still learning, so it will be interesting to see what you come up with.
Is a list of prisons information or data!? Previously libraries would have stored such information in a directory. Are the entries in who's who information or data? There is a very close line between the two. Should there be more collaboration between data, information and knowledge practitioners?
Comment by Theo Chapple posted on
I work for TfL and part of my role is product manager for our open data services. One of our challenges is to get teams who are commissioning and designing new systems that generate data to think about the potential customer-facing use cases for that data. All too often they are focused on their operational need (understandably perhaps) and don't always take into account the needs of those using our open data products for customer facing tools like Citymapper or the plethora of bus apps. We end up applying logic and "sticking plasters" when data is ingested into our API so it "just works" for our users... which isn't the most efficient way of doing things. Would be interesting to know if you have similar challenges and what you've done to mitigate them.
Comment by GDS team posted on
Hi Theo,
Thanks for your comment. We have seen this in our own research and in many cases, government departments or organisations want to meet the needs of those using open data, but are held back by technical or process problems. Sometimes those teams aren't even aware of what openness means and its benefits. We also often find that they don't have capacity to do research with their own end users and the result is that those user needs are not often met.
This is something that the data.gov.uk team, in particular, is looking at. This team is focused on improving how open data is published, found and used. The team would love to chat to you about your work at TfL to share ideas and research. Please reply to this comment if you’re happy for one of us to get in touch with you directly.
Comment by Elspeth Body posted on
This definitely resonates - from my experience, users like to feel like the data is something tangible (hence the desire to have their own local copy). We've also got to remember when designing systems to collect, hold and disseminate data that different users have different requirements of the same dataset, and these can conflict and change over time. There will never be a perfect, seamless solution... (can keep wishing though)