Getting started with the service design and delivery process

Understand and communicate the value of building services using the process.

The service design and delivery process is a new way of delivering government services that makes it easier and quicker to build the right thing for users.

It’s important to communicate these values to decision makers and people in teams to help everyone understand why we should follow the process.

[toc]

Meeting the Digital Service Standard

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

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

Start with user needs, not government needs

Traditionally, government has built services in response to policy needs. Teams would capture requirements, get the resources they needed and then would build and launch the thing. User needs would be discovered after the thing was built and finished.

Caption: Traditional service design and delivery in government

The service design and delivery process changes this to start with user needs. The team continues to research with users through all stages to check they are building and improving the right thing.

"Diagram showing moving through Discovery, Alpha, Beta and Live stages and activities with users. Discovery is shown with 2 speech bubbles, representing deep research. Alpha stage shows 2 users, representing testing prototypes with users. Beta stage shows 4 users, representing testing a service more widely with users. Live stage shows many users, representing ongoing process of improving the service based on what users need."

Caption: The service design and delivery process

Stages of the service design and delivery process

The service design and delivery process is an agile approach with 4 stages:

  • Discovery stage — the team gets a deep understanding of the users and their needs, and developing hypotheses to solve the problems
  • Alpha stage — the team builds prototypes to test the hypotheses
  • Beta stage — the team builds and tests a solution based on the hypotheses validated in Alpha
  • Live stage — the team is changed to maintain and improve the service

The stages build on each other but they don’t always go in order. Sometimes a service might go back to an earlier stage (for example, if a service in Beta needs to go back to Discovery to work on a different problem).

Service design and the double diamond

The first 3 stages of the service design and delivery process are similar to the double diamond phases of discover, define, develop and deliver:

  • In the first half of the Discovery stage you go wide with user research to understand the problem (discover phase).
  • In the second half of the Discovery stage you narrow in on the biggest pain points to really understand them so you can define hypotheses (define phase).
  • In Alpha stage you test your hypotheses using prototypes until you can define a minimum viable product (develop phase).
  • In Beta stage you build the minimum viable product (deliver phase).

"Diagram showing moving through Discovery, Alpha, Beta and Live stages and activities with users. Discovery is shown with 2 speech bubbles, representing deep research. Alpha stage shows 2 users, representing testing prototypes with users. Beta stage shows 4 users, representing testing a service more widely with users. Live stage shows many users, representing ongoing process of improving the service based on what users need."

Caption: Double diamond phases of discover, define, develop and deliver

Get support from decision makers

To get support and budget to work in a new way you need to manage the risks in changing the way things have been done previously.

The service design and delivery process helps you add value quickly and regularly check that you are building the right thing. This reduces the risks around working to a large release with limited research to support it.

Make sure that you understand the organisation's goals. You may need to make a business case that shows how using the process will help you meet these goals (for example, the process will help you build quicker, which reduces the cost of running a team).

Be clear from the start what support you need from other people. This might include the authority to recruit the right roles and capability for the team.

Find out how you need to report on your work. The process uses agile techniques that give you lots of opportunity to show how you are working and produce artefacts to communicate progress.

The process helps you build quickly and reduce risk

The service design and delivery process helps teams start delivering quickly. It also helps them to adjust their work to new information they get about your users and their needs. This reduces the risk of building the wrong thing.

Other governments, including the UK and the US, are following similar processes to make sure they add value to their citizens. It’s also part of meeting the Digital Service Standard.

Deliver the right thing

The process focuses teams on building end-to-end services. This helps people to get things done in the way that suits them best. It also helps users with additional needs to get things done.

Deliver quickly

Frequent incremental releases increase value for users and give feedback on what needs more work. This helps the team to prioritise its resources so they keep building what users actually need.

More visibility

Regular showcases of work are built into how teams follow the process. They discover very quickly if something is not meeting user’s needs.

More adaptable

The process is iterative and transparent, with quick feedback loops. Teams learn more about user needs earlier on, and can make better decisions about how to meet them with the available resources.

The process helps teams work in progressive increments designed to meet specific needs. They can test those parts of the service and quickly adjust to iterate them.

Manage risk

The process allows teams to break large risk into smaller, more manageable risks. Teams tackle the most valuable thing first. 

Teams can also test assumptions, especially the risky ones, early. This allows them to make data-driven decisions based on rigorous research.

Releases become routine for the team rather than major milestones. They won’t waste time working towards a big release and find out it doesn’t help users.