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.
Back to top
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.Back to top
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:
- web operations expert
- ethical hacker
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:
- 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:
- user journey
- user story map
- decision register
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)
- 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.
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
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.Back to top
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 data.
There are 4 key performance indicators for government services that you must measure:
- user satisfaction
- digital take-up
- completion rate
- cost per transaction
There will be other service metrics you will want to track and report on to help you understand how well your service is meeting user needs and other goals.
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
During the private 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
- build your service dashboard layout
- populate your service dashboard with baseline and current data
- get internal sign-off to publish your service dashboard on the Performance Dashboard
During public beta you will need to:
- publish your service dashboard on the Performance Dashboard
- plan how you will maintain your service dashboard and how you will add improvements to your metrics and data
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.Back to top
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
- made a prioritised list of work to be done (your backlog)
- made a plan for ongoing user research
- published your dashboard
- built a working system that can be used in full by users
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.Back to top
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