Alpha

Alpha is the second phase in the product or service life cycle. Alpha is all about trying and failing – testing different ideas and prototypes until we find one that works that we can take forward into the next phase.

Alpha is about trying out different potential solutions to the problems we learned about during discovery. During alpha, the team works on various prototypes – this is an opportunity to try out different ideas and approaches or even challenge the way things are currently being done by trying something new.

While working in agile teams, you will hear the phrase failing fast.

This means not being afraid to try and fail multiple times – if an idea does not work, just discard it and move onto something new. It’s all about adapting and applying what you learn with each failure to the next idea, not wasting time trying to make something work if it’s clear it’s not going to.

User researchers play a key role in alpha by testing prototypes with users, gathering feedback, and helping teams make evidence-based decisions before moving to beta.

The more information user researchers are able to provide the team from work done during discovery, the better their initial ideas and prototypes will be, which means that what we then build and test during alpha is more likely to lead to something successful that we take forward to beta.

What do user researchers do during alpha?

During alpha, the goal of user research is to:

• improve the team’s understanding of your users and their needs
• test different design ideas and service prototypes with likely users
• learn how to build or improve your service so that it helps users achieve their goal

Service prototypes are simple versions of the service (or sometimes just parts of the service) that are just defined enough to test an idea. User researchers assist with testing the usability of these different design prototypes with users, but you should also continue to conduct interviews and visits to deepen your understanding of your users and their needs.

You should also be able to show that you’ve considered inclusion in the wider sense.

Research in alpha should continue with the same broad range of users you interacted with in discovery, including those with limited digital access, knowledge or confidence and users who are disabled or who need additional support. You should also include people who provide the service or who support other users, such as caseworkers, call centre agents and charity workers.

It is essential to consider if there will be pain points for particular groups of people when accessing the service and how the team intends to stop them being excluded for any reason.

With an online prototype, you cannot apply the full range of technical accessibility tests you would use for production code, as prototypes are often not sophisticated enough to be tested with assistive technology used by disabled users. Testing with paper or offline prototypes also means that you cannot test with some users, such as users who are blind or partially sighted.

These things can be tested later in the beta phase, but it is important that these things are acknowledged in alpha so that they are not forgotten later – testing for accessibility should be prioritised as part of the beta phase.

User researchers should also be thinking about the service from end to end.

Point 3 of the GOV.UK Service Standard – the guidelines we adhere to when designing government services – is ‘provide a joined up experience across all channels.’ This means considering all the ways that users interact with a service, including all tools, transactions, support and offline steps, and user journeys that start with third-party or non-government organisations.

This is important because sometimes the team can be working on something that seems like a great idea, but does not actually fit with the wider user journey and would create additional barriers for the user later on. It also means that you can highlight risks or things may need to be changed for the service to work for all users.

For example, if part of a service requires users to be sent a letter, is it possible for the content of that letter to be changed to reflect a new or updated digital service? Does this service include all users, including those without permanent addresses?

It is often not possible to directly change these elements, but teams can collaborate with other teams across government to recommend changes if a need becomes apparent.

At the end of your user research in alpha, you should have:

• a better understanding of user needs, including support and access requirements
• feedback on how well the team’s design ideas work for users
• helpful insight into usability issues related to layout, functionality and content

When the team is confident that the proposed design solution will meet the needs of your users, including those with disabilities and support needs, the team can move forward into the next phase – beta.