扒哥吃瓜

Alpha is where you 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鈥檚 entire wider journey.

You might not even want to prototype all of the transaction or element you鈥檙e 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鈥檝e 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鈥檚 useful to think about who you鈥檒l need in your team at alpha.

You can .

Focus on testing your riskiest assumptions

A crucial part of alpha is . What these are will depend on the service you鈥檙e 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鈥檙e trying to help receive information at the moment. If they do not use the internet at all, it鈥檚 unlikely they鈥檒l use your service.

Or being able to integrate with existing technology might be a priority. The team working on Register to vote realised they鈥檇 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鈥檚 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鈥檒l 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鈥檝e got the scope of your part of the journey right
• you鈥檝e 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鈥檙e 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鈥檙e 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鈥檙e 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鈥檚 point of view.

Joining up with the user鈥檚 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鈥檚 journey, the different organisations involved and the different channels people use to access them.

If one of your riskiest assumptions is that it鈥檚 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鈥檙e 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鈥檙e 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 .

You should also get in touch with the 扒哥吃瓜 content team midway through your alpha. They鈥檒l help you work out how your transaction should join up with 扒哥吃瓜.

Dealing with constraints

Use the alpha phase to explore any immovable constraints in legislation, contracts or legacy technology that affect the service you鈥檙e planning to build. By the end of alpha, you should be able to explain:

• how you鈥檒l create a service that meets user needs while working within these constraints
• where they鈥檙e 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鈥檚 plan for doing this

Working in the open

During alpha, you should continue to talk publicly about the prototypes you鈥檙e building and what you鈥檙e learning from them. For example, through blog posts and open show and tells. As part of this, think about ways to share what you鈥檙e learning with operational delivery colleagues.

Reusing users鈥� information where possible

It鈥檚 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鈥檒l be expected to show how you鈥檙e 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鈥檒l 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鈥檒l 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鈥檇 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鈥檙e 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鈥檚 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鈥檙e going to tackle accessibility at beta.

You should also be able to show that you鈥檝e considered inclusion in the wider sense. This means:

• you鈥檝e thought about whether there are likely to be pain points for particular groups of people when accessing the service (for example, if you鈥檙e asking for someone鈥檚 permanent address and your users include homeless people, you鈥檒l need to show that you鈥檝e got a plan to stop them being excluded)
• including people with low levels of digital confidence in your user research
• you鈥檝e started thinking about how you鈥檒l 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鈥檝e got a prototype that鈥檚 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鈥檒l need to be confident that:

• you can create something that meets users鈥� needs and is cost-effective
• you鈥檒l 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鈥檙e not confident you could do these things, you could stop altogether or decide to repeat discovery or alpha.

When you鈥檙e 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鈥檒l need in your team for beta.

Other things to consider at alpha

There are a few other things that you鈥檒l need to consider at alpha. You鈥檒l need to show that you鈥檝e started to think about:

• the sorts of programming tools you鈥檇 like to choose for beta and why you鈥檇 get value for money
• how you鈥檒l identify threats to your service, how you鈥檒l deal with them and how you鈥檒l stay up to date with threats
• how you鈥檒l open source your code - and with offline channels, how you鈥檒l share your methods and processes
• whether or not you鈥檙e 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鈥檒l use to measure how successful your service is.

If you鈥檝e created any new design patterns - or learned anything useful about an existing design pattern - you should share what you鈥檝e learned through the .

Related guides

You may find these guides useful:

• How the discovery phase works
• How the beta phase works
• How the live phase works
• Retiring your service