In the eighteen months between March 2023 and January 2024, the NHS England online GP registration service grew from 837 participating practices to 2,312. Patient registrations rose from under 200,000 to over 900,000. The target set by NHS England, originally aiming for 2,000 practices by December 2023, was met ahead of schedule.
These are the numbers a board likes to see. They are also the wrong place to start the conversation. The interesting question is not how the service grew. It is why an earlier generation of similar digital services, aimed at the same population, with the same nominal sponsor, did not.
The orthodoxy of the well-formed user
Most public-sector digital services have, until recently, been designed around an implicit user. The implicit user has a fixed address. They have photo identification. They speak English well enough to read a government form. They hold a smartphone with a recent operating system, and they have a stable enough living situation to receive correspondence.
This implicit user does exist. They make up the bulk of the population. A service designed around them works for most people most of the time, and the metrics will show steady, unremarkable growth. The cost of the assumption is invisible at the centre, because the people excluded by it are the people least likely to complain to the people most likely to listen.
The cost is real. It compounds at the edges of the population, where the demand for services is often highest. People without fixed addresses are more likely to need primary care, not less. Migrants are more likely to need help reaching the system, not less. The well-formed-user assumption produces services which exclude the people who would benefit most from them, and the exclusion is rarely visible in the headline figures.
What was decided before the code was written
The Register with a GP surgery service was designed differently. Patients without ID were allowed to register. Patients without a fixed address were allowed to register, including travellers, people on canal boats, and people experiencing homelessness. The service worked alongside online translation tools and screen readers from the start, not as a later accessibility retrofit. A paper form running the same questions in parallel meant patients who preferred a non-digital route, or who had no realistic digital access, were not pushed out of the system.
These were governance decisions, not technical ones. They were made before requirements were drafted, and they constrained every downstream decision the team subsequently made. They are also the reason the resulting figures look the way they do.
Two-thirds of users came to the service to switch GPs, which is the population most public-sector services already capture. The remaining third is the part worth attending to. Twenty-three per cent were migrants and visitors, including international students. Ten per cent accessed the service in a language other than English. Nearly half of all registrations happened outside regular GP working hours, which tells you something about the relationship between digital availability and the working lives of the people most likely to need the service.
The numbers reflect the design choice. The design choice reflects the governance call.
Why this is a board issue, not a CSR issue
Inclusion is often discussed at board level under the heading of corporate social responsibility, where it sits alongside diversity reporting and community engagement. The framing is wrong, and it produces the wrong decisions.
Inclusion-by-design is not an ethical accessory bolted onto a service which would otherwise be optimised for the modal user. It is a governance posture about which assumptions the organisation is willing to ship, and which it is not. The cost of getting it wrong is rarely a single dramatic failure. It shows up as services with strong headline figures and weak penetration into the populations they were ostensibly built to serve. The board sees adoption metrics and concludes the service is working. The people who are not in those metrics remain invisible.
For a regulated service in healthcare, social housing, financial services, or public infrastructure, the populations most exposed to exclusion are also the populations most likely to be the subject of statutory scrutiny later. A service which works for everyone except the homeless, or everyone except non-English-speaking residents, or everyone except people without smartphones, is a service which will eventually attract a regulatory or ombudsman finding. The early choice is the cheap one. Discovering it after launch is expensive.
The harder question for boards is not whether their organisation believes in inclusion. The question is whether the design assumptions in their current digital roadmap have been examined, named, and signed off by anyone with the authority to challenge them. In most organisations the answer is no. The assumptions are inherited from whoever drafted the requirements, and they are absorbed into the build before the board has any visibility of them.
The diagnostic question worth asking
For boards reviewing a digital service in flight, the useful question is not how the service is performing. The useful question is who the service is currently designed to fail.
A well-run team will be able to answer the question quickly and specifically. They will know which populations are out of scope, why, and what the cost of bringing them in would be. They will have made the trade-off explicit and recorded it.
A team which cannot answer the question has not made the trade-off explicit. It has made it by default, and the default is almost always to design around the well-formed user. The board is then, without knowing it, sponsoring a service which will scale into the populations it was already going to reach, and stall against the populations it was supposed to help.
The Register with a GP surgery service worked because the well-formed user assumption was named and rejected before the build started. The reason it is worth holding up as a case study is not the growth figures. It is the order of operations. Inclusion was a design constraint, not a feature request. Boards which want services which work in the regulated, scrutinised, edge-of-population environments their organisations now operate in should insist on the same order.