Skip to main content

We had to follow the data, not our users

Chiara Garattini and Kate Burn explain how working in our Data and Analytics sub-directorate has challenged the assumptions of our user-centred design team.

A big part of early work on projects typically involves helping our colleagues to focus a bit less on the characteristics of their products and the requirements of their internal processes, and to instead start by involving users to understand their needs.

Therefore, it's been interesting to work on projects that required our team to get deep into the weeds of the process in order to, ultimately, put the focus back on users. 

Decorative image of a crowd with hexagons joined by lines above them

Working with NHS data

We started working in Data and Analytics (at the time, part of NHS Digital) 3 years ago, at the height of the COVID-19 pandemic. NHS data played a vital role in the response to that national crisis – and continues to be central both to the future of our health and care system and the day-to-day delivery of services.

We are at the centre of this work: the “custodian of health and care data in England”. Sounds simple, but it actually encompasses a very wide range of processes and types of information, many touch points with many different people.

We first needed to understand what services we deliver, who uses each of them and what for. The answer from our colleagues very often seemed to be that our services are for "everyone", and that isn’t specific enough to be useful. When we dug further, the answer had become: "everyone who has a role in providing or using health data for the benefits of the public and the health and care system". Again, not an identifiable user group with actionable needs.

They needed different things from us depending on their task rather than necessarily on their roles and competencies.

We asked, "what are the tasks that people who use data for the benefit of the health and care system do?" and started coming up with various categories of people and their expertise. For example, data skills, technology proficiency and clinical knowledge. From there, we were able to get to some large categories of users, such as clinical and clerical staff, analysts and data specialists, scientists and researchers, and policy and service planners and decision makers.

But even this didn’t help as much as we expected. These user groups tended to crop up across the services we were seeking to understand. They had very different and discrete needs depending on where we encountered them.

Similar users were coming from a wide variety of different organisations, from academic research institutions, to service providers and commercial entities, and they needed different things from us depending on their task rather than necessarily on their roles and competencies. It wasn’t as simple as clinical and clerical staff needing one set of things from us, and academics needing something else.

Following the data

We took a different tack. Could we understand the process by following the thing we were working with? Instead of looking at the journey taken by the people using and interacting with our data, would looking at the data instead help us make sense of our services and users?

We started following what we called the life-course trajectory of the data. First, we looked at the birth and development of data. We mapped how it was created in a particular context; how some of this data was then submitted to us via different technical means and forms; how the data was stored, cleaned, curated, processed, and readied for use; how it was moved again in this new form into another place where it could be accessed and analysed; and finally, how it was transformed and published as different artefacts: dashboards, articles and visualisations.  

We mapped what we knew of the kinds of people inside and outside our organisation who were involved at each of these stages. Who were they? What were their skills? What were their needs?


Using the insights gained from this detailed investigation, we were able to establish that we had 4 large service areas:

  1.  Data provision and ingestion
  2.  Data transformation and curation
  3.  Data access provision and dissemination
  4.  Data-outputs publication

A new operating model was implemented in 2022 with these 4 areas at its backbone and our technical colleagues responded well to the division. We started making headway in our conversations: "Yes, now I can tell you who our users are for this and for that area of service" is what we started to hear.

Returning to our users

We are aware that our focus on the data and its journey raised the risk of designing services and making technology decisions that would benefit the data, its quality, its speed, and its timeliness over actual benefits to users. In the end, the goal must be to focus on what people need.

By following the data and mapping where it flows through our organisation, we were able to establish a common view among senior stakeholders and service owners of what our services are, where they start and end, which products they involve, and who uses these services for what. This map became a go-to tool to agree and communicate where work sat. It allowed colleagues with different expertise and perspectives to come together and coordinate efforts to deliver great data services that will increase the potential for data to save lives.   

Health data is wonderfully complex, and working and designing for it – and with it – is hard. A lot of things are fixed or unchangeable and trying to do user-centred design in this area can sometimes be confusing and even overwhelming. But it is important, interesting, and fascinating work and critical to the future of our health and care system.

This content was first presented at the SDinGov 2023 conference.


Last edited: 27 March 2024 3:21 pm