Public sector digital projects are all about helping people more effectively. Whether that’s applying for a passport, registering to vote, accessing healthcare or finding housing, your project needs to address real-world needs. The four-stage process UK public sector projects go through is designed to ensure you do this.
This blog is part of a series looking at how to deliver successful discovery, alpha, beta and live projects. We’re sharing advice and insights learned from thousands of person-hours spent delivering digital services for the NHS, central and local government. Today, we’re looking at alpha.
Why is an alpha important?
During discovery, you’ll have defined and understood the problem you need to solve. Ideally, the discovery should also have provided a steer on how the alpha team should begin its work. You can learn more about running successful discoveries in our discovery blog.
Alpha is then about understanding your problem space in more depth, trying out a variety of solutions and gathering feedback from your users. Its aim is to help you make an informed decision on:
- Whether to commit more substantial amounts of taxpayers’ money to building a solution in beta
- Help shape what that solution will be capable of, and how it will do it
What happens during alpha?
There’s a page on Gov.uk setting out what happens during a government alpha project, so we recommend that as your first stop to understand the alpha phase, if you’re not familiar with it, or want a quick recap.
How do you run a successful alpha?
Recruit your users for testing early
If you read our discovery blog, you’ll know we advised lining up users and other stakeholders for interviews as early as possible. The same is true at the alpha stage. User feedback is critical to your success, so you want to ensure you’re speaking to the right people. Depending on the nature of your service, they may be difficult to find, or have exceptionally busy diaries, so it’s advisable to line up your research sessions early.
Test with people who have accessibility needs
However much accessibility theory you read, there’s no substitute for talking to people about their lived experiences, and watching them use your product as it takes shape.
People with accessibility needs can be more difficult to find than those without. It can therefore be easy, when time is constrained, to simply go back to the same individuals time and again. Like with all user testing, however, it’s important to seek out a diverse range of views, needs and experiences, so make sure you incorporate sufficient time into your process to find and recruit people.
Strike a balance between desirability, feasibility and economic viability
Desirability, feasibility and viability are the three lenses of human-centred design set out by non-profit design studio IDEO. It’s essential you take all three into consideration when considering whether to pursue a feature or capability during alpha.
Desirability is about how exciting the feature will be to the target user, and/or its ability to help them address a need. Feasibility focuses on whether you have the skills, time, money and technology to actually deliver the feature. And viability is about economics: is there a strong business case for the feature, and can it be operated sustainably in the longer term?
Prioritisation frameworks can be helpful here, by providing structure around your decision-making in these three areas. (Listen to our feature prioritisation techtalk for more information)
Focus on your riskiest areas
During alpha, you don’t necessarily need to prototype and test the entire solution required to solve your problem. Instead, identify the areas where there’s most uncertainty, and focus on creating certainty in these.
Perhaps you want to get two technologies to work together in a way that hasn’t been done or documented before. Or there may be a question over whether users will find a task too onerous, and therefore be unwilling to complete it.
Your discovery may already have identified areas requiring further exploration. Take some time at the start of alpha to identify any others. Talk openly with stakeholders to tease out where there are uncertainties: someone answering ‘I don’t know’ or ‘good question’ when you ask something are strong indicators you’ve identified a topic that needs more investigation to reduce uncertainty and the associated risks.
Test your full journeys, including offline elements
It’s not uncommon for stakeholders to view the digital service you’re prototyping as the be-all and end-all of the overall project. But it’s important for all involved to remember the aim is to solve a problem, not simply build a digital service.
Not everyone will be able to use a digital service, for example, so you’ll need to provide other ways of solving the problem. This will likely involve other channels, such as telephone, post, or in-person. It’s essential you test these elements during alpha, and to do so as part of an end-to-end journey, not simply in isolation.
Capture and share learnings as you go
One of the key principles behind agile delivery is to regularly collect feedback from your users, to inform the direction of the service you’re building. Recording and sharing key information helps bring stakeholders on the journey with you and secure buy-in. And having a record of decisions and their rationale is invaluable if you need to undergo a service assessment at the end of your alpha.
Start alpha by agreeing means of capturing and sharing learnings that arise. User journey maps are a good option, because you can continually flesh them out as you learn more. Risk and decision logs can also form part of the picture.
What comes after alpha?
Once you can confidently say whether you’ll be able to cost-effectively create a service that solves the problem you’ve identified, and have the resources needed to build it, you’re ready to move to beta. This is the stage of the project where you’ll build out the service ready for public launch.
Beta is the topic of our next upcoming blog in the series, so stay tuned!
