An alpha is about trying out different solutions to the problems you identify. It allows you to gather early feedback before committing to a solution. In effect, it reduces the likelihood of building the wrong thing.

I delivered a successful alpha recently. I wanted to capture my key learnings here.

What key questions should you consider in an alpha?

• Can you show how potential solutions or components might work?
• What lessons can you learn from others?
• What is your riskiest area?
• How will you measure success?
• How will you ensure your service is accessible and secure?
• Are you complying with legislation?
• Is it worth proceeding?

Source

What does an alpha look like?

A typical alpha can be around 8-12 weeks, and can cost anywhere between £120-250k.

Here’s how I structured my project:

• Sprint 1 was about understanding the problem space.
• Sprint 2 was about ensuring we were ready for testing.
• The bulk of the testing occurred in Sprint 3 and 4.
• Sprint 5 was about bringing everything together.

We ran fortnightly sprints and ran the project in an agile way. For our research sprints, we followed the design sprint structure:

• Day 1: set the priorities for the week, start prototyping, user recruitment
• Day 2: continue prototyping, seek feedback, course correct
• Day 3-4: test prototypes
• Day 5: analyse findings, retro, seek feedback from client and prepare for next week

This worked but it did mean the team were working at a frenetic pace, which wasn’t sustainable. We ran three design sprints in total.

What does a typical alpha team look like?

On our alpha we had the following roles:

• Product Manager / Delivery Manager (me)

Led the team throughout the project. They help to set the project’s strategic direction. The client usually provides the product role, but they are often inexperienced, so this is something I usually take too.

• Content designer x 2

Responsible for the content in your service.

• Technical lead and a separate front end developer

Understands the technical environment (APIs, CMS) and is able to explore available technologies, their capabilities, and constraints, as well as help develop any hi-fi / lo-fi prototypes as necessary to test and validate primary research.

• Service Designer

Helps the team to build up an understanding of the end-to end process or service.They help to understand the existing user experience and use this to set the strategic direction. They can also create the visuals of the prototype.

• User researcher

Plan and facilitate the user research. They also take a lead in facilitating synthesis sessions and work with the wider team to deliver high-impact outputs.

Further information

Reflecting on the experience

• Our content designers, having subject matter expertise, helped us when dealing with technical terminology.
• Having the whole team involved in user research meant our user researcher didn’t have to spend a lot of time playing back insights. We were all there. Our researcher concentrated on interviewing, while the team captured notes.
• As we weren’t involved in the discovery, it meant we had to spend the first sprint understanding the subject space. We felt some information was missing (e.g. user journeys) so we spent time crafting those to ensure we understood the users we were designing for. It did mean we went slower than we would have liked.
• Constant prioritisation was key to ensure we delivered a successful alpha. We settled on a sensible scope early on, but as we learned more this would impact the scope. Having open and honest conversations with the client about what was realistic and important, helped us to stay the course.
• Our show and tells were a powerful way to engage with our stakeholders. As we progressed through the project, we did our best to take them on a journey to show how we came to decisions. Tracking any key decision point on a decision log helped to clarify why we went in a certain direction.
• Sometimes we made tough decisions on scope. We wanted to explore some areas but knew that they would need much more time than we had.
• We used a recruitment agency to help us find our users. Ensure you speak to a diverse sample. If you don’t have a recruitment agency, recruit users early through social media or other channels.
• Having the design system made our life so much easier. We could use repeatable patterns across the GOV.UK estate to ensure consistency with other products and services. I lost count of the amount of times users said ‘oh it’s like one of those government sites!’. It meant they were familiar with it, and knew how to use it.
• The GOV.UK prototyping toolkit meant we could create a coded prototype. Even though this process is fast, it is not faster than using something like Invision. Consider using a lower fidelity prototype if you need to move faster.
• It was nice to reflect on the week with virtual tea, cake and games. A healthy positive culture is all about bringing people up, not putting them down. Create an environment where people feel supported.

Other things to consider in your alpha

• Test with users with accessibility needs and assisted digital needs
• Understand offline journey
• Test your riskiest area
• Capture your learnings as you go so you can show how you iterated content and designs

At the end of an alpha, you should have…

• Working prototypes
• High-level plan for Beta e.g. team structure, cost
• High-level technical architecture
• Requirements e.g. user needs and development estimates

I hope this helps when you embark on an alpha.