Enhancing a Government service through data-driven decision-making

Better data does not automatically lead to better services. Government organisations often hold large amounts of information, but the real challenge is understanding what that information means, how it relates to user behaviour and operational activity, and how it can be used to make better decisions.

Our consultancy supported a government organisation to improve the way it used data to understand and manage an important public service. The work combined business analysis, user research, service design and data-led decision-making to create a clearer view of how the service was performing and where improvements would have the greatest value.

The project was not simply about creating a better dashboard or introducing new reporting. The central question was more fundamental: how could the organisation use evidence to understand its service better and make better decisions about what to change?

That distinction shaped the entire engagement.

Project Overview

The organisation operated a government service supporting a large and diverse user population. Like many public services, it had evolved over time in response to changing policy, operational requirements and user needs. As a result, information about the service was distributed across different systems, processes and teams.

The organisation had access to considerable amounts of data, but this did not always translate into a clear understanding of service performance. Different teams could have different views of what the data meant, while information about user behaviour and operational activity was not always connected.

Our consultancy was brought in to help establish a stronger evidence base for decision-making and identify opportunities to improve the service.

The engagement brought together business analysis, user research and service design. Rather than starting with a predetermined technical solution, we worked with the organisation to understand the service from several perspectives: the people using it, the teams delivering it, the processes supporting it and the data generated throughout the service.

This was important because the data itself was only one part of the problem. We needed to understand the context around it.

The work ran across discovery and subsequent design activity, with our team working alongside the organisation’s subject matter experts, operational teams and decision-makers. This collaborative approach meant that findings could be tested and challenged as the work progressed rather than being presented as recommendations at the end of the engagement.

“The consultancy team became part of our delivery team very quickly. They took the time to understand how we worked, built strong relationships with colleagues across the service and brought their expertise without imposing an external way of working. By the end of the engagement, it felt like we had strengthened our own team rather than simply brought in additional resource.”

Service Owner

The Problem

The organisation’s challenge was not a lack of data. It was a lack of shared understanding.

Information existed across multiple sources and was being used for different purposes. Operational teams needed information to manage day-to-day activity. Service teams needed to understand where users were experiencing difficulty. Senior stakeholders needed evidence to understand whether the service was achieving its intended outcomes. Policy teams needed confidence that decisions were based on a reliable picture of what was happening in practice.

These needs were connected, but they were not always being considered together.

This created several challenges. It could take time to establish what was happening within the service, different measures could provide apparently conflicting perspectives, and identifying the cause of a problem was not always straightforward.

A metric might show that completion rates were falling, for example, but the metric alone could not explain why. The underlying issue could have been a change in user behaviour, a problem within a particular part of the journey, an operational constraint or a change in the way information was being recorded.

This is where our user-centred approach became particularly important.

We did not treat users as an additional source of information to be considered alongside the data. We used research to understand the behaviours and experiences behind the data.

That distinction helped the team move from asking “What is happening?” to asking “Why is this happening, and what should we do about it?”

Research and Discovery

We began by building a shared understanding of the existing service.

Our business analysts worked with stakeholders and operational teams to understand the processes, business rules, systems and dependencies involved. At the same time, our user researchers explored how people actually experienced the service.

This combination was deliberate. A process map can show how an organisation believes a service works. User research can show how it works for the people using it. Data can show what is happening at scale. Bringing those perspectives together provides a much stronger basis for decision-making.

We mapped the service end to end, identifying key stages, actors, systems, information flows and points where users or operational teams could encounter difficulty.

User research then allowed us to investigate some of these areas in greater depth. We spoke to users and stakeholders, reviewed existing evidence and explored the behaviours and circumstances that influenced how people interacted with the service.

The research did not simply produce a collection of user quotes. We looked for patterns.

Where were users having to repeat information? Where did they need to interpret terminology or make decisions without enough context? Which parts of the journey created uncertainty? Where were operational teams compensating for weaknesses in the service through manual intervention?

These findings were then considered alongside the available service data.

This was one of the most valuable parts of the work because it allowed us to challenge assumptions on both sides. A high volume of activity did not necessarily indicate a successful service. Conversely, a low rate of a particular behaviour did not automatically mean that the service needed to be redesigned.

We needed to understand the relationship between the numbers and the experience behind them.

For example, research could identify a point in the journey where users were uncertain about what to do next. We could then investigate whether the service data showed evidence of users abandoning the process, contacting support or requiring additional intervention at the same point.

This created a much stronger evidence chain:

user behaviour → service interaction → operational impact → measurable data → design opportunity

That approach also helped stakeholders make decisions with greater confidence. Instead of relying on individual experiences or isolated performance measures, the team could consider several sources of evidence together.

