扒哥吃瓜

The beta phase is where you take your best idea from alpha and start building it for real. It also involves thinking about how your service will integrate with or start to replace existing services, and preparing for the transition to live.

The stages of beta

There are 2 stages to beta: private and public. You鈥檒l start in private beta by inviting a limited number of people to use your service. This is so you can get feedback and make improvements.

Once you鈥檝e improved the service and you鈥檙e confident you can run it at scale, you take a beta assessment to move into public beta. This involves opening up your service to anyone who needs it. If you鈥檙e replacing a legacy service, keep the legacy service running until your new service moves into its live phase.

Book your assessment 6 weeks before the date you want.

You can .

What you need in place for beta

Structure your beta phase so you can roll out the service to real users. This helps you minimise risk and gives you more opportunities to learn and iterate the service.

During beta, make sure:

• the service team has the capacity to sustain that learning and iteration throughout the beta period
• support staff can cope with new users who might struggle to use the service, including in ways you have not foreseen

What to focus on during beta

Build on the understanding of user needs and the solution you identified in alpha. Focus on making sure that the solution you鈥檝e chosen works as well as possible by carrying out user research. Start to gather data on how successful the service is based on the success metrics you identified in alpha. Iterate the service based on what you learn.

Meeting the Service Standard at beta

Meeting points 2 and 3 of the standard at beta involves slightly different things than it did at alpha.

Solving a whole problem for users

To meet point 2 of the standard, you鈥檒l need to show how your service fits into the wider user journey and supports users from start to finish.

Getting the scope of your part of the journey right

At alpha, you鈥檒l have tried different approaches and developed an idea of how to scope your transaction so it makes sense to users.

Use the beta phase to continue to test and refine that scope.

Joining up with the user鈥檚 wider journey

At alpha, you鈥檒l have worked out whether your service is part of a wider journey. At your beta assessment, you鈥檒l need to show how the service you鈥檝e built operates within that wider journey, working across organisational boundaries where necessary.

For a 扒哥吃瓜 transaction, you鈥檒l need to agree the following things with the 扒哥吃瓜 team at GDS before going into public beta:

• how the transaction will join up with 扒哥吃瓜 guidance or any start page
• a subdomain name and any content changes needed

Working in the open

Continue to work in the open during beta. For example, blog about your work and invite operational delivery colleagues to show and tells so they know what you鈥檙e doing.

If what you鈥檙e building at beta is going to be part of a wider journey involving other organisations or services, it鈥檚 especially important to talk publicly about your plans. It鈥檚 also worth looking into whether you could start or join a service community.

Dealing with constraints

You鈥檒l have used the alpha phase to understand any constraints that are likely to affect your service.

For example, contracts or the organisation鈥檚 plans for a wider change programme might influence how fast you can move away from legacy technology.

At the beta assessment you should be able to explain how the organisation as a whole is making reasonable progress towards addressing these constraints.

Reusing users鈥� information where possible

If you鈥檙e building a service that reuses information users have already provided to another part of government, you鈥檒l need to show that users鈥� information is being shared in a way that鈥檚 secure, stable and works at scale. This might be through an Application Programming Interface (API) that follows the government API standards.

You鈥檒l also need to make sure any information sharing happens in a way that protects users鈥� privacy.

Providing a joined up experience across different channels

Point 3 of the standard says that you should work towards providing a service that works well across all the channels a user might use to access it.

You鈥檒l need to show that you鈥檙e making reasonable progress in improving the user鈥檚 experience in different channels.

For example, by:

• testing and iterating letters users get from the service
• improving the way a call centre refers people online

You should also be able to explain:

• how you know your assisted digital support model helps users online
• how you鈥檝e set up your user support model

You should also be able to show that the organisation as a whole is tackling any long term constraints that make it difficult to improve offline channels. Like a process for creating automated letters that makes it expensive to change things.

You should be able to explain how you鈥檙e involving colleagues from operational delivery in:

• prioritising what you work on
• designing how the service works - for example, by inviting them to attend and analyse user research

And you should be able to explain the organisation鈥檚 process for solving problems that show up in one channel, but need to be fixed by making changes in another.

Making sure everyone can use your service

As part of providing a service that everyone can use, at your beta assessment you鈥檒l need to show how you鈥檝e run regular accessibility testing on your service and run research sessions with disabled people.

You鈥檒l also need to talk about the results of your accessibility audit and fix any issues before moving into public beta.

You鈥檒l need to show that you鈥檝e considered whether the service has any pain points that might lead to people being excluded, and what steps you are taking to address them.

When you move into public beta, you will need to publish an accessibility page for your service.

Things you might be asked at assessment

There鈥檚 no specific set of questions during an assessment, but you鈥檒l usually need to talk about how you use technology. For example, you may be asked how you鈥檙e:

• deploying software safely and often, without disrupting users
• securing your service so users鈥� data stays safe
• working with cookies and similar technologies
• making source code open
• managing the limits placed on your service by the technology stack and development toolchain you鈥檝e chosen
• using open standards and common platforms
• managing service availability and the effect on users if the service is unavailable
• testing your technology

You鈥檒l probably also be asked about:

• your beta dashboard and the performance data you鈥檝e published
• how you鈥檙e using styles, components and patterns in the
• your future user research plans and budgets

If you鈥檝e created any new design patterns - or learned anything useful about an existing design pattern - you should share what you鈥檝e learned through the .

Moving from public beta into live

Read our guidance on how the live phase works to find out what operating a live service involves.

You can book an assessment when you think you鈥檙e ready to move into live.

Related guides

You may find these guides useful:

• How the discovery phase works
• How the alpha phase works
• How the live phase works
• Retiring your service