Beta stage: building and testing the service

In Beta, the team builds an end-to-end service based on what they learned in Alpha. They keep iterating until it is ready to test in a private Beta release and then a public Beta release.

In the Beta stage you focus on building the minimum viable product you defined at the end of Alpha. This is the simplest thing you can build that meets the user need. 

Time needed: the length of time Beta takes depends on the scope of your product. If you have the right team in place, it should take a few months. 

The team you need in Beta 

The multidisciplinary team you established in Alpha should stay on in Beta. This keeps the existing empathy, context, and momentum. You might need to bring in different roles and capability during Beta.

These may include: 

  • web operations expert
  • ethical hacker 
  • data analyst. 

What to do in Beta 

In Beta you will take the agreed prototype from the Alpha stage and build a minimum viable product.  

The main activities in Beta are: 

  • development 
  • design 
  • usability research 
  • accessibility testing 
  • metrics monitoring. 

Private and public Beta 

You will release in private Beta, testing in short rounds as you continue to update and iterate. As your team refines the product, feedback rounds will become shorter. Continue running the private Beta until you have a functioning end-to-end service. Once you have a functioning end-to-end service, you can open a public Beta people can use alongside the existing service.

As real users trial the new service you will continue testing to find ways to improve it. 

These activities help you: 

  • build your service and plan for its launch 
  • solve any remaining technical or process-related challenges 
  • improve your service by testing it with users and releasing updates. 

Update artefacts 

The team will continue to update the artefacts developed in the previous stages. This includes: 

  • vision 
  • user journey 
  • user story map 
  • decision register 
  • prototype. 

How to work in Beta 

In Beta the team should build the real thing with the minimum features that support the end-to-end user journey. Make it accessible and secure. Avoid the temptation to build a polished version of your Alpha prototype. 

During Beta: 

  • make sure the team’s focus switches from experimentation to prioritising the minimum viable product 
  • work as a team on actual user stories — make sure you focus on needs, not wants 
  • define and iterate a workflow, including ‘definition of done’ and other details to help the flow and work through the backlog of items. 

Use Agile Delivery practices

Your team should use agile delivery practices, including: 

  • continuous iteration and delivery 
  • test-driven development  
  • automation 
  • incremental design 
  • pair programming. 

Release a private Beta and public Beta 

Once you build the minimum viable product you will release it to real users, first as a private Beta and then a public Beta, alongside the current service. Your research will help you find the best way to host the new public Beta. This might be a new subdomain, sub-directory or a domain name. 

Apply for a new domain name through the Domain Administration System

Private Beta 

A private Beta is a Beta that isn’t open to everyone. Don’t launch your service publicly in private Beta, make it invite-only. A private Beta allows you to: 

  • have control over the users who test the Beta service 
  • restrict the volume of transactions that go through the Beta service 
  • start small and get quick feedback before releasing the service out to a wider audience. 

Public Beta 

A public Beta is a version of your service that’s available for any member of the public to use. It will exist at the same time as the current available service. This version of the prototype is available to all users, should they choose to use it. 

Measure performance 

You need to measure and report on the performance of your service. You will: 

  • put the measurement plan from Alpha into action, this means integrating your APIs, setting up your analytics and so on 
  • test the outcome of the plan with stakeholders 
  • iterate and improve the plan, consider sustainability over time and only collect the information you need. 

Performance metrics help you understand if your service is meeting user needs and allow you to make decisions based on evidence. During Beta, you will: 

  • capture real performance data for your service 
  • iterate and improve your service through findings 
  • improve your methods to capture data, where needed 
  • plan how you will maintain your data and keep data records tidy. 

How you know Beta is finished 

At the end of Beta, you will have: 

  • launched a private Beta service followed by a public end-to-end service 
  • built a working system that can be used in full
  • made a prioritised list of work to be done
  • made a plan for ongoing user research to compliment quantitative data. 

Make sure you plan how you will meet resourcing needs when the service scales up. 

Your multidisciplinary team should stay in place when the service goes Live to make sure it continues to be iterated and improved. 

Move on to Live stage 

At the end of the Beta, you will have launched a private Beta service followed by a public end-to-end service that can be used in full by users. You can move your service Live when you are sure: 

  • the Beta meets user needs and delivers the full end-to-end user journey 
  • you can support and keep iterating and improving the service until it’s retired. 

When you're ready, move on the Live stage.