This is a guide to help teams going through the live phase of the transactional service design and delivery process. We’ve written it from our experience helping government organizations run live services as part of their work. This guide will evolve over time as we learn more about the things that work (and those that don’t work).

We welcome any feedback and suggestions from your own experiences. To send us your comments, please email us at

What is live?

The live phase is about supporting your service in a sustainable way, and continuing to iterate and make improvements. You’ll also address any concerns you identified in beta.

Running your service during live

You’ll need to work out how to run your service sustainably during live. Unlike the beta phase, you won’t need a full team on your 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 to live

Before your 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.

Other things to consider before you move into live

Before the service goes live, you’ll also need to make sure the digital service standard criteria continue to be met:

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

Last update:
Jun 4, 2019