Alpha
What's an alpha?
After we have identified the problem in a discovery, we turn our attention to a potential solution.
The alpha is all about experimentation. We are expansive and broad in our approach, trying out different ideas to see what might work. We have a solid basis of understanding of the user needs, business and technical requirements, and we continue to build on that as we enter the ideation phase.
Hypotheses are turned into prototypes (mock-ups of ideas) which we then test with users. Insights from testing help to refine our ideas and narrow down the scope.

We tend to work in 2-week sprints, planning, iterating and reflecting. Like a discovery, an alpha typically lasts 3 to 6 sprints.
Our projects are delivered in line with the Government Service Manual.
What value does an alpha deliver to clients?
An alpha delivers validated solutions that take the risks out of projects and inform effective future investment.
Our clients know we deliver evidence-based ideas. We take a balanced view of user-centred and operational needs to help them make informed decisions for the new product or service. Part of our role is to advocate for the best solution. We work with clients to understand where they align and differ internally and help build a case for change, driving a stronger sense of ownership of the proposed solution.
Thanks to the iterative process, we’re constantly amending our work to respond to our most recent findings. We test and course-correct as we go. This gives our clients confidence that what we deliver actually works, addressing genuine user and business needs.
We often pursue multiple ideas at once. This gives us the best chance of finding the right idea. We bring clients on the journey with us, so they can show their stakeholders the value of the work we’re doing. This makes internal buy-in much easier.
Alphas produce a clear scope to take into beta. That includes prioritised backlog and the technical plans to support the development.
What sort of team delivers an alpha?

The team will vary slightly depending on the needs of the project, but typically we’d work in a team like this:
The delivery manager oversees the entire project. They’re responsible for keeping everyone else on track and liaising with the client.
The user researcher, business analyst, service designer and solutions architect will focus on the user needs and user journey mapping, as well as business and technical requirements. The designers create prototypes, then the user researchers and service designers test them with users so we can iterate designs along the way.
The client also plays a critical role. As in a discovery, they are a subject matter expert for the business and sector we’re operating in and keep us on the right path. In the alpha, they start prioritising the backlog with the team, ready for development to start in beta.
Capability key
ResearchDesignTechnologyWhat do you need to start an alpha?
Like a discovery, before any work is done the team must first meet for a kick off. Client stakeholders and full project team meet to:
clarify project goals
set expectations for what will be addressed in the alpha
discuss aspirations, risks and opportunities
align processes that underpin the project and how we’ll work together
Next, we take a deep dive into the discovery report. Even if we ran the discovery ourselves, there might be some colleagues who weren’t on that phase, who we need to get up to speed. If we didn’t run the discovery, this is a really important time to review the work that was done before our involvement. We check it was done to a high enough standard to allow us to successfully run an alpha and then we dive into the detail. This means we’re all on the same page about the problem we’re trying to solve, the context it exists in, the requirements of the users and the opportunities that have been discovered to help address the problem.
Operationalising a project is a big step. We map out a timeline of activities and schedule agile ceremonies (like stand-ups and show-and-tells) to ensure collaboration between our teams and the client. We also set up:
a teams channel for communication
a SharePoint site for documentation
a project management tool like Jira to track our backlog and development
a prototyping tool like Figma, Axure or HTML to build digital prototypes in
a RAID log to track risks, assumptions, issues and dependencies
a design change log to track any decisions we’ve made with the client
Then we’re ready to get into an alpha.

What do we usually do in alpha?
Following the discovery’s more general research into needs and opportunities, we probably want to conduct specific research to inform the design of prototypes. And depending on the quality of the discovery that was done before we started the alpha, we may need further research into the business and user needs. Either way, we’ll need to prepare for our ideation and testing phases which means we need to:
Plan our research. We plan the conversations we’d like to have and the types of users who would have the best insight. That lets our ReOps team hit the ground running with participant recruitment.
Prepare the research materials. Materials include everything from tools to help stimulate conversation to important documentation we have to complete for GDPR. For example, that might be discussion guides or consent forms.
Prioritise user stories. The designers, user researchers and business analysts work with the client to map out user stories and user journeys to prioritise them. To do this, we look at the various needs that have been identified and plot them out in a map that shows the order in which those needs occur. Part of that process is identifying the riskiest and most complex journeys so we can test them.
Understand technical requirements. Part of exploring the options to address our problem statement is considering their feasibility. That’s where the solutions architect comes in. Their job is to work with us to make sure that the plans we’re considering are efficient and make good sense technically.
Once we’ve got some potential solutions to the problem, we need to test them with users. To do this, we create a low-fidelity prototype. It's a simple sketch of an early-stage design concept. Our research and design teams use them to quickly test ideas and identify potential issues, learning from and moving on from versions that don’t resonate with users.
We take these prototypes to users to test their usability, accessibility and how well they fit into the wider system that users experience. With each round of new insights, we iterate the designs and refine them to better address the problem we’re trying to solve. As we progress through an alpha, we create more functional and interactive prototypes that get closer to representing the final solution.
What outputs would you expect from an alpha?
By the end of an alpha, we’ve narrowed down our ideas to a single solution that we can bring to life in beta. We know which solutions suits our client, their users and the technical and financial constraints of the project best. But what details do we need to support that?
The alpha report is a comprehensive report that outlines all the learnings and proposed solutions. It’s the best tool to help the team prepare for beta. It includes:
Product direction – the best solution to answer the problem and the proposed scope of a future beta
‘To-be’ user stories, storyboards and prototypes – documenting what we understand the users’ needs to be in the proposed service and the expected experience of going through the proposed solution, as well as any artefacts that might be directly reused in a future beta
Diagrams and service blueprints - outlining how elements of the service fit together and deliver the proposed experience
Prioritised roadmap and backlog – user stories have been prioritised so when the beta starts there are clear steps to delivering the solution
Documented technical requirements – the technical architect has worked alongside the design teams to make sure any proposed solutions have been vetted and are feasible
Insights from research and recommendations from testing – knowledge of where users have experienced problems and whereto focus future testing
Transition plan - how to decommission the existing service, if there is one, and launch the new one when it’s ready
Sign off from the client – crucial evidence that the job has been done to a satisfactory standard and the client is ready to progress to the next delivery phase
We close down an alpha with a final show-and-tell with the client. Normally we have a larger number of stakeholders from the client join us than for the regular show-and-tells at the end of each sprint. We cover the alpha findings and get sign off that the client is happy with the work we’ve done and the direction for a beta.
For government projects, we may need to pass a service assessment before we can progress to a beta.
Then we’re ready to start building.
Last updated
Was this helpful?