Enhancing public services through User-Centred Design

Public services exist to meet people’s needs. Yet it is surprisingly easy to design a service around the organisation delivering it rather than the people who need to use it.

This is one of the recurring challenges I have seen across public sector digital delivery. Teams can spend months defining requirements, designing processes and building technology, only to discover that the service does not work particularly well for the people using it. Sometimes the problem is obvious: a form is difficult to understand, information is inaccessible or users are required to provide the same information several times. In other cases, the problems are less visible. A service may technically work but still create unnecessary effort, uncertainty or frustration.

User-centred design provides a way of addressing this.

At its simplest, it means putting the needs, circumstances and behaviours of users at the centre of decisions about how a service works. In practice, that requires more than carrying out some user research before development begins. It means continuously testing assumptions, understanding the wider service and using evidence to shape decisions throughout delivery.

In my experience as a business analyst and service designer, this is where the real value of user-centred design emerges. It creates a shared understanding of the problem and gives delivery teams something stronger than opinion to work from.

Start with the problem, not the solution

One of the easiest mistakes in digital transformation is to begin with a solution.

A programme may start with a requirement to build a new portal, replace an existing application or introduce a new digital process. By the time a delivery team becomes involved, the proposed solution can already feel fixed.

This creates a difficult starting point. The team is effectively being asked to design the best version of something that may not be solving the right problem.

User-centred design changes the starting point. Instead of asking, “What system do we need to build?”, we can ask, “What are users trying to achieve, and what is preventing them from doing it effectively?”

That distinction is important.

I have worked on services where the initial requirement appeared straightforward, but research and analysis revealed a much more complicated picture. Users were navigating multiple processes, relying on workarounds or contacting staff because the digital service did not reflect the way the underlying service actually operated.

The technology was not necessarily the fundamental problem. The service around it was.

“The most valuable part of the work was the way the team helped us move beyond what we thought the problem was. We had a clear view of the service from an organisational perspective, but we did not have the same understanding of how people actually experienced it. By combining user research with process analysis and service design, the team gave us a much clearer picture of where users were struggling and why. That evidence changed some of our original assumptions and, importantly, influenced what we decided to build. It meant we were making decisions based on the needs of the people using the service rather than simply translating existing processes into a digital format.”

Head of Digital Transformation, Central Government Department

This is where the business analyst and service designer can add significant value. User research can tell us what people experience. Process analysis can help us understand why that experience exists. Service design can connect the two, showing how people, processes, technology and organisational responsibilities interact.

The result is a more complete view of the problem.

It also creates a better conversation with stakeholders. Rather than debating whether a particular feature should be included, the team can discuss the evidence behind the problem it is intended to address.

That is a much healthier basis for decision-making.

Understand the whole service, not just the digital interface

A common misconception is that user-centred design is primarily about designing better screens.

The interface matters, but it is only one part of the experience.

A person using a government service does not experience an organisation’s architecture, operating model or departmental boundaries. They experience a journey.

They may receive a letter, search for information, complete an online form, upload evidence, wait for a decision, receive another communication and then contact an organisation because they are unsure what happens next.

From the user’s perspective, that is one service.

This is why I often find journey mapping and service mapping particularly valuable. They help teams move beyond the individual transaction and understand what is happening around it.

For example, a digital form might be perfectly usable in isolation. But if users have to find information from another part of a website before completing it, cannot save their progress and then have to telephone an organisation to understand what happens afterwards, improving the form alone will not solve the underlying experience.

The wider service needs to be understood.

This is also where accessibility becomes more meaningful. Accessibility is not simply a compliance exercise or a checklist to complete before launch. A service can meet technical accessibility requirements and still be difficult to navigate, understand or complete.

Users may have different levels of digital confidence, limited access to technology, language barriers, cognitive differences or circumstances that make a supposedly simple process difficult.

Good user-centred design makes those realities visible.

It asks not only whether someone can technically use a service, but whether they can understand what they need to do, complete it successfully and know what will happen next.

Use evidence to challenge assumptions

Public sector delivery involves a large number of stakeholders, each bringing valuable knowledge and experience.

That knowledge matters. But it is not the same as knowing how users actually behave.

One of the most useful things user-centred design brings to a programme is a way of testing assumptions.

I have seen situations where stakeholders were confident that users would want a particular feature, follow a particular process or understand a particular piece of terminology. Once the team spoke to users, the reality was different.

This should not be treated as a failure.

Finding out that an assumption is wrong before significant time and money has been invested in building around it is a successful outcome.

The challenge is creating an environment where teams are comfortable discovering that they are wrong.

This requires a shift in mindset. Research should not be treated as an activity intended to validate a solution that has already been chosen. It should be used to reduce uncertainty.

That means involving users early, testing concepts before they become expensive to change and continuing to gather evidence as the service develops.

For a business analyst, this creates a useful connection between research and requirements. Rather than translating stakeholder requests directly into system requirements, I can use research findings to understand the underlying need and then work with the team to define an appropriate response.

For a service designer, the same evidence can inform journeys, service models and interaction patterns.

The disciplines overlap because they are addressing the same fundamental question: what needs to change to make the service work better?

