Alpha Explained- source: Gov.UK
Alpha is the development phase that comes after discovery.
In the alpha phase you need to:
build prototypes of your service
test your prototypes with users
demonstrate that the service you want to build is technically possible
You should use your experience building prototypes in the alpha to:
find the problems with the design of your service and decide how you’ll solve them
make some estimates about how much your service will cost
identify the biggest risks for the beta stage, as early as possible
By the end of alpha you should know:
whether to move your service into the beta phase
what you need to build in beta if you are moving into beta
The team you need in alpha
Find out how to set up your service team at each phase.
How your team should work
Your team should work in an agile way, iterating quickly so that you can learn quickly.
Stages of a successful alpha
Each alpha will be different because the risks and goals for each service are different.
Most alphas are 8 weeks long and follow these 3 stages.
1. Inception: getting the team together to set out goals.
2. Iterations: build prototypes, test them, learn, change and test again.
3. Conclusion: you move on to the beta phase or end the project.
Inception
At the inception stage, you need to complete these steps, which should take a few days.
1. Bring the team together.
2. Set some goals for your project.
3. Identify the biggest risks.
Bring the team together
You can hold sessions during inception to make sure your team:
gets to know each other and forms a team identity
forms a team understanding of the business itself
You may want to introduce your team to the Digital Service Standard, if they aren’t familiar with it, and to agile ways of working.
Set goals
You and your team must work out what the goals of your alpha are.
For example, some of your goals might be:
creating a new digital service
creating a service that meets user needs
proving that you can serve user needs that are currently being met by the private sector, due to a government service failing
Identify the biggest risks
The reason for running an alpha is to identify all the risks to your project as early as possible.
During inception you should try to identify the biggest risks and get a better understanding of them.
Types of risk
In most government projects, the risks fall into one of the following 3 categories:
design
business process
technical
Design risks
Design risks are any issues that come with running a user-centred design process within an iterative model.
It can often take several attempts to get a scope for your service that’s right for the user.
You need to consider:
how easy is it to use
whether the user will get through it correctly the first time
what errors look like
how you’ll analyse the user research
how you’ll build prototypes quickly
Business process risks
Business process risks could include:
how your department will integrate your new service
whether your department has fraud checks – talk to your Senior Information Risk Owner (SIRO) to find out
whether your department is set up to handle support calls
how to operate the service and who’s responsible if it goes down and whether you have out-of-hours support
Technical risks
Technical risks tend to be about integrating into the existing systems, for example:
the type of ongoing connections that are necessary between your service and your department’s existing systems
any special hosting arrangements, for example high security hosting
What you need at the end of inception
Every service is different, but by the end of inception your team should have some or all of the following:
knowledge of the service, what it does and who it’s for
written descriptions of the people who’ll use the service, also called ‘user personas’
a good understanding of whatever currently exists to meet the user need
a clear set of goals and risks
an idea of the vision for your project and what it should look like when it’s done
a clear understanding of how the service will integrate or move away from legacy systems
a prioritised backlog of work for your first iteration
Demonstration and retrospective
You should show what you’ve learned to the service team and to your stakeholders (the project board or senior management team).
You should also hold a retrospective meeting at the end of the inception stage.
Iterations
At the alpha stage, you won’t usually to be able to choose a single user journey or design. You should build and test many prototypes instead.
This allows you to quickly find out which designs offer the best user experience. Your first draft of a user flow will have problems – keep revisiting the design, research and test processes and improving them.
An iteration timetable
GDS encourages the following format:
Day 1:
retrospective (1 hour)
iteration planning (2 hours)
start iteration
Day 2:
user research on previous iterations’ prototypes
analysis of test results
Day 5:
demo
You can deviate from this timetable but you should do the user research early in the iteration to give plenty of time to feed into the next iteration. This allows fast turnaround of user stories.
Working at this pace will result in:
user research in iteration 1
stories completed in iteration 2
further research on updated prototypes in iteration 3
To work in this way you need well-developed prototypes. These can have backend systems that mock out service integrations, but which contain actual working logic.
If you need to iterate faster, you can start with much lower fidelity prototypes (like paper).
This allows you to test various flows and allow much faster iteration of research and prototype development.
You should keep iterating until either:
you can demonstrate that you’ve met the user need with the prototypes and are ready to move on
you’ve proven that you don’t understand the problem enough to prototype, and you cancel the project and return to discovery
At the end of each iteration
At the end of each iteration you should do a demonstration of the service journey so far which shows what your team has learned and what you’re planning to do next.
You should avoid setting up iterations that begin on Mondays and end on Fridays, since more people are absent on these days.
Conclusion
Deciding the alpha phase is finished
At the end of the alpha phase, you should have:
user stories – they should relate to the overall user journey rather than being tied to individual features
a plan for your beta phase and a (less detailed) plan for your live phase
set some metrics to measure your service’s success
a basic working system with limited functionality which you can demonstrate to users
an understanding of legacy systems you need to replace or integrate with
a decision on whether or not to progress to beta phase
analysis on the user needs research you’ve done
ideas for how you’ll design the assisted digital support model for your service
How your prototype should look
Your alpha prototype needs to allow a complete end-to-end transaction.
You should think of it as a proof of concept and use it to check:
you’ve got the right solution that meets the user need
your approach is viable and cost-effective
the technologies exist to implement your plan
the things that won’t be easy to change and whether you can still go ahead despite these
you understand the needs of your users enough to be able to meet them
If not, find out more and make a new prototype.
Moving on to beta
Your team should feel confident that you aren’t proposing a project that won’t work at beta. Make sure your timelines, your scope and your vision are correct according to the money and people you’ve got for the next phase.
Once you’re confident that you want to move to beta, the delivery manager and service manager should start working on a business proposal for beta, early in the alpha stage.
Starting early on the beta program proposal means your team can keep up momentum, and gives you time to get further spend control approval.
You should hold a final demo of your alpha and make sure the project board or senior management team for your service can attend.
Use the demo to show what you’ve achieved in alpha and explain your vision for the beta phase.
You should have a final retrospective and make a backlog of epic user stories for the beta.
Find out more about user stories.
Deciding not to move on to beta
You may also use the alpha stage to decide to end your project rather than continuing into beta.
For example, you may find that:
the user needs for the service are already being met by another government service or the private sector
it costs too much to build the service based on the number of people who’ll use it
there’s a better non-digital solution
adapting or developing another service is a better solution
It’s still a successful alpha if you decide not to move on to beta because it means you won’t waste time and money.
Deciding to start a new alpha
At the end of alpha, you could also decide to start alpha or discovery again, perhaps because you want to focus on different things.
For example, you might identify a user need in discovery an alpha and then discover a different user needs through further research.