The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements. You’ll also:
- continue to address any constraints you identified at beta
- continue to develop the service and work with other organisations providing services that are part of the same journey, so that you’re iterating towards solving a whole problem for users
- transition or integrate any existing transactions that meet a similar need to yours - making sure that what you end up with has a scope that makes sense to users
You’ll have your 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 doesn’t 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.
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, or any related services - and make sure none of your changes will have a negative impact.
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.
Meeting the standard to move into live
Before the service moves into the live phase, you’ll need to show that you’ve used the beta phase to build a service that meets the needs you identified at discovery and alpha, testing and iterating based on what you learn.
Solving a whole problem for users
Once you’re in live, you’ll need to continue to develop your service so it forms an intuitive part of the user’s wider journey.
This means continuing to work with teams responsible for related services, and continuing to address any constraints affecting how you can iterate the service.
During public beta, start putting a roadmap together for this work. Items in your roadmap should be ambitious, at the level of things like:
- continuing to make sure that transactions are scoped in a way that makes sense to users
- starting a service community (or joining an existing one) to support others working in your problem space
- continuing to address any constraints you identified at beta (for example, with legacy technology)
Providing a joined up experience across channels
Before you move into live, you’ll need to make sure the people who support your users understand the online part of the service.
This might involve things like updating call centre scripts, providing training or finding a way for operations staff to walk through or familiarise themselves with the service.
Other things to consider before you move into live
Before the service goes live, you’ll also need to make sure:
- you’re securing the service’s information
- you’ve got appropriate metrics in place to measure the success of the service, based on what you’ve learned during beta
- the service meets accessibility requirements you’re able to maintain uptime and availability and monitor the status of the service
- you’re able to continue with vulnerability and penetration testing
- you’re able to continue testing service performance
- you’re able to maintain quality assurance
- you have addressed, or have plans to address, any pain points that might lead to people being excluded
If you’ve created any new design patterns - or learned anything useful about an existing design pattern - you should share what you’ve learned through the GOV.UK Design System.
When you need to retire your service
You need to retire your service if you find out users don’t need it anymore - or that so few users need it that it’s not cost effective to keep running it in its current form.
Updated to match the requirements outlined in the new standard.
Added guidance on how to meet government accessibility requirements in live.
Added the need to continue doing user research in live.
Guidance first published