“What stood out was that user-centred design was not treated as a discovery activity that happened at the beginning and was then handed over to the delivery team. The team continued to bring user evidence into the design and development process, which gave us much greater confidence in the decisions we were making. We were able to identify areas where people were finding the service difficult to understand, test alternative approaches and make changes before they became expensive to implement. It also helped bring different stakeholders together because we had a shared evidence base. Instead of having competing views about what users needed, we could look at what the research and service data were actually telling us.”

Programme Director, Government Digital Transformation Programme

Design for real people and real circumstances

Another lesson I have learned is that users rarely interact with public services under ideal conditions.

They may be busy, stressed, unfamiliar with the subject or dealing with circumstances that make completing a process difficult.

This matters because services are often designed around a neat process model.

The organisation has a defined workflow. The user provides information. The system processes it. A decision is made.

Real life is rarely that clean.

People forget passwords. They lose documents. They misunderstand terminology. Their circumstances change. They start a process on one device and finish it on another. They abandon an application and return later. They may need help from somebody else.

Designing around these realities produces more resilient services.

This is one reason I place considerable value on observing users rather than relying exclusively on what they tell us. What people say they do and what they actually do are not always the same thing.

A user might say that a process is straightforward but still take several attempts to complete it. They might describe a particular workaround as their normal behaviour even though it introduces unnecessary effort.

These details are important.

They allow a delivery team to design for the circumstances in which a service is actually used rather than the circumstances in which the organisation hopes it will be used.

Bring user-centred design into delivery, not just discovery

One of the biggest risks is treating user-centred design as a discovery phase.

Research happens. Personas are created. Journey maps are produced. A set of findings is presented to stakeholders.

Then delivery moves on.

That approach misses much of the value.

Services change as they are developed. Technical constraints emerge. Policy decisions change. Operational teams identify new requirements. Users reveal problems that were not visible earlier.

User-centred design therefore needs to continue throughout delivery.

Prototypes are particularly useful because they give users something tangible to respond to before a team commits to building the final solution. Testing a prototype can reveal problems with content, navigation, terminology or the underlying process while changes are still relatively inexpensive.

This also creates a stronger relationship between research, design and development.

Rather than each discipline operating sequentially, they become part of an iterative delivery cycle. Research generates evidence. Analysis turns that evidence into a clearer understanding of the problem. Design explores potential solutions. Development turns those solutions into working software. Testing provides further evidence.

The cycle continues.

This is not about creating additional process for the sake of it. It is about reducing the risk of building the wrong thing.

Measure whether the service actually improved

A service is not successful simply because it has launched.

This sounds obvious, but delivery environments can place significant emphasis on whether a project has delivered its scope, met its deadline or released its planned functionality.

Those measures matter, but they do not necessarily tell us whether the service has improved.

A user-centred approach encourages us to think about outcomes.

Are users completing the service successfully? Are fewer people abandoning the process? Are avoidable errors decreasing? Are people able to find the information they need? Are support calls falling because the digital service is easier to understand?

The right measures will vary depending on the service.

The important point is that they should reflect what success means for the people using it as well as the organisation operating it.

This can also change how teams prioritise improvements.

If research shows that users are struggling with a particular part of the journey, and service data confirms that it generates a high number of errors or support contacts, there is a strong evidence base for addressing it.

The conversation becomes less about which feature someone wants next and more about which problem is creating the greatest impact.

That is a more mature approach to continuous improvement.

“The project changed the way we thought about accessibility. Previously, it was something we associated primarily with the digital interface and meeting the relevant standards. The work showed us that accessibility is much broader than that. We needed to consider the whole journey, including the information users received beforehand, the language we used, how people completed the process and what support was available when something went wrong. The team helped us understand the service from the user’s perspective and identify changes that made the journey clearer and more inclusive. That has influenced how we now approach other services, particularly at the point where we are defining problems and making early design decisions.”

Director of Customer and Digital Services, Public Sector Organisation

User-centred design is ultimately about better decisions

The strongest argument for user-centred design is not that it produces nicer interfaces.

It produces better decisions.

It gives delivery teams a clearer understanding of who they are designing for, what those people are trying to achieve and where the existing service is creating unnecessary difficulty.

It gives stakeholders evidence to challenge assumptions.

It gives business analysts a stronger foundation for defining requirements and understanding processes.

It gives service designers a way to connect user needs with the wider service.

And it gives delivery teams an opportunity to identify problems before they become expensive to fix.

Most importantly, it changes the relationship between an organisation and the people who use its services.

Instead of asking users to adapt to the organisation’s processes, the organisation starts asking what it can do to make the service work better for the people it exists to serve.

That does not mean every service can be made simple. Government services often have complex policy, legal, operational and technical constraints.

But complexity in the underlying service does not have to become unnecessary complexity for the user.

That distinction is central to good digital delivery.

Final thoughts

User-centred design is sometimes presented as a collection of methods: interviews, usability testing, journey maps, prototypes and personas.

Those methods are useful, but they are not the point.

The real value comes from using them to understand problems properly, challenge assumptions and make better decisions.

In my experience, the strongest teams are not the ones that simply involve users. They are the ones that allow what they learn from users to genuinely influence what they build.

For public sector leaders, that raises an important question: when was the last time your service changed because of something a user told you?

And if the answer is difficult to give, perhaps the bigger question is whether users are genuinely shaping the service — or simply being consulted about decisions that have already been made.