top of page

JOURNEY MAPPING

BACKGROUND

Government Digital Services (GDS) sits within the Cabinet Office of the UK Government.  Its job is to set standards of excellence in technology and digital for government, as well as look for ways to create digital transformation.

​

My role was to work as the lead user researcher within a small team at GDS, to discover how the government uses, stores, shares and safeguards personal data, and from there, to identify what can be done to optimise this.

​

The broad questions, at the beginning of the Discovery Phase, were :

1.

How are things currently done?

2.

What are the pain points for government services who handle this data?

3.

What unmet needs can we identify?  Can the process be easier?

4.

What standards and patterns are in place?

5.

Are there data owners?  Who are they?

APPROACH

My first goal was to dig into what GDS currently assumed, understood, knew/didn't know about personal data in government, and to capture these as potential avenues to explore more deeply.

 

These questions included areas such as :

​

  • Are there formal data owners/custodians?

  • How are things currently done?

  • What are the barriers?

  • What do the data journeys look like?

 

After scoping out my detailed research objectives, my first task was to dig into the existing data landscapes within government departments. As a team, we identified which government departments and agencies we would research in order to understand the data journeys, as well as the pain points, workarounds, current processes, dependencies and goals stakeholders experience with the way their data is collected, shared, stored, safeguarded and used in the course of their work.

objectives.png

Research Objectives

Using a combination of desk research, telephone interviews, meetings, and workshops, I sketched out multiple, complex data journeys within a large department and a smaller, arms-length body to map the impact and processes, and discover if there were common issues and patterns.  This information was captured in the form of infographics pinned to a wall so that stakeholders could understand these findings more readily, and fire questions and thoughts that led to deep dives of areas that needed more clarity (e.g. what happens inside XXX database? Who else uses this data, and so on.)

Journey mapping

Data Journey Infographics

In tandem with this, I spoke with multiple stakeholders and users of services and data across a range of services, to gain an in-depth understanding of the limitations and challenges around digitizing services. From this, we developed a clearer understanding of which areas of need were viable to explore, and what was beyond the boundaries of our ability to improve.

​

I met with third-party technology providers to understand their systems and limitations so that I could better understand:

 

  • How and why the data moving through these systems was cleaned and processed, and what the impact was down the line

  • How this was perceived and treated by users of this data along these journeys


I looked at the landscape and the journeys of personal data across multiple departments and agencies and their end-users to get insights into how the data was currently being used, stored and shared. 

 

Putting all of this data together, we identified a core cycle of data life-cycle patterns across government departments and pain points associated with each step of the process. 

Personal data lifecycle, user issues

Data Life Cycle and Pain Points

These insights enabled us to develop key findings, which led to 9 hypotheses and two propositions.

KEY FINDINGS

HYPOTHESES

PROPOSITIONS

KEY FINDINGS

​

Data Collection
​
  • Legislation can complicate data collection
 
Data Sharing
​
  • Data Sharing Agreements (DSAs) define the rules of engagement

  • User concerns about using other dept data include technical (downtime), process (data not up to date) and user experience (bulk data batches, usability etc) issues.

  • Accessing personal data that stakeholders, as a service team, didn’t collect, is difficult

  • Confidence in sharing data is only present where accountability is embedded in the service/product [and good data processes exist because of that]

  • There appear to be no clear drivers (benefits) to sharing one’s own “good” data and compelling reasons why departments don’t want to or can’t share their data (lack of faith in data, the perceived effort in setting it up, fear of risk and exposure, politics, lack of resources, legacy systems, process, etc.)

  • Managing and keeping track of consent, for data reuse, is challenging

  • While the research appeared to indicate that all departments we spoke to would like to have other department's data to improve their service, it was not always the case that they want to share their own data, for these identified reasons (further investigation may yield more)  :

    • Lack of faith in data and fear of liability 

    • Would other departments have any interest in the type of data they hold? 

    • Legacy storage issues that don’t allow them to share and/or upkeep data 

​

 

Data Quality

​

  • Refining (cleansing and reconciling) messy data is hard and there are a lot of things government currently does that makes it more difficult

​

Data Ownership

​

  • Data ownership isn’t clear and legacy systems and supplier lock-in sometimes make it harder to "own" the data

  • Without a formal data owner or custodian, there is :

    • Little or no accountability aside from internal assurance processes 

    • Fragmented ownership 

    • No formal drivers for data management 

    • No clear, common understanding of why the data is being collected, and how it relates to wider departmental goals 

    • Low confidence in sharing data 

    • Reliance on expensive third-party data matching, reconciling, and cleansing (which does not always result in “perfect” data) 

​

Personal Data Needs

​

  • For services, personal data often isn’t the end game. The end game is making decisions, like eligibility, that support service delivery

 

The findings led to the development of several hypotheses, which also indicated further areas for research.  From this, we were able to create two propositions that would guide the development of an Alpha product and point to further areas for research.

HYPOTHESES

  1. Eligibility assessments are a significant driver of services data reuse needs

  2. Services need a mechanism by which citizens and businesses can give permission to access information about them contained in other government data sources, in order to complete that transaction.

  3. Matching (as a mechanism for cleansing and reconciling data) is currently an expensive overhead. Supporting data reuse at (or closer to) the point of collection can reduce this cost significantly.

  4. The custodian of a set of data is not the same as a service manager of the service that uses or collects the data.

  5. The development of a shared governance regime to manage permissions, assurance levels for the data and establish standardised access.

  6. It is possible to decouple services and the underlying datastores.

  7. Assent by default, notification if possible, and transparency otherwise.

  8. Accountability is an important prerequisite for extensive reuse of personal data across services, and transparent audit trail capability is the best solution.

PROPOSITIONS

  1. It is possible to meet government’s data collection and access through a distributed, federated ecosystem of datastores, which upholds the mandate for no central database.

  2. It is possible to develop a system whereby, with appropriate assent and permissions, a service’s ability to reuse (citizen's and business's) personal data is not be impeded by departmental structure.

​

Both of these propositions pointed to further research into the current situation and pain points.

RISKS & OPPORTUNITIES

I created a scale that would identify who early adopters of the propositions might be. I took on the role of advocate and guardian of the user research findings, to ensure that all hypotheses were grounded in evidence.

 

From the propositions that we developed, I was then able to look at the risks and opportunities of developing these propositions, reminding stakeholders of the pain points and blockers existing within the current landscape, such as :

​

  • Technical setups

  • Business processes

  • Data principles & standards

  • Departmental structure

  • Resources

  • Policies & legislation

​

In addition, our propositions would not be a solution for all government departments and agencies, and we would have to focus our attention on departments that were already working on their own solutions.

The recommendation was to focus on one area (e.g. data ownership), and to conduct further research into what solutions individual departments were developing.


This led to the first opportunity, which was to discover what was already being done within departments or agencies that had already implemented successful data sharing/access, custodianship, and processes and standards. 

 

Further exploration was needed in order to gain insights into how they achieved this, what their pain points were, and if/where possible, how this could be extended, improved, standardised and scaled.

Another opportunity existed around the question ownership/custodianship of personal data. While the research showed that some departments may have believed that they had a private data custodian, there didn’t appear to be a consensual model of what the roles, responsibilities and standards were.

 

There was, therefore, an opportunity for GDS to clearly define this role (and the need for it) and to create a common pattern for accessing private data across government, that enables shared governance within a distributed ecosystem.

bottom of page