Following the Early Years private beta launch, we wanted to continue improving the admin site used by support agents to process claims.
Previously, we designed with caseworkers to support claim processing and used those insights to shape the initial case working journey.
As the service moved into private beta, we pivoted our focus to understand how the admin site was working in practice for support agents when reviewing claims across all claim services.
Understanding the existing problems
Over time, the team had built up a backlog of 16 improvement tickets relating to the admin site. We reviewed these alongside previous design work and the existing live services to understand whether they represented individual feature requests or broader operational problems.
Several tickets appeared to address different symptoms of the same problem. For example, requests relating to dashboards, filtering and navigation all suggested that support agents needed better ways to understand what work required their attention.
Instead of treating the backlog as a list of features to build, we decided to explore the problems behind the requests.
Working directly with support agents
We organised an in-person session with support agents and service managers to test our assumptions and understand how they use the service day to day.
We were clear that we were not asking them to design new screens. We wanted to understand:
- what they use regularly
- what slows them down or causes confusion
- what they rarely use
- what information or functionality is missing
We reviewed existing screens together, using post-it notes of different colours to identify what worked well, what caused problems and what was missing. We then explored which changes could save the most time, remove frustrations, or make the biggest difference to their role.
This gave us much richer insight than simply asking which features they wanted.
Moving from screen issues to service problems
Support agents use a purpose-built admin site to process claims as well as Zendesk to communicate with claimants. Discussions and notes highlighted problems including restrictive search, difficulty organising claims by policy or status, switching between the admin Site and Zendesk, and claimants contacting them because they could not see the progress of their claim.
Instead of recording these as separate design requests, we looked for patterns.
Dashboard changes, filters and grouping failed checks, for example, all related to a broader need for better work prioritisation. Requests around sending emails, collecting evidence, and showing claim progress pointed towards a wider problem around communication and evidence collection.
Creating a problem register
We combined what we heard from support agents with evidence from the existing backlog.
This resulted in 32 problem statements grouped into eight themes, covering:
- work prioritisation and operational workflow
- finding and accessing information
- decision support
- operational efficiency and automation
- communication and evidence collection
- integrations
- claim quality and fraud prevention
- service language and usability
This helped us move away from page-specific fixes and understand needs that appeared repeatedly across the service.
The workshop also challenged some smaller assumptions. For example, the service referred to people processing claims as 'caseworkers', but participants told us that 'support agent' better reflected their role. We now use this terminology when describing these users.
Deciding what to explore first
We worked with product colleagues to consider the potential impact of improvements alongside the effort required to deliver them.
Some opportunities, including additional claim filters and a function to retry HMRC checks, could provide significant operational benefits with relatively low development effort. Others, such as historic claim access or cross-policy claimant history, require further discovery and technical investigation.
The problem register therefore gives us an evidence base for deciding where future research, design and technical investigation can have the greatest value, rather than becoming another list of features to build.
Building a closer relationship with support agents
An important outcome from the work was creating a closer relationship between the people designing the service and those using it to process claims every day.
We want to move away from support agents raising individual tickets for the product team to interpret.
Instead, we are establishing regular conversations, opportunities to shadow real tasks, and ways to agree with priorities together.
This allows support agents to contribute earlier, before solutions have been decided, while giving the product team a better understanding of the operational context behind requests.
What we learned
An existing backlog does not necessarily provide a complete picture of user needs. Individual tickets can describe proposed solutions without revealing the underlying problem.
Working directly with support agents helped us challenge those assumptions and identify broader needs across the service.
It also reinforced something we learned when designing the original claim-processing journey: the people operating a service are users too.
As the service develops, we want this collaboration to become part of how we work rather than something reserved for individual discovery activities.