Putting users at the heart of service design means making decisions based on what they actually need, not just what design and delivery teams assume they need. Sometimes that leads to a surprising but important conclusion - that building a new service isn’t always the right thing to do.
User-centred design (UCD) helps teams explore problems from the perspective of users. In agile delivery, the discovery and alpha phases exist to help us investigate whether a service is viable, valuable and feasible. In some cases, the most responsible and user-centred decision we can make is to stop.
This post shares how and why UCD teams at the Home Office have advised stakeholders not to move beyond discovery or alpha, and how that can be considered a success, not a failure.
When not building a new service is the right outcome
The Service Manual sets clear expectations for moving between phases:
- at the end of discovery you should have evidence that there's a problem worth solving and a viable, cost-effective service that could meet that need
- at the end of alpha you should know that a service can meet user needs, be delivered within your constraints, and is technically feasible
When those conditions aren’t met, moving forward risks delivering something that doesn’t work for users, and ultimately wastes public money.
Some examples of why we might not continue include:
- discovering that user needs could be met more effectively by existing services
- realising that operational or policy changes would better solve the problem
- legal or technical barriers that prevent us from meeting user needs effectively
- recognising that the cost and effort of building a new service and implementing change wouldn’t be proportionate to the value it would deliver
Making the decision to stop shows that we’re taking a truly user-centred, evidence-based approach. It puts users first, above delivery timelines or internal pressures, and demonstrates our commitment to achieving value for money.
Tips for teams thinking about not proceeding to build a service
1. Bring your stakeholders with you
Stopping shouldn’t be a surprise. Share your findings early and often. Use approaches like regular mini-playbacks or collaborative analysis sessions to involve stakeholders in the learning journey. This builds trust and helps everyone understand the evidence.
2. Stay open to different ways of solving the problem
Frameworks like the opportunity solution tree help you explore and effectively communicate a range of options that relate to your desired outcomes, without jumping to conclusions. This mindset encourages teams and stakeholders to focus on outcomes for users, not pre-defined solutions.
3. Consider value versus effort
Think about whether the value of a new service justifies the effort to deliver it. Sometimes, the change needed is too complex or costly for the benefit it brings. In those cases, another approach might be more effective.
4. Test your riskiest assumptions
By framing assumptions as hypotheses, you can test them quickly and build a solid evidence base. This gives your team confidence in their recommendation to stop, and shows that that recommendation is based on user research and data.
5. Give your stakeholders actionable recommendations
Even if you're not continuing to beta, your work should support others. Use your end of phase playback to share what you’ve learned, and suggest next steps for policy, operations or other teams.
Stopping can still deliver value
It can feel like a setback to stop work on a service. But choosing not to build when it's the right thing for users is a powerful act of public service.
Here's how we added value in our work with asylum operations after choosing not to move beyond alpha:
- Amplified user voices: We worked with under-represented users, shared their perspectives, and helped make their needs more visible.
- Shared insight: We passed on research findings to related teams, reducing duplication of effort by teams working to understand and improve outcomes across multiple services.
- Highlighted existing value: We identified where existing technology, tools or processes could meet user needs, helping teams make better use of what they already had.
- Improved content: Based on evidence we gathered in discovery and alpha, we created a content playbook that's now used by designers and operations teams to communicate more clearly with users and external partners.
- Influenced standards: Our findings helped inform guidance in the Home Office Design System.
- Documented our work: We made our approach and evidence easy for a future team to pick up again, recognising that needs, policy and technology may change over time.
Empowering users means better public services and value for money
Stopping the design of a service before it’s been built can be hard. But it’s often the most user-centred, responsible decision you can make. By putting user needs above assumptions and showing the evidence behind your thinking, you can help your department deliver better, and better value, public services.
Leave a comment