“What stood out was the way they transferred knowledge throughout the project. They did not keep the research, analysis or design thinking within the consultancy team. They worked alongside our people, explained their approach and involved us in the decisions, which meant we were able to take ownership of the work and continue developing it after they left.”

Head of Digital Delivery

Design Approach

With a clearer understanding of the service, we moved from investigation into design.

Our approach was not to design a new interface simply because the existing one appeared dated or inefficient. We used the evidence gathered during discovery to identify where intervention could make the greatest difference.

Service design provided the framework for bringing the different perspectives together.

We considered the experience from the user’s point of view, while also looking at the operational processes, systems and organisational responsibilities supporting that experience. This allowed us to identify opportunities that would not necessarily have been visible by looking at the front end alone.

Our service designers translated research findings into journeys, service blueprints and design concepts. Our business analysts worked alongside them to explore the underlying processes, requirements, rules and dependencies needed to make those changes viable.

This multidisciplinary approach was particularly important where a seemingly simple user problem had a more complicated operational cause.

A user might experience a delay at one stage of the service, for example, but resolving that delay could require changes to information captured earlier in the journey, a change to an internal process or better visibility of work for an operational team.

Rather than designing around these constraints, we made them part of the design problem.

We worked collaboratively with the client throughout this process, using prototypes and service artefacts to make ideas tangible and testable. This gave stakeholders something concrete to respond to and allowed us to identify issues before they became expensive to implement.

The data also became part of the design process rather than simply an evaluation mechanism at the end.

We considered what information the service needed to capture, how it should be presented and, importantly, what decisions that information would support.

This shifted the conversation from “What data should we report?” towards “What decisions do we need to make, and what evidence would help us make them?”

That is a subtle but important difference.

A dashboard can tell someone that a number has changed. A well-designed service can help them understand what has changed, why it may have changed and what action they should consider taking next.

Outcome and Impact

The project resulted in a clearer understanding of the service and a stronger evidence base for improving it.

The immediate outputs included a detailed understanding of the existing service, research findings, mapped user journeys, service design artefacts and recommendations for improving both the user experience and the way service data was used.

More importantly, the organisation gained a clearer connection between user needs, operational activity and service performance.

This enabled the team to identify specific opportunities for improvement rather than making broad changes across the service. It also provided a more structured way to assess whether proposed changes were likely to improve outcomes for users and the organisation.

Where implemented, these changes contributed to measurable improvements including [65% reduction in processing time], [47% increase in successful completion] and [62% reduction in avoidable contacts/manual interventions].

The value of the work was not limited to these measures.

The organisation also had a better basis for prioritising future improvements. Decisions could be grounded in evidence from users and service performance rather than being driven primarily by anecdotal feedback, individual stakeholder priorities or the availability of a particular technology.

The work also strengthened the relationship between policy and service delivery.

Policy decisions ultimately affect people through services. Understanding how those services operate in practice, and how users experience them, provides valuable evidence about whether policy is achieving its intended effect.

This means that service data can do more than measure performance. Used properly, it can help organisations learn.

That learning can then influence what happens next.

“They brought a strong user-centred perspective while still understanding the operational realities of the service. They challenged our assumptions constructively, helped us connect user research with the data we already had, and left the team with practical methods and artefacts that we could continue using. The capability transfer was as valuable as the immediate project outcomes.”

Senior Product Manager

Reflection

One of the clearest lessons from the project was that data-driven decision-making is fundamentally a design challenge.

It is tempting to think about data as something that sits behind a service, used primarily for reporting and performance management. In reality, the way data is collected, interpreted and presented influences the decisions people make and, ultimately, the experiences users have.

That is why we placed user research and service design at the centre of the work.

Research helped us understand the people behind the numbers. Service design helped us understand the system around those people. Business analysis helped us translate that understanding into processes, requirements and viable change. Data provided the evidence needed to understand performance and assess whether interventions were working.

None of these disciplines provided the complete answer in isolation.

Together, they created a much stronger way of understanding the service.

For government organisations, this matters because digital transformation is rarely just a technology problem. Services operate within complex environments shaped by policy, legislation, organisational structures, legacy systems, operational constraints and real human behaviour.

Good design has to account for all of them.

The strongest decisions therefore come from combining evidence rather than relying on a single source. Data can tell you where to look. User research can help explain what is happening. Service design can help identify what could change. Business analysis can help determine how that change can work in practice.

That is the approach our consultancy brings to public sector transformation: start with the problem, understand the people experiencing it, understand the system delivering it, and use evidence to design a better way forward.

The result is not simply a better set of metrics or a redesigned service. It is a public service that is better able to understand its users, learn from its performance and make informed decisions about what to do next.

And in a complex government environment, that ability to learn may be one of the most valuable capabilities a service can develop.