What is expected from a Service Designer in Live

During the Live stage the focus is on operating, improving, and scaling a service that is already in production. The emphasis is on whether the team has built a sustainable, high‑performing service that meets the GOV.UK Service Standard.

The purpose of the assessment is to ensure that the service:

• meets all user needs identified in Discovery and Alpha
• has been tested, iterated and improved during Beta
• is ready to operate as a sustainable, long‑term service

It is the gateway to move into the Live Business as Usual (BAU) phase of service delivery.

Service design involvement

As a Service Designer, much of the core design work will be complete by this stage, but you may still be involved in:

• ensuring the service can be operated sustainably over the long term
• confirming that adequate resources and capacity are in place to support continuous improvement
• establishing clear operational roles and effective business‑as‑usual (BAU) support arrangements
• reviewing Beta performance data and service metrics
• demonstrating that the service is performing as intended against user needs and service standards
• ensuring the service meets accessibility requirements
• supporting thorough testing and quality assurance prior to release
• contributing and sharing blueprints to the wider DDaT library
• maintaining or completing a design history or log to document how the service has evolved over time, capturing what was created, why decisions were made, and how

In short, Live‑stage service design is about embedding good service design into day‑to‑day delivery and operations, while adapting minimal changes to the service to meet user needs and government priorities.

What outputs are expected from an Service Designer in Live

Service Designer outputs should include the design artefacts appropriate to the phase and needs of the service, for example:

• completed to-be blueprints maps – illustrating proposed end‑to‑end experiences across channels showing actors, touchpoints, channels, and dependencies and opportunity areas – where change could have the biggest impact
• completed ecosystem or stakeholder maps – organisations, teams, suppliers, and relationships
• completed empathy mapping – to help the team move beyond what users do, to understand why they do it, grounding service design decisions in real user insight rather than assumptions
• completed policy and legislative constraints summary – what shapes or limits the service
• completed to-be focused user journey – identifying touch points, pain and gain points

---

Improve the playbook

If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.

Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.