That pharmacy's only option was for a family member or a friend to pick up the medicine and to pay for it at the time of collection. As we have no family or friends living nearby, this wasn’t a suitable solution, so my wife could not receive the medication she was relying on. 

Our alternative option was for my wife to cancel the order, find a new pharmacy which could deliver the medication, set that as her nominated pharmacy on the app, and then re-order her medication. However, this would’ve triggered an asthma review check at her GP practice, which she could not have attended due to being ill with COVID-19.

All individual parts of this service worked on their own: the app was able to trigger a medication order, the pharmacy prepared the order and notification was received, and it was possible to change your nominated pharmacy. But put together, they didn’t deliver the required outcome for our particular situation: my wife could not get her medication .

Although I will cover the definitions and products later, what really matters is that we understand the difference between an output and an outcome.

Ordering a repeat prescription:

Outputs are delivered by products or sub-services. They are tangible, for example a confirmation message via text, email or letter.

Outcomes are the goal for the user, the solution to their problem. For example, having the medication in their or their carer's hand, with relevant instructions and the knowledge and skills to use it.

Outputs and outcomes are both essential to the delivery of a service, but it is important to be clear which is being used to assess effectiveness. If we measure the number of repeat prescriptions ordered, rather than the number of medications successfully delivered to the right person at the right time, we may think the service is performing better than it is. The outcome is dependent on the output, but the outputs do not give the full picture.

As Matt Edgar wrote in 2015, most of government is mostly service design most of the time.  This is also true for the National Health Service.

Services add value to products. Providing a service means that the user doesn't have to know how to do something or is not able to do it. In healthcare, this could be taking a COVID-19 test, for example. The test kit is the product, but you can also ask a health professional to take the sample for you. This is the service.

In the case of vaccinations, the vaccination itself is the product, but I'd assume a few people would know how to safely administer it. Therefore, the NHS is providing it as a service, which ensures the vaccine is administered correctly and safely and any possible complications are taken care of.

I do agree with the common argument that the NHS website, or the NHS App are simply not just products.

Products and platforms are often wrapped in services, and also act as front doors to more services. For example, the NHS App is:

• a product you can download from the app store on your phone. It's made of code and that code sits on a server or your phone
• wrapped in a service layer that ensures it is available and if it isn't, work is done to ensure it will be as soon as possible. So, you could also call it a service
• a platform that enables regional service providers to provide available services to their local people. These may vary from region to region. As a platform, the NHS App enables exchange between the regional service providers and the public
• a front door through which you can access services, such as order a repeat prescription

The NHS website is very similar. The point is, the website or the app is the product and if we only focus on that, we don't achieve the outcomes. The services you can access via the app deliver the outcome, for example 'order a repeat prescription', not the app itself.

Service design is the process of orchestrating the end-to-end service from when the users become aware of the service, to when they exit and everything in between.

Service design is about designing the full stack top-to-bottom, from the visible touchpoints to the back-end systems and the policies, standards and target operating models.

Service design must also be cross-channel and not just focusing on the digital. Telephone, face-to-face, paper and assisted digital channels must also be designed as one service - not separate channels.

This end-to-end, top-to-bottom and cross-channel view also means that the staff members delivering the day-to-day service are also our users, and they have user needs. We should not just focus on the public or the patient.

Service design is what ties all these together, with teams that are multi-disciplinary, with a diverse set of skills and perspectives, and by forming wider service communities empowered to solve the whole problem.

The 'Get vaccinated for a coronavirus' service consists of number of different products and services, delivered by several different providers in national, regional and local levels. The whole end-to-end service consists of a number of products, for example the NHS website and the point-of-care products to name a few. But it also consists of nested services, like 'Book and manage your appointment'.

Together, all of these will solve the problem for the user which is 'I need to get vaccinated for coronavirus' and thus deliver the outcome of being successfully vaccinated.

Service: Get vaccinated for coronavirus

Like all services, the nested service, 'Book or manage your appointment' also delivers an outcome: either the person has been able to successfully attend their appointment or not. It also delivers outputs, such as the confirmation of the booking.

What’s the difference?

The person may have received their confirmation (intended output achieved), but then be unable to attend their original booking. Without the ability to easily reschedule, the intended outcome will not be achieved.

Therefore, if we simply measure the number of booking confirmations, we miss the point – we don’t know whether we have achieved the outcome.

The delivery of this outcome is not the sole responsibility of the online part of the booking service. You can also call 119 to book or amend your appointment. All these services are related, so you need all the teams to work together across policy, digital and telephone to effectively solve the problem of booking and managing appointments, delivering the intended outcome.

An easy, practical solution to this, which doesn’t need any re-organisation of existing teams, is to form a service community with all the different teams across the system who are involved in achieving the outcome.

This idea of forming communities to design a whole service is not new. The Government Digital Service (GDS) discussed them already back in 2017 as a way to connect the different parts of the government together to deliver services.

Service communities should not just be about sharing ideas and talking about the service, but actively discuss issues, performance, user research findings and other feedback loops, prioritise backlogs, and come up with hypotheses and plans how to validate them. Together, as one service community, the teams can then agree who is in the best place to solve a particular problem.

Through collaboration they are more likely to be able to solve the problem, deliver the service, and achieve the outcome, not simply deliver their outputs in isolation of each other.

Too often, we still deliver products, or technical features, which simply exist as a token of a delivery at the end of a project, and then measure our efforts on the number of outputs delivered.

We must shift to focus on outcomes (not outputs) and the services which deliver those, and form multidisciplinary teams empowered to solve the problems and deliver the intended outcome.

For us in the NHS, working together is the only way. The design and delivery of health services is so fragmented, we simply cannot deliver the meaningful health outcomes without forming our teams around the services and working together.