1.1. What is Alpha?

Alpha is an experimental phase. It’s an opportunity to check if you are building the right thing, before you go ahead and start building a working service.

It’s the second stage of the service design and delivery process. During Alpha, you test the hypothesis formulated in Discovery by building prototypes in code, exploring different ways of meeting your users’ needs.

It’s a time to be bold with service design, challenge traditional approaches to solving the user need, and quickly validate them with user research. It’s okay (and highly recommended) to throw away the prototypes you build afterwards.

Alpha is also the time to establish the team’s delivery approach and ways of working. You’ll apply the user-centred, cross-functional and multi-disciplinary principles from Discovery to a team that is making software. You’ll form a routine of continuously building and testing new ideas, collaborating around the prototypes, and regularly presenting your findings back to stakeholders.

From what you learn, you will be able to define the future vision for the service - what a real solution could look like to users, that works across the boundaries of multiple agencies or tiers of government.

Within this vision, you can then scope a Minimum Viable Product (MVP) - the simplest thing you can build that meets the user need. The MVP will set out the scope what is built in Beta. Then, drawing from the technology research and mapping performed in Discovery, you make choices on the technology you will use to build it.

1.0.1. What Alpha is not

Alpha is not about building a working service. It shouldn’t be perceived as building ‘phase one’ of the Beta.

Although you may decide to do so, there’s no expectation that teams will release their prototypes in public (sometimes called a ‘public alpha’). However, a public release might be worthwhile if you’re illustrating brand new ideas or patterns.

Alpha is not about validating what users like and dislike. Your success measures should be focussed on how well prototypes meet users’ actual needs.

It’s also not just restricted to prototyping only ideas constrained by current business, technical or time constraints. You should think big and explore a vision for the future, so you can validate if the effort to implement this over time would be worthwhile.