I renewed my mother's Blue Badge recently. The form took half an hour, demanded information she does not hold, and asked the same question in three different wordings. I have led the delivery of a national NHS digital service. I struggled. She would not have finished it.
The failure was not technical. The form works. Pages load. Validation fires. Data gets to the back office. The failure is the exclusion of the user it exists to serve, and no one in the delivery chain treated the exclusion as a defect.
The brief was simple. The scope was not.
A public-sector digital service starts with a clear brief. Move a paper process online. Cut administrative cost. Improve throughput. The minimum viable version is short, focused, and built around the user with the highest barrier to completion.
Then the scope expands. Policy wants an extra question. Operations wants a confirmation step. Legal wants a declaration. Finance wants a verification. Audit wants a paper trail. Each addition is defensible on its own terms. None of them is owned by the person who decides whether the service still works for the user.
A five-minute form becomes a half-hour interrogation. The minimum viable service was scoped out somewhere between sprint two and go-live, and nobody recorded the moment it happened.
The user is missing from the room
The Blue Badge applicant is, by definition, someone with significant mobility or cognitive impairment. Many are elderly. Many are completing the form through a carer who does not hold their medical history, their consultant's name, or their NHS number to hand. A meaningful share have limited digital confidence.
The form assumes none of this. It assumes the user has the records, the time, the patience, and the cognitive bandwidth to navigate ambiguous questions. The user fitting this profile is the user the form does not need to exist for.
This is not a design oversight. It is a structural one. The teams adding scope are answering to internal stakeholders. The user is represented by a persona document, if at all. The persona does not push back when the form gets longer. The user, by the time the form is live, has no route to push back either. They abandon, or they ask their council for a paper form, or they give up the entitlement.
UK GDPR Article 5(1)(c) requires data minimisation. The principle: organisations collect only what is necessary for the stated purpose. In practice, necessity is defined by the organisation, not the user. The legal hook exists. The governance to enforce it inside delivery does not.
Boards underwrite this without knowing they have
A board signing off a digital transformation programme sees the business case, the cost saving, the throughput uplift, and a green RAG status at each gateway. The board does not see the form. It does not see the abandonment rate broken down by user vulnerability. It does not see the share of applicants who reverted to paper, called the helpline, or stopped applying entirely.
These are the metrics telling you whether the service works. They are also the metrics least often surfaced to the executive layer, because they expose a delivery failure the rest of the dashboard is designed to hide.
A senior executive given the brief to digitise a process is rewarded for shipping. They are rewarded for cost reduction. They are not, in most public-sector delivery structures, rewarded for the harder discipline of refusing scope additions which degrade the service for the users who need it most.
The board signs the business case. The board does not see the form. The scope expansion happens in the gap.
The fix is governance, not design
A user research function, a service design team, and a head of digital inclusion are all useful. None of them is sufficient. The decision to add a field to a form is taken by people senior to all three.
What works is a governance discipline at the level above delivery. Three questions, asked at every scope decision, with named accountability:
Does this addition serve the user, or does it serve the organisation? If the latter, what is the user cost, and who has signed it off?
Who is the user least able to complete this service, and has the addition been tested against them?
If the addition is non-negotiable, what compensating change protects the user with the highest barrier?
These questions are uncomfortable. They slow delivery. They surface trade-offs the dashboard does not. They also produce services which work for the people they exist for.
A digital identity layer would help. Pre-filling known information, reducing duplication, integrating across services: all of this reduces the load on the user. None of it fixes the underlying problem. The underlying problem is the addition of scope without anyone in the chain being accountable for what the additions cost the user. The identity layer is a technical patch on a governance gap.
The form my mother needed to complete was not built for her. It was built for everyone in the delivery chain except her. Until boards treat the exclusion as the defect it is, the next form will fail in the same way.