Under the hood of government design
If we want more consistent, accessible and trusted public services, we need to look beyond interfaces and fix the conditions underneath…
Part 1
Under the hood of government design
If we want more consistent, accessible and trusted public services, we need to look beyond interfaces and fix the conditions underneath delivery.

Since joining the Civil Service in 2011, I have worked across digital, design, standards, assurance and service delivery. My background as a developer with a leaning towards UI and UX design started back in 2000 when I studied interaction multimedia design at university. With 8 years in the private sector as a developer, working on the design and build of one of the UK’s largest mortgage platforms, I very quickly developed an appetite for improving products and services that were broken, or didn’t quite work as users needed them to.
Fast forward to 2026 and I’m still fighting the same battles as I was back in 2006.
Much of my work has focused on helping teams do the right thing for users, often at pace, while navigating the realities of getting value for money for private and public service delivery: everything from policy constraints, governance, legacy technology, organisational boundaries and often the need to make decisions with imperfect information.
This has shaped how I think about design.
For me, design has never really just been about interfaces, screens or journeys. This is what many designers think design is, and treat it as such. Getting fixated on how things look or being pixel perfect, when in most cases, this is completely wrong.
Instead, it is about how decisions get made. It is about how standards are understood and applied. It is about how teams learn from what has already been built. It is about whether organisations create the conditions for consistent, accessible and trusted services.
I have always been driven by standards. Not standards as paperwork. Not standards as a way to slow teams down. Standards as a way to make good decisions easier to make, and be accepted without having to get bogged down in justification. Standards as a way to protect users. Standards as a way to help teams move quickly without repeating the same mistakes.
That approach has often helped bring people with me. It gives teams something to organise around. It gives people confidence that they are doing the right thing. It can turn uncertainty into something practical.
But it can also create conflict.
Standards, design and agile delivery all involve ambiguity. They ask teams to make decisions with imperfect information. They ask organisations to learn as they go. They ask people to be comfortable changing direction when evidence shows that something is not working.
Not everyone is comfortable with that.
In government, we often say we work in agile ways. But real agility is not just about ceremonies, stand-ups, planner boards, backlogs or delivery phases. It is about how an organisation responds to learning. It is about whether teams are trusted to test, iterate and improve. It is about whether governance helps teams make better decisions, or simply asks them to prove decisions that have already been made.
I want to explore several themes across a series of posts that for me, have been a very long time coming, and this is one of the tensions I want to explore in this series.
Public services have changed a lot since I joined the civil service. GOV.UK, the Service Manual, the Service Standard and the GOV.UK Design System have created a stronger foundation for digital government. They have helped teams design services that are clearer, more consistent and more user-centred.
But there is still a lot to do.
We have made progress on consistent interfaces but we are still much less consistent in how services behave.
Changing your name, changing your address, applying for a licence, renewing something, proving eligibility, uploading evidence, checking progress or challenging a decision can still feel very different depending on which part of government or the wider public sector you are dealing with.
Some of that difference is necessary. Public services are shaped by different laws, risks, users and operational contexts.
But some of it exists because organisations solve the same problems separately. Teams are pushed to deliver quickly, but are not always given the shared patterns, standards, platforms, governance or evidence they need to reuse what already works. Legacy services become the starting point for new services. Poor patterns are copied. Workarounds become permanent. Technical debt, design debt and service debt build up.
That is not usually the fault of one team. It is often the result of the environment created in organisaions delivering services.
If we want more consistent public services, we need to look under the hood. We need to understand the conditions that create consistency, and the conditions that prevent it.
That means talking about governance, assurance and compliance as part of design and delivery, not as things that sit outside it. It means looking at how standards are applied, how assurance is done either formally, or informally, how risk is managed, how accessibility is assured, how teams reuse previous work, and how organisations make decisions about pace, quality and accountability.
It also means being honest about the world we are designing for now.
People interact with public services in a context shaped by AI, misinformation, digital exclusion, declining trust, complex data sharing, economic pressure and increasing expectations. Digital inclusion is no longer only about whether someone can get online. Accessibility is not only about meeting a technical standard. Trust is not created by a logo or a design pattern.
Trust is built through the way a service behaves, for example:
- can people understand what is happening?
- can they use the service in a way that works for them?
- can they see how their information is being used?
- can they correct a mistake?
- can they get help when they need it?
- can they challenge a decision?
- can they trust that the organisation has designed the service with care?
These are design questions. They are also governance questions, assurance questions, standards questions and delivery questions.
This series is my attempt to get under the hood of those questions.
I want to write about the parts of design that are often less visible but have a huge effect on user experience: standards, assurance, compliance, service patterns, accessibility, inclusion, reuse, organisational memory, data, AI and trust.
On the point of accessibility and inclusion, both of these are particularly important to me.
Part of that comes from professional experience and understanding, but part of it also comes from lived experience. I am colourblind, neurodivergent and affected by ADHD, anxiety and periods of depression. I am slightly dyslexic, I hate reading, but like writing. I have trouble articulating thoughts in words at times, but think visually.
That does not make me representative of everyone’s experience, but it does mean I know what it feels like when systems create unnecessary friction, or someone presents something which I can’t make sense of because they’ve used green as a status indicator alongside a swathe of other colours.
I know how quickly a service can become harder to use when the language is unclear, the steps are inconsistent, the page is visually noisy, the code you’ve been asked to enter into a 2FA page is hard to remember — even if it’s just 5 numbers, or the consequences of making a mistake are not clear. I know that confidence, attention, memory, comprehension, time, trust and emotional load all affect whether someone can use a service successfully, or, at all.
That is why I think accessibility and inclusion need to be treated as core measures of service quality, not as minimum compliance tasks.
Meeting a technical accessibility standard matters. But it is not enough on its own. Public services also need to consider the wider barriers people face: disability, neurodivergence, literacy, language, income, access to devices, access to support, confidence, trauma, safety, time, trust and the complexity of the situation they are in.
This is where I think digital inclusion needs to evolve.
It is no longer enough to ask whether someone is online, or whether they have basic digital skills. People interact with services across websites, apps, letters, phone calls, face-to-face support, digital identity, data sharing, automated decisions, AI-generated information and increasingly complex evidence requirements.
We need better ways to understand digital literacy, confidence, capability, risk and impact across the whole service journey. Not just whether someone can complete a digital transaction, but whether they can understand it, trust it, challenge it, recover from mistakes and get support when digital is not the right route.
For me, this is a core design issue. It is also a standards issue, an assurance issue and a governance issue.
I do not think the answer is more bureaucracy, or red tape, it’s creating better conditions for delivery with people who really understand it, not just give lip service to the aforementioned standards and compliance.
Good governance should help teams understand what matters. Good assurance should give confidence earlier. Good standards should make the right thing easier to do. Good design should help organisations learn from what already exists, reduce avoidable inconsistency and create services that people can use, understand and trust.
That is the space I want to explore and I am not starting from a blank page.
A lot of my thinking, and indeed my career has been shaped by people who have pushed government and service design to look beyond screens and transactions.
From taking part in service design training in GDS by Lou Downe in 2017 through to their book on good services and designing for the gaps between them; Marc Stickdorn’s work on service design methods and systems; Kate Tarling’s writing on service organisations; and the work of people like Ben Terrett, Tom Loosemore, Andrew Greenway and Mike Bracken, who helped show what digital government could become when design, technology, delivery and leadership come together.
This series I hope to write in that spirit. Not as a finished answer, I’m just one (opinionated) person with an view that this can be better, but as a contribution to a continuing conversation about how public services can be better designed, better governed and better delivered.
Some of the themes I’m thinking about writing on in this series are:
- Why accessibility, inclusion and universal barriers need to be treated as core measures of service quality and do we need a new scale to measure against?
- How digital inclusion, AI, misinformation and data sharing are changing what people need from, and interact with public services
- What it means to be able to lead design at organisational scale, not just within individual services, and the conditions needed to enable success
- How standards, governance, assurance and compliance can create better conditions for delivery
- Why consistency needs to apply to service behaviours, not just interfaces and components
- How delivery pressure creates technical debt, design debt and service debt when organisations do not invest in reuse
I’d love to hear your thoughts on these themes and also your experiences, lived as a user, or if you’ve delivered good services, or services you know haven’t been right, or caused problems.
I promise not to name and shame — we’ve all been there.
Links and references
Some of the links and references to articles, books, and content in this initial post.
Government design, standards and delivery
- GOV.UK Service Manual
- GOV.UK Service Standard
- GOV.UK Design System
- GOV.UK Design System patterns
- GOV.UK Design System components
- Developing service patterns: reusable designs for building government services
Governance, assurance and digital government
- A roadmap for modern digital government
- A blueprint for modern digital government
- Digital Assurance Playbook
- Technology Code of Practice
- Digital, Data and Technology Playbook
Accessibility, inclusion and digital capability
- Accessibility requirements for public sector websites and apps
- Making your service more inclusive
- Designing assisted digital support
- Government Digital Inclusion Strategy
- Digital Inclusion Action Plan: First Steps
- Digital Inclusion Action Plan: One Year On
Service design and digital government thinking
메타데이터
- post_id
- f5571cdd1bba
- slug
- under-the-hood-of-government-design-f5571cdd1bba
- url
- https://medium.com/@andyjones_1981/under-the-hood-of-government-design-f5571cdd1bba
- canonical_url
- https://medium.com/@andyjones_1981/under-the-hood-of-government-design-f5571cdd1bba
- author_url
- https://medium.com/@andyjones_1981
- status
- ok
- fetched_at
- 2026-07-26 00:26:36