How the alpha phase works
Alpha is where you try out different solutions to the problems you learnt about during discovery.
Spend alpha building prototypes and testing different ideas. And do not be afraid to challenge the way things are done at the moment: alpha is a chance to explore new approaches.
You do not have to prototype the user’s entire wider journey.
You might not even want to prototype all of the transaction or element you’re working on: often it makes sense just to focus on the areas you think will be most challenging. This lets you do the minimum you need to test your riskiest assumptions.
Alpha services should not be available for the public to use.
With any online solutions you try out, build things that are just complex enough to let you test different ideas, not production quality code. Expect to throw away any code - and lots of the ideas you test - at the end of alpha.
By the end of alpha, you should be in a position to decide which of the ideas you’ve tested are worth taking forward to beta.
Alphas tend to last between 6 and 8 weeks. Which means you should book your alpha assessment within a fortnight of starting your alpha.
It’s useful to think about who you’ll need in your team at alpha.
It’s okay to decide at the end of your discovery that you do not think it’s worth running an alpha.
You can download a poster that explains what the alpha phase is for.
Focus on testing your riskiest assumptions
A crucial part of alpha is identifying your riskiest assumptions and testing them. What these are will depend on the service you’re building.
For example, the problem you want to solve might be reducing loneliness and isolation. If you think an online information service might help to solve that problem, one thing you might prioritise is carrying out research to find out how the people you’re trying to help receive information at the moment. If they do not use the internet at all, it’s unlikely they’ll use your service.
Or being able to integrate with existing technology might be a priority. The team working on Register to vote realised they’d need to build an API that integrated with the registration systems of over 400 local councils. If that had not been possible, the service would not have worked - so that’s what they focused on during their alpha.
Equally, if one of your possible solutions relies on finding solutions to legislative constraints you might want to spend part of your alpha working out how feasible that is.
Meeting the standard at alpha
There are a couple of points in the standard you’ll want to pay particularly close attention to at alpha.
Solving a whole problem for users
Point 2 of the standard says you need to work towards solving a whole problem for users.
At alpha, this could mean showing:
- how you know that you’ve got the scope of your part of the journey right
- you’ve looked at the wider user journey your service is part of
- you have a sense of what would need to happen to make the journey as a whole work as well as possible (in particular, you’re able to talk about other services that are part of the same journey, and the opportunities and challenges involved in making changes to those services)
- you’re working in the open, and have started building relationships with teams responsible for other parts of the journey where it makes sense to do so
- you understand any constraints with legislation, contracts or technology that impact on your service
- you’re planning to minimise the number of times a user has to submit the same information to government
Getting the scope of your part of the journey right
Getting the scope of a transaction right is probably the most important part of making it simple to use. Use alpha to explore what scope makes sense from the user’s point of view.
Joining up with the user’s wider journey
Not all transactions are part of a wider journey for the user. But if yours is, you should have explored that wider journey as part of discovery.
You could bring a rough journey map (or similar artefact) to your alpha assessment, showing where your service sits in the user’s journey, the different organisations involved and the different channels people use to access them.
If one of your riskiest assumptions is that it’s possible to make changes to other services in order to provide the user with a simple, intuitive journey, use the alpha phase to test that assumption by talking to the people responsible for those other services. By the end of alpha, make sure you’re clear what can be changed and how difficult or costly it would be to make those changes.
If you face any blockers collaborating across government or more widely, you need to show how you’re addressing them, for example by building relationships with potential collaborators.
Either way, you should be talking and building relationships with the other people working in the same area as you. A good place to start is to check whether there’s a service community for the area you’re working in.
You should also get in touch with the GOV.UK content team midway through your alpha. They’ll help you work out how your transaction should join up with GOV.UK.
Dealing with constraints
Use the alpha phase to explore any immovable constraints in legislation, contracts or legacy technology that affect the service you’re planning to build. By the end of alpha, you should be able to explain:
- how you’ll create a service that meets user needs while working within these constraints
- where they’re the type of constraints that can be removed over the long term (for example, by changing a technology platform or contracting with suppliers in a different way), the organisation’s plan for doing this
Working in the open
During alpha, you should continue to talk publicly about the prototypes you’re building and what you’re learning from them. For example, through blog posts and open show and tells. As part of this, think about ways to share what you’re learning with operational delivery colleagues.
Reusing users’ information where possible
It’s often the case that, when interacting with related services, users have already given government the same information you need from them.
Use the alpha phase to investigate whether you can reuse that data, so that users do not have to provide the same information multiple times as they move from task to task. Unless there are public policy, trust or legal reasons not to share data, you’ll be expected to show how you’re working towards sharing it.
Providing a joined up experience across different channels
Point 3 of the standard says your service needs to work well across all the channels a user might use to access it.
This involves understanding how the online and offline parts of your service link together and any pain points users experience as a result of this.
You could work towards this at alpha by:
- including offline elements like letters in your alpha experiments and user research, especially where this relates to a risky assumption (for example, that you’ll be able to change the content of letters)
- considering user journeys that start within a third party or non-government organisation, like referrals
- inviting operational delivery colleagues to get involved in the alpha - they’ll have a really useful perspective on what the riskiest assumptions are
Making sure everyone can use your service
With an online prototype, you cannot apply the full range of technical accessibility tests you’d use for production code. But at alpha, you should be able to show that you:
- understand the WCAG accessibility principles - this will help you identify and test any specific accessibility challenges you’re likely to face with your service
- are including disabled people in your user research
You do not have to get an accessibility audit at alpha, but it’s worth starting to think about it because they can take time to arrange. And if you appoint your auditor during alpha, they can review your alpha designs or prototypes for potential accessibility problems giving you plenty of time to fix things.
Either way, by the end of alpha you should have a plan for how you’re going to tackle accessibility at beta.
You should also be able to show that you’ve considered inclusion in the wider sense. This means:
- you’ve thought about whether there are likely to be pain points for particular groups of people when accessing the service (for example, if you’re asking for someone’s permanent address and your users include homeless people, you’ll need to show that you’ve got a plan to stop them being excluded)
- including people with low levels of digital confidence in your user research
- you’ve started thinking about how you’ll design the assisted digital support model for people who need help doing things online
Deciding whether to move on to beta
Alpha is finished when you’ve got a prototype that’s substantial enough to help you make a decision about whether to move on to the beta phase or not.
To move on to beta you’ll need to be confident that:
- you can create something that meets users’ needs and is cost-effective
- you’ll have the budget and people necessary to deliver what you need to - this includes having a budget for research
You should be able to explain how you came to this decision using the success metrics you identified at the end of discovery.
If you get to the end of your alpha and you’re not confident you could do these things, you could stop altogether or decide to repeat discovery or alpha.
When you’re confident you want to move on to beta, your delivery manager and service owner should start working on a beta business proposal. This should include information on who you’ll need in your team for beta.
Other things to consider at alpha
There are a few other things that you’ll need to consider at alpha. You’ll need to show that you’ve started to think about:
- the sorts of programming tools you’d like to choose for beta and why you’d get value for money
- how you’ll identify threats to your service, how you’ll deal with them and how you’ll stay up to date with threats
- how you’ll open source your code - and with offline channels, how you’ll share your methods and processes
- whether or not you’re going to be using common platforms
- how your users would be affected if the online part of your service had technical problems
You should also continue to refine the metrics you’ll use to measure how successful your service is.
If you’ve created any new design patterns - or learned anything useful about an existing design pattern - you should share what you’ve learned through the GOV.UK Design System.
Related guides
You may find these guides useful:
- Last update:
-
Updated to reflect the requirements outlined in the updated Service Standard.
-
Added guidance on how to meet government accessibility requirements in alpha.
-
Guidance first published