Skip to main content
Creating a new NHS England: Health Education England, NHS Digital and NHS England have merged. More about the merger.

Behind the scenes at COVID-19 vaccination centres

The national booking service is helping millions of people schedule their life-saving COVID-19 vaccinations. James Higgott, Lead Product Manager, gives an insider’s view on how we created the staff-facing products that make up this service and solved some teething problems along the way.

About 17 million appointments have been scheduled through Book a coronavirus vaccination – the public-facing part of the national booking service (NBS) for the COVID-19 Vaccination Programme.

People queueing outside a coronavirus vaccination centre

There are two other lesser-known products which make up NBS, which allow staff to schedule available appointments and manage check people in as they arrive. This is how we designed, released and iterated these 2 staff-facing products.

A brief history

I joined the NBS project in October 2020, soon after it had started. At the time we didn't know when the first vaccines would be approved and when the first appointments would be made available. We just knew it was going to be soon.

My team's role was to get the staff-facing products ready for this launch. If the public were going to book appointments at vaccination centres, we needed to know where the sites were and – most importantly – when they were offering appointments.

The NBS team had already chosen an off-the-shelf product called Q-Flow for this, so we thought our scope was limited to configuring and customising this product, and aligning it with NBS and the wider vaccination programme. However, some early digging revealed that Q-Flow was not going to meet user needs when it came to checking people in on site and we realised we had to build our own check-in app as well.

Asking staff to use poorly designed products wastes their valuable time, incentivises them to create workarounds and leads to errors.

Q-Flow admin console was released to its first users in mid-December. These users set up the first vaccination sites and created accounts for the next wave of users. They added appointments to the system, which were released to the public in early January. They also created user accounts for the arrival stewards who checked the patients in using the 'Check a vaccination appointment' product when they started arriving for their appointments from 11 January.

This initial release to our first users is my standout moment from this project. As this tweet describes, it was a low key thing but we knew it would soon become something much larger. 

Tweet by James Higgott saying "I just launched a live service in the most boring and humdrum of ways - I created user accounts for the first 10 users. The rest will follow."

User research and design

Staff-facing products often don't get the same user-centred design treatment as products which are going to be used by the public. Maybe this is because they're not as high profile, or because they have a smaller number of users.

This is a fallacy though. Asking staff to use poorly designed products wastes their valuable time, incentivises them to create workarounds and leads to errors, which require further valuable time to resolve and can impact the public’s user experience.

Getting in front of our actual users – staff at vaccination centres – when those vaccination centres didn't yet exist was problematic.

There's also a commonly held belief that products used by NHS staff do not have to meet the same accessibility standards as products used by the public. This is incorrect. The law is clear on this: websites and apps used by employees must meet WCAG 2.1 AA accessibility standard. The Public Sector Equality Duty (which is how public sector bodies must honour the Equality Act 2010) makes it illegal to discriminate against people based on protected characteristics, which includes the tools they must use on the job. If you can’t hire someone because they can’t use an inaccessible product, you are breaking the law.

That said, getting in front of our actual users – staff at vaccination centres – when those vaccination centres didn't yet exist was problematic. So we chose to do user research with proxy users. NHS Digital's Implementation and Business Change team put us in touch with people who ran NHS services at a regional and local level and we tested our prototypes with them.

Because Q-Flow is an off-the-shelf product we didn't have free rein to design it how we wanted, but user research was still essential to understand how to configure and customise it. Check a vaccination appointment was designed and built from scratch (using the NHS digital service manual's design system) so we had more control over the user experience of that product.

We asked questions like:

  • what would they expect if they were a user of Q-Flow?
  • how would they expect tasks to be split between regional and local level, and between different people?
  • what challenges might they face doing things like scheduling appointments?
  • how would they turn people away who lacked valid appointments?
  • could they perform the tasks that our real users would need to, using the software we were developing?

The answers they gave informed a number of changes we made before go-live and helped us create and prioritise a backlog of future iterations.

Being agile

NBS is just one part of the Tech and Data workstream for the COVID-19 Vaccination Programme. Elsewhere, there are other teams maintaining the list of who's eligible, sending invitations to book, recording consent and vaccination events, and capturing and sharing data. And this workstream is just part of the wider vaccinations programme with other workstreams focused on buying vaccines, transporting vaccines, setting up sites and so on.

All of these component parts were dependent on one another and they were all being designed and built at the same time. A change of plan in one place rippled across the programme, requiring workstreams and teams to redesign and reprioritise.

Instead of being used by just a small number of large sites, NBS was now intended for a large number of small sites as well.

For example, we initially thought there would be a 3 to 4 week gap between doses but in December this gap changed to 11 to 12 weeks. We changed how far ahead sites could publish appointment availability and updated guidance about how to schedule appointments so that the public could book doses 1 and 2 at the same site.

Also in December, it was decided that NBS would be used by community pharmacy sites as well as mass vaccination centres. Instead of being used by just a small number of large sites, NBS was now intended for a large number of small sites as well. We scaled and performance tested the service, and a new Onboarding team was formed to help train and set up the hundreds of new sites that were a result of this decision.

Working in an agile way meant we could respond to these changes. It wasn't easy and a lot of people put in a lot of hours to make it happen, but it would have been impossible if the NBS team wasn't following agile principles.

Teething problems

When designing and launching a new service you'd normally expect to run in a small-scale trial for a while before making the service more widely available. Our trial phase with just a handful of vaccination sites lasted about a fortnight. We now have around 450 vaccination sites offering appointments all over the country.

As you'd expect, we experienced a few teething problems:

  • one site in Newcastle entered an incorrect Longitude which located it in the middle of North Sea, so far from the mainland that it didn't appear when users searched for a site in the North East. We fixed it and put in some extra checks to avoid similar mistakes in the future
  • one site manager accessed an obscure part of Q-Flow and changed the default appointment duration across all sites, inadvertently limiting the total number of available appointments. We locked down permissions to make sure that didn't happen again
  • one small site with capacity for about 150 appointments a day accidentally published tens of thousands of appointments for its first week of operations. By the time the mistake was spotted and fixed, it had about 5,000 appointments booked over just a few days. The local team stepped up, brought in more people and vaccinated everyone without having to cancel a single appointment
  • to make their daily reporting tasks easier, around half of sites opted at first not to use Check a vaccination appointment and to rely instead on printed appointment lists or Excel files. We promoted this product and gave site managers better reports in Q-Flow, and use of this app has risen to over 80%

Where do we go from here?

The long-term future of NBS is still being considered, but in the short- to medium-term we are planning many iterations to the staff-facing parts of the service:

  • a new report to help site managers with operational planning and performance measurement
  • allowing site managers to reschedule appointments or move them to a different site
  • bulk cancellation of appointments in case of emergency closure

We are continuing with user research to keep us focused on the changing needs of site staff, and we are working with vaccination site managers to design and test our iterations.


Last edited: 7 January 2022 2:44 pm