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.

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.

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. 

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.

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:

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.

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.

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.

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:

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:

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.