Inheriting the Guide
When I joined the team, I inherited a design guide. Previous designers had recognised the same problem I described in Why Design Principles?: products built in the vendor's application builder do not follow NHS design patterns. They had tried to address this by creating documentation - a guide for platform developers explaining NHS typography, colours, spacing, and accessibility requirements.
The guide exists, hosted on GitHub Pages. It covers the basics: NHS Blue (#005EB8), type sizes, button styles, date formats, data visualisation colours. It links to NHS accessibility checklists. It tries to bridge the gap between the platform's defaults and NHS brand requirements. It is a reasonable piece of work, and as far as I can tell, no one uses it.
The Guide That Does Not Follow the Guide
The resource explaining how to follow NHS design standards does not itself follow NHS design standards. It is built with MkDocs (a Python documentation generator), not the NHS Service Manual's design patterns. The typography is not quite right, the spacing is not NHS spacing, and the navigation does not follow NHS patterns. I do not know who built it for the team, or under what constraints; perhaps there were good reasons, perhaps it was pragmatic - get something out quickly, improve it later. But it captures something about the structural position of design on this programme: even attempts to document good practice run into the same constraints that prevent good practice in the first place.
What the Guide Contains
The guide has genuine strengths: clear colour specifications with hex codes, practical guidance on type sizes (noting that the platform's "small" text is unreadable for many users), accessibility reminders linking to NHS checklists, sensible content design guidance covering plain language, sentence case, and UK date formats, a data visualisation colour palette tested for accessibility, and guidance on semantic page structure for screen readers.
The gaps are more revealing. There are no component specifications describing what a button should actually look like, no interaction patterns explaining how validation should work, no layout guidance beyond basic principles, no templates or examples, and limited guidance on platform-specific constraints. A "Templates and Widgets" section promises that "in future versions of this guide, there will be guidance here" - but no future versions came.
The structural problem sits beneath both strengths and gaps: it is documentation that developers have to choose to read, it is not integrated into any workflow, there is no enforcement mechanism, and it competes with the vendor's own documentation.
Design Guides vs Design Principles
The working group discussion that prompted Why Design Principles? was about whether we needed principles before patterns. But the existing guide is not really principles - it is specifications. Colours, sizes, formats. It tells you what to do, not why.
This distinction matters for how we understand them as interventions. Design guides like the existing one are prescriptive ("Use NHS Blue #005EB8"), specific (exact values, exact formats), reference material (look something up when you need it), and implementation-focused (how to build things). Design principles, by contrast, are evaluative ("visual hierarchy signals importance"), abstract (applicable across many specific decisions), internalised knowledge (shaping thinking rather than just reference), and critique-focused (how to assess whether things are good). The guide can tell a developer that NHS Blue is #005EB8; it cannot tell them whether their use of colour is helping users understand the interface. That requires principles.
Intervention Strength
Interventions vary in strength based on how much they constrain behaviour. Meadows (2008) identifies twelve leverage points for intervening in a system, and while her framework addresses systems at a much larger scale, the underlying logic applies: the more an intervention shapes the default path of action, the stronger it is.
At the weakest end, principles are abstract statements about what good looks like; they require internalisation to have any effect and can be ignored entirely. Design guides are somewhat stronger because they give specific instructions, but they still require someone to read them, remember them, and choose to follow them. Templates and examples are stronger again: concrete starting points that embody good practice, easier to use than to ignore, though they can still be modified or abandoned. Component libraries are stronger still, because the design is in the component and using it means accepting the design. At the strongest end sit platform constraints - what the platform allows or prevents - which cannot be ignored because the platform enforces them.
The existing guide sits at the second level: stronger than abstract principles because it gives specific instructions, but weaker than templates (which it promises but does not deliver) and far weaker than a component library (which we do not have). And it competes with the strongest level - the platform's own constraints. When the platform's defaults conflict with the guide's recommendations, the platform wins by default because the developer has to actively override it to follow the guide. That is friction in the wrong direction.
Parallel Work
The NHS England Data Viz Community of Practice has published comprehensive dashboard design guidance covering not just specifications but principles explaining why certain approaches work, along with navigation patterns, layout guidance including grids, spacing, and visual hierarchy, component-level detail for cards, filters, KPIs, and tooltips, chart type selection with examples, table design patterns, and downloadable templates as starting points. It is aimed at Tableau and Power BI development, but the principles are platform-agnostic and much of it applies directly to application builder development.
The existing design guide does not reference it. Two NHS England teams, working on adjacent problems, produced overlapping documentation with no apparent coordination. This is the fragmentation problem in miniature: every team documents their own solutions, knowledge does not flow between teams, wheels get reinvented, and the documentation that exists does not get maintained because the people who created it move on to other work.
Why Guides Fail
The existing guide's apparent lack of uptake is not unusual; it reflects structural problems that affect documentation-based interventions generally. There is a discovery problem: developers do not know the guide exists because it is not linked from anywhere they look and does not appear in their workflow. There is an authority problem: the guide is not official, not mandated, and has no governance behind it, so ignoring it carries no consequences. There is a maintenance problem: the guide was created at a point in time, the platform has evolved, the guide has not, and sections that promise future content erode trust when that content never arrives. There is a competing authorities problem: the vendor has its own documentation, defaults, and design language, and when NHS guidance conflicts with vendor guidance, whichever is easier to follow usually wins - and the vendor's is integrated into the platform. And there is an abstraction problem: the guide tells you what colour to use but not how to think about colour, so when a novel situation arises - which is most situations - the guide does not help.
What Would Work Better
Starting with principles rather than specifications would help people understand why NHS design works the way it does, so that specifications become applications of principles rather than arbitrary rules. Integrating guidance into workflow would address the discovery problem, since documentation that lives outside the development environment does not get used. Providing templates rather than just guidance would follow the approach the Data Viz Community of Practice got right: downloadable starting points that embody the guidance, so teams start from something good rather than building from scratch. Acknowledging constraints honestly would be more useful than aspirational documentation, since the existing guide presents NHS standards as if they are achievable when often they are not.
The strongest intervention would be building components rather than documents. If we had an NHS-styled component library that worked with the platform, developers would not need to read a guide at all; the design would be in the components. But we do not have that, and building one requires resources and authority we do not currently possess.
Where This Leaves Us
The existing design guide represents well-intentioned work by designers who came before me. They saw the problem - products do not follow NHS standards - and tried to address it with documentation. It did not work, as far as I can tell, not because the documentation was bad but because documentation is a weak intervention in a system that would need stronger interventions to change.
This is why the working group's turn toward principles feels different. We are not trying to replace the guide with better specifications; we are trying to establish a layer beneath specifications - a shared vocabulary for evaluating design quality that could support multiple kinds of intervention. Principles will not work on their own either; they are even weaker than guides. But they might be necessary groundwork for whatever comes next. The guide tells you NHS Blue is #005EB8. Principles tell you why colour consistency matters - which becomes relevant when you are advocating for platform changes, building component libraries, or making the case for design authority.
References
Meadows, D. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.