The Question That Stopped Us
A few weeks ago, in one of our design systems working group sessions, a colleague asked a question that brought our entire approach into focus. We had been discussing UI patterns, component hierarchies, and how to map service patterns onto the platform's interface builder. We were getting quite engaged with transaction patterns and reusable templates and the wider hierarchy of complexity that we were starting to map and sense-make around together.
Then she said something like: "I think we're still missing something. We don't have our fundamental principles yet. Before we can talk about patterns, we need to agree on what good design actually means for this platform".
We had been rushing towards solutions - patterns, templates, components - without establishing the foundational layer from which everything else should derive, and without codifying the principles that would shape our shared design practice.
The Problem We're Trying to Solve
We are working on a major NHS data platform that uses a vendor's proprietary application builder rather than the open-source NHS Service Manual design system. This creates a fundamental challenge: we are trying to design good user experiences within a platform whose design system we do not control.
The vendor's drag-and-drop interface builder is powerful; it enables rapid application development without traditional frontend engineering. But it comes with significant constraints: fixed component behaviours, limited customisation, and architectural decisions that do not always align with NHS accessibility requirements or interaction patterns, alongside an aesthetic that does not align at all with the NHS Service Manual or brand identity.
Multiple product teams work independently on different applications, each making their own design decisions. Without shared principles, we get inconsistency by accident - not because anyone is doing anything wrong, but because there is no common vocabulary for what "right" looks like, and the shared NHS Service Manual framework cannot be applied to this platform anyway. The question we asked ourselves was whether design principles could help: could a shared set of guidelines create coherence across teams and products, even when we do not control the underlying platform?
What Design Principles Are Good For
Jakob Nielsen's work on heuristic evaluation provides a useful starting point. Heuristic evaluation is described as "a 'discount usability engineering' method for evaluating user interfaces to find their usability problems" (Nielsen, 2003). The key insight is that heuristics - rules of thumb based on usability principles - give evaluators a systematic framework for identifying issues.
There is an important limitation, though. Boyarski and Butter (1997) observe that "most of the work done on heuristics is in the area of evaluation, not design itself. Although there are many methods to evaluate human interface designs, there are no equivalent sets of heuristics to help generate solutions". This distinction matters: heuristics and principles are excellent for critique - for looking at something that exists and identifying what is wrong with it - but much less useful for generation, for creating new solutions from scratch. Baxter and Courage (2015) define a heuristic simply as "a rule or guide based on the principles of usability", positioning principles as the foundational layer from which more specific rules derive.
Where Principles Sit in a Design System
One way to understand where principles sit is through Brad Frost's Atomic Design framework. Frost (2016) describes design systems as comprising atoms (basic elements like buttons and labels), molecules (groups of atoms working together), organisms (complex UI sections), templates (page-level structures), and pages (specific instances with real content). He argues that design systems "lead to cohesive, consistent experiences. That means users master your UI faster, leading to more conversions and more money based on the positive experience" (Frost, 2016).
Principles are arguably above this hierarchy - the meta-layer that governs decisions at every other level. A principle like "progressive disclosure" influences how you design atoms (what is visible by default), molecules (how information is grouped), and templates (what appears above the fold). This is why our colleague's intervention mattered: we were discussing patterns and components without having established the principles that should govern them.
Principles for Constrained Environments
Our situation is somewhat unusual in the design systems literature. Most discussions of design systems assume that you are building one - that you have control over the components, the patterns, the entire stack. Frost's work, for instance, is primarily about creating design systems, not working within someone else's.
The academic literature on sociotechnical systems offers some insight into what happens when you are designing within constraints you did not choose and cannot change. As one analysis notes, "secondary design at the functional layer allows flexibility in the action and reflection of people, [but] the flexibility often has boundaries" (Germonprez and Hovorka, 2018). We have agency, but bounded agency; we can influence some things, accept others, and must be honest about which is which.
This suggests that principles in a constrained environment might need to do different work than principles in an unconstrained one. Rather than purely aspirational statements about what good design looks like, they might need to be honest about constraints, acknowledging what we can and cannot control; differentiated by agency, distinguishing between areas where we have full control, partial influence, or no ability to change things; and useful for evaluation, providing vocabulary for critique even when they cannot guide generation.
The NHS Context
Working in the NHS adds another layer of complexity. Public sector design operates differently from commercial product design, and The Design Council (2013) maps a ladder of design maturity ranging from using design for discrete problems through to design as a strategic capability.
The NHS Service Manual represents years of work codifying what good NHS digital design looks like; it is based on extensive user research, accessibility testing, and iteration. When we use a vendor's platform instead, we step outside that carefully considered framework. This is not necessarily wrong - there are good reasons for using the vendor's platform, primarily around data infrastructure and rapid deployment - but it means we need to be intentional about which NHS design patterns we try to preserve and which we accept we will lose. As Grinyer (2025) notes, quoting Ben Terrett who was Director of Design at the UK Government Digital Service, "change is hard, very hard". This is true of both changing the platform we are working on and changing our own expectations about what is achievable.
What We Decided to Do
After our colleague's intervention, we agreed to step back and establish design principles before continuing with patterns. We started with established heuristics - Nielsen's ten usability heuristics, the GDS design principles, and NHS-specific guidance - and adapted them for our context, asking which principles make sense for clinical data applications and which require modification. We categorised principles by whether we fully control, partially influence, or merely aspire to them, and framed them as evaluation vocabulary rather than design rules. That last point is crucial given Boyarski and Butter's insight that heuristics are better for evaluation than generation: the principles are tools for having productive conversations about design quality, not recipes for creating designs.
The Limitations of Principles
Principles are a weak intervention. They describe what good looks like, but they do not make good design happen. A team can read a principle, agree with it, and still produce work that violates it - not through malice, but through time pressure, platform constraints, or simply not having the principle in mind at the moment of decision.
Stronger interventions would include shared component libraries, where good design is the path of least resistance because the components themselves embody the principles; platform changes, where constraints that prevent good design are removed at source; and design authority, where governance enforces consistency. We do not have any of these. The vendor controls the component library, platform changes require vendor cooperation, and we have no formal design authority across product teams. What authority we have is informal and limited to the specific teams we are working with.
So we are left with principles as one of the few levers we can actually pull. Whether they can do useful work, given their limitations, is the question I explore in the next post in this series.
References
Baxter, K. and Courage, C. (2015). Understanding Your Users: A Practical Guide to User Requirements. Morgan Kaufmann.
Boyarski, D. and Butter, R. (1997). Design in the Age of Information. Carnegie Mellon University.
Frost, B. (2016). Atomic Design. Brad Frost.
Germonprez, M. and Hovorka, D. (2018). Secondary Design: A Case of Behavioral Design Science Research. Journal of the Association for Information Systems.
Grinyer, C. (2025). Redesigning Thinking. Routledge.
Nielsen, J. (2003). Enhancing The Explanatory Power Of Usability Heuristics. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems.
The Design Council. (2013). Design for Public Good.