A digital service that works well at launch may not continue to meet users’ needs in the same way years later. So, when we wanted to better understand how our service was being used today and whether it still supports users as effectively as intended, we went back to basics with a rediscovery.
Although the service manual says discovery should happen at the beginning of a project, before any solution is designed or built, discovery is also for challenging assumptions and exploring new or unknown problems.
So when a cross-government reform programme developed a new assessment to replace key user journeys within our service, we saw it as an opportunity. Our service had been live for years and significant changes were planned.
We couldn’t assume we understood everything about how the service was being used, or what challenges users now faced. So we used discovery as an opportunity to understand where user needs were not being currently met in the end-to-end user journey. This means when it's time to test different ideas, we’ll have the evidence needed to do it well. In this post, we reflect on what we learnt from that discovery, and what it revealed about opportunities for future transformation.
Discovering before the discovery
Before making any changes, we wanted to fully understand why the service was designed the way it was. Reflecting on this post Responsible interaction design, it’s important to “dig into the history of why things are the way that they are". We did this by reviewing previous discovery work; the research reports, user needs, journey maps, Miro boards and Confluence pages created by earlier teams.
What we found was a huge amount of valuable material, but it also presented a challenge: it wasn’t clear what was still relevant, what assumptions no longer held true, and what gaps remained. At times, it felt like we were spending a long time discovering the discovery itself.
In hindsight, we could have time-boxed this work more tightly and moved sooner into generating fresh insights with users. While understanding the past was important, new research proved essential for understanding how the service is used today.
Creating the right environment for research
The users of this service work with sensitive information across complex, high-risk workflows. To understand their processes and needs, we planned to shadow users as they carried out their day-to-day work.
Because many staff work remotely, we arranged to meet in person at a central office. On arrival, it became clear the space was not suitable for working with sensitive information or for a long shadowing session, and we had to reschedule.
While frustrating, this reinforced the importance of planning not just research methods, but also the environment in which research takes place particularly when working with sensitive data.
Discoveries do not stop when a service goes live
One of our biggest things this work reinforced is that discovery isn’t always a one-off phase. As set out in this blog Keeping services alive , product teams working on live services, still need time and space to explore problems properly. Without this, they end up applying sticking plasters instead of solving the underlying problems.
This was true for us. As a service team, we had accumulated a large body of historic research, but it wasn’t clear what user needs had been addressed and what gaps remained. Going back to basics, talking to users, mapping the end-to-end journey and involving stakeholders in our work, gave us the foundation to make informed decisions rather than relying on old assumptions.
Putting money where are insights are
Our discovery generated a large number of insights, and it was important that the whole team had a shared understanding of which problems were most valuable to focus on.
To support this, we ran a collaborative prioritisation exercise using Monopoly money. Team members were given a set amount and asked to “bid” on the problems they felt would deliver the most value if solved. This helped bring the findings to life, encouraged open discussion, and surfaced different perspectives across the team.
This approach showed us the value of involving the whole team in prioritisation early. By creating space for discussion before applying more structured scoring, we built stronger alignment and confidence in our decisions. We followed this with value, effort and influence scoring to agree which challenges to take forward into alpha.
Working with the reform programme
We shared our findings with the reform programme team at the end of discovery. This helped us have honest conversations about what was realistic to deliver and where we’d need to work more closely together.
Rather than waiting for requirements to be handed down, we became partners in understanding the problem. This meant that the evidence we gathered helped both teams understand where improvements were needed and helped shape what we’d work together on next.
The reform programme is still going, a multi-year, cross-government piece of work looking at how counter terrorism is case managed across agencies. Until that ends, a large part our work in on hold. But the discovery means we’re not starting from scratch.
Discovery also identified new opportunities outside of the programme. We’ve already started making changes and conducting further research, and the prioritisation exercise has given us a clearer picture of what users need and a backlog of prioritised opportunities to guide us.
User research is a team sport
If you’ve worked in government for any length of time, you will have seen the GDS posters ‘User research is a team sport’ and ‘Two hours every six weeks’. The posters are about encouraging a user-centred culture by getting everyone participating in user research, often.
We did this by involving the whole team throughout the discovery. After our research sessions, the team shared and analysed the pain points together. Talking through the findings helped everyone, not just the researchers, see the patterns in what users were struggling with. We then used ‘How might we’ statements to reframe the pain points as opportunities, which gave our team a shared framework for talking about the problems worth solving.
This collaborative approach made a big difference. When everyone has seen the evidence and helped make sense of it, decisions about the work are more understandable. When we say, ‘user research is a team sport’, the ‘team’ means anyone whose work and decisions will, directly or indirectly, influence the product or service. If you involve teams in the work early, they’ll make better, evidence-based decisions, and build a more collaborative, open culture in the process.
What we learned
Discovery isn’t straightforward when you’re working on a live service. We inherited a large amount of research and designs but the rationale behind these wasn’t always documented. It wasn’t always clear why certain design decisions had been made, what had changed since or what gaps remained.
But it was valuable. After 6 weeks we had a better understanding of how the service is used today, closer relationships with our stakeholders and clearer view of what we should work on next.
Leave a comment