Beta stage: building and testing the service

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

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

You will keep testing the service with users first in a private Beta and then a public Beta.

[TOC]

Meeting the Digital Service Standard

You must follow the service design and delivery process to meet Criteria 3: Agile and user-centred process of the Digital Service Standard.

The Digital Service Standard guides teams to build services that are simpler, clearer and faster.

The team you need in Beta stage

The multidisciplinary team established in Alpha should stay on in the Beta stage to keep the existing empathy, context, and momentum.

You might need to bring in different roles and capability during Beta, including (but not limited to):

  • web operations expert
  • ethical hacker
  • data analyst.

What to do in Beta stage

At the start of Beta stage, you take the prototype you agreed on at the end of Alpha stage and build a minimum viable product. You will release this service as a private Beta.

The team will keep iterating the private Beta as they test it in short rounds of user research. These rounds of feedback become shorter as the team refines the product.

You keep running the private Beta service until you have a functioning, end-to-end service. You then open it up as a public Beta service that people can use alongside the existing service. As real users trial the new service you will keep testing it to find out how to improve it.

Once the public Beta service has proven to be a better solution, you can move on to the Live stage where the public Beta service will replace the existing live service.

The main activities in Beta are:

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

These activities help you to:

  • 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.

The team will keep updating the artefacts developed in the previous stages. This includes:

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

How to work in Beta stage

In Beta stage 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 stage:

  • 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 (DoD) and other details that help the continuous flow of backlog items.

Your team should use agile delivery practices, including:

  • continuous integration and delivery
  • test-driven development (TDD)
  • automation
  • incremental design
  • pair programming.

Releasing the private Beta and public Beta

Once you have built the minimum viable product you will release it to test with real users, first as a private Beta and then a public Beta, alongside the current service.

Your research should help you find the best way to host the new public Beta service. This might be a new subdomain, sub-directory, or a domain name.

Apply for a new domain name through the gov.au 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 more control over the type of user that gets to use 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, who can choose to use it if they are willing to try something new.

Measuring performance

You need to measure and report on the performance of your service. You will have started preparing for this in the Discovery and Alpha stages.

Performance metrics are sources of information that can help you find out whether your service is meeting user needs. They make sure that the decisions you make to improve your service are based on evidence.

You will need to:

  • put the measurement plan you developed in Alpha stage into action — this means integrating your APIs, setting up your analytics and so on
  • test the plan’s outcomes with stakeholders
  • iterate and improve the plan – consider sustainability over time and only collecting the information you need.

During Beta, you will need to:

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

How long the Beta stage takes

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

How you know Beta stage is finished

At the end of the Beta stage, 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 by users
  • made a prioritised list of work to be done (your backlog)
  • made a plan for ongoing user research to compliment quantitative data.

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

After the service goes live, the multidisciplinary team should stay in place to keep momentum and make sure the service continues to be iterated and improved.

When you’re ready to move on to Live stage

Your service is ready to move on to the Live stage when you are sure:

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