How the beta phase works

The beta phase is where you take your best idea from prototyping 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.

Structure your beta phase so you can roll out the service to real users - while minimizing risk and maximizing the potential to learn and iterate the service. Make sure:

support staff are aware and engaged on changes to system and user flows
Truss and client are prepared to adapt to how new users may use the system in unforeseen ways

You’ll start out in ‘private beta’. This involves inviting a limited number of people to use your service so you can get feedback and improve it.

Once you’ve improved the service and are confident you can run it at scale, you can move into ‘public beta’. This involves opening up your service to anyone who needs it. If you’re replacing a legacy service, keep the legacy service running until your new service moves into its live phase.

Things to pay attention to in beta

By now you’ll have developed a strong understanding of your users’ needs and, by the end of prototyping, chosen a way of meeting those needs.

During beta, focus on making sure that the solution you’ve chosen works as well as possible by carrying out user research and starting to gather data on how successful the service is based on the success metrics you identified in prototyping. Iterate the service based on what you learn.

Solving a whole problem for users

Getting the scope of your part of the journey right

At prototyping, you’ll 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’s wider journey

At prototyping, you’ll have worked out whether your service is part of a wider journey. At the end of your beta phase, you’ll need to show how the service you’ve built operates within that wider journey, working across organizational boundaries where necessary.

Working in the open

Continue to work in the open during beta - for example, by blogging and by inviting operational delivery colleagues like the back office team, customer support team etc to open show and tells, demos so they know what you’re doing.

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

Dealing with constraints

You’ll have used the prototyping phase to understand any constraints that are likely to affect your service.

For example, in prototyping you identified the constraint that contracts or the organization’s plans for a wider change program might influence how fast you can move away from legacy technology. In beta, you can create a rollout plan to slowly shift from the legacy platform.

Accessing user’s information securely

If you’re building a service that reuses information users have already provided, you’ll need to show that users’ information is being shared in a way that’s secure, stable and works at scale. This might be through an Application Programming Interface (API) that follows the API standards of the client.

You’ll also need to make sure any information sharing happens in a way that protects users’ privacy.

Providing a joined up experience across different channels

You’ll need to show that you’re making reasonable progress in improving the user’s experience in different channels. “For example, this could be ensuring that the offline part of the Milmove journey is positive. Or signposting about your new service in other places where users currently might go for help.

You should be able to explain how you know your assisted digital support model meets the needs of users who need help doing things online. And how you’ve set up your user support model.

You should be able to explain how you’re involving colleagues from operational delivery (back office team, customer support members etc) in:

prioritizing what you work on
designing how the service works - for example, by inviting them to attend and analyze user research, participate in brainstorming sessions.

You should also think about how your product impacts wider existing process and bubble it up to the client if changes needs to be made elsewhere.

Making sure everyone can use your service

As part of providing a service that everyone can use, you’ll need to show that your service is accessible. This can be from running accessibility tests and running research sessions with disabled people.

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

You’ll need to show that you’ve considered whether the service has any pain points that might lead to people being excluded, and what steps you are taking to address them.

Other things to consider at beta

You’ll usually need to talk about how you use technology, for example:

the way you deploy software, proving you can deploy frequently without impacting users
how you’ve made your service secure so users’ data is safe
how you’ll work with cookies and similar technologies
how you’re making source code open
how you’re managing the limits placed on your service by the technology stack and development toolchain you’ve chosen
how you’re using open standards and common platforms
what the effect would be if your service was unavailable for any length of time and how you’re managing this
how you’re testing your technology

Moving from public beta into live

You’ll have your go-live assessment at the end of the public beta phase. Spend public beta preparing for live.

Running your service during live

You’ll need to work out how to run your service sustainably during live. This does not necessarily mean having an agile team on the service 100% of the time. Spend time during public beta working out what level of continuous improvement it makes sense to support, and who you’ll need on the team. You will want to include factors such as:

bug triage load
refactors and technical debt strategies
package and security updates
new compliance requirements

As in beta, improvements you make during live should be:

based on user research
tested to make sure they work with different browsers and devices
tested for accessibility
quality assured

You should also make sure you are clear on the effects that changes will have on offline channels (such as: in office organizational memos and paperwork), or any related services - and make sure none of your changes will have a negative impact on user experience.

You’ll also need to spend time during public beta reviewing the performance metrics you set to check the data you’re collecting will tell you whether your service is performing as it should.

## Related guides

You may find these guides useful:

Source Credit: This content is an edited reprint from the GOV.UK Service Manual under the terms of the Open Government Licence v3.0.