Mike Gallagher

When you are working at the scale of an object or an interface, design methods feel clear. Constraints, requirement, tools, and materials are easy enough to understand and work with because they can all be laid out in front of you. For the most part, you can manipulate them directly. Feedback can be produced quickly. When you’re working at the scale of a whole system, however, what Nigel Cross calls a “designerly way of knowing” becomes difficult to explain and conjecture – the forming of a plausible guess and then testing it by making something – involves more risk. At that scale, the effects of what you produce are diffuse and change happens slowly. You can prototype a new national API standard, but testing its efficacy takes years, by which point there is massive vendor lock-in and you can’t make any more changes for a good long while. It is difficult to loosely hold a strong opinion if the consequences will be measured in billions of pounds. At this scale, baking adaptation into your approach can be hard to justify.

---

Horst Rittel – one of the theorists Cross draws on when formulating his concept of a designerly way of knowing – made a distinction between “tame” and “wicked” problems. Tame problems are definable: they have a knowable, correct solution and the work is to find it. Wicked problems are something else, different in both degree and kind. They are ill-defined and have no single correct solution. Crucially, the act of working on them changes the problem: the problem tends to shift as you develop a greater understanding of its nature and dimensions. You cannot fully specify a wicked problem before you start because the work is part of the specification. Deciding everything up front doesn’t produce a correct answer; it produces a premature one. This is why design is useful: only through action can you develop a deeper and more accurate understanding of both the problem and how to address it.

This is an issue for government, which has structural incentives that lead to up-front decision-making being baked in to core processes. Policy, procurement frameworks, and business cases are all instruments for making decisions before “delivery” is carried out. These are reasonable tools for tame problems – just like waterfall development is – but most things government struggles with are wicked problems. The health system, social care, housing, poverty: none of these have single “correct” solutions waiting to be found.

Cross’ central claim is that design produces knowledge through engagement with materials – that the resistance you encounter when making something generates understanding that no amount of prior analysis could have produced. At product scale, that material is pixels, code, interaction patterns, and order fulfilment. At systems scale, it is institutional bureaucracy, policy, the market, and the grind of organisational change. A designerly way of knowing does not present a faster or cheaper alternative to analytical, up-front decision-making, but I would assert that it is the right method for this class of problem because it is the only form of reasoning that treats the problem as something that needs to be continually reshaped rather than something that can be definitively solved. It isn’t a calculus equation, it is a dance. That isn’t a comfortable idea in an environment shaped by policy directives, but it is a more accurate description of the territory. The work is never truly done.

---

Aspects of this are well known in some circles. GDS’s statement of intent from the early teens – “the strategy is delivery” – sounds at first like commitment to speed. It is not. It is much more methodologically interesting than that: if you are working in a complex or chaotic environment, you cannot know in advance what the right answer is, so the only way to find out is to start making stuff (i.e. delivering) and to observe what happens. The slogan is short because slogans have to be. What it does not say, and what really matters, is that “the strategy is delivery and then changing things based on what delivery has revealed”. Iteration is not a result of a failure to plan, it is the plan.

This isn’t just history. The Magenta Book – HM Treasury’s official guidance on evaluation – now includes a “test and learn” annex that explicitly names feedback loops, prototyping, and systems mapping as core methods. It frames iterative working as a compliment to traditional policy design. The direction is right. The question is whether the framing goes far enough. Test and learn, as described, is largely about evaluation and evidence – cyclical, structured, outcome-oriented – which is subtly different from a conjectural method that treats the act of making as itself a form of knowing. I may be splitting hairs (this annex is a big deal).

The mechanism that makes iteration work has a name. When I worked at Hugh Dubberly’s design studio back in 2010, I don’t think a single day went by when someone didn’t draw a diagram of a feedback loop on a whiteboard. There was a seemingly infinite variety of illustrations on printouts pretty much everywhere you looked. What Hugh was drawing, compulsively and in many forms, was the basic structure of a goal-directed system: you have a goal, you act toward it, the environment responds, you measure the effect, you compare it to what was intended, you detect error or divergence, and you correct things. Then you do it again. This cycle is the formal description of what agile development tried to institutionalise, what GDS was pointing at with its slogan, and what a conjectural method depends on. You cannot learn from a conjecture without some form of feedback. The delivery is what generates it.

At the scale of a single product, this cycle can be tight – a day, a sprint, maybe a quarter. At systems scale, the loop is much longer and harder to close. Effects are diffuse, causes are multiple, and it can be hard to extract signal from noise. This isn’t a reason to abandon the approach and retreat back into big upfront specification, rather it is a reason to be deliberate about designing the feedback mechanisms.

The Service Standard formalises a version of this approach for products and services: start with user needs, work in the open, iterate based on evidence, and focus on solving a whole problem. It is a demonstration of government having accepted that you cannot decide everything up front and the work will necessitate some degree of learning and change. This is really significant, but the Service Standard was developed for services that have legible boundaries – things with a beginning, middle, and end; things with identifiable user needs that can be tested against. What it does not address is what happens (and what to do) when the boundaries of the service dissolves into policy, into decisions made by other organisations, into infrastructure that you have no control over, or into problems that no single team could ever hope to own by themselves. The Service Standard is clear on how to act when you can describe the problem at hand. It is less clear about what to do when the first task is working out what you’re even dealing with. This isn’t only a gap in the standard, it is built into how the profession is defined.

This is part of why service designers are always having an existential crisis. Running communities of practice is instructive. Interaction design huddles are fun: you have tangible stuff to review and discuss. Service design huddles, by contrast, are always a nightmare. It is difficult to critique the conversations someone has had over the span of months, or to give advice for becoming friends with policy colleagues. The sessions tend to split between reviewing maps and struggling to say anything useful, or something like group therapy.

---

At systems scale, the work looks different from what happens on a product team, but the logic is the same. A service map is not a prototype in the way that a design system and prototype kit produce a direct representation of software to be built. It is more like a tool for developing an understanding of what needs to change – provisional, conjectural, made with the expectation that drawing it will reveal gaps in how you think the system fits together. A project kickoff is a means to shape a problem definition with a team, and that will happen through conversation and questioning. Walking stakeholders through a service journey is a means to build shared understanding. This work produces knowledge that could not have been produced by analysis alone.

There are versions of this work that produce artefacts without knowledge. When some stakeholder asks for a map to be produced, they are typically looking for certainty and reassurance – we know how things work, it will all be ok. The problem is that the final artefact is basically never where the real value is. The value is in the making of the map and in what can only be understood by doing so – disagreements that are surfaced, gaps that you hadn’t noticed before, relationships that have been neglected. A map produced without any friction is probably not a very useful map and most maps are likely out of date by the time they are done. That’s ok – the team should have a greater depth of understanding that it can use to do something new.

This is true for most design artefacts when you are working at this scale. The most useful service maps are not clean, sleek representations of everything working well, but rather are tools for thinking with. Really good maps are covered in red pins that indicate where the problems are. Once you know where the problems exist, you can work backwards toward an understanding of how to affect them. You can look for points of leverage. There will be many and most of them will be weak. Once you find these leverage points, you also need to intervene. You do that mostly by talking to people – questioning, negotiating, pleading, and repeating yourself until everyone is completely sick of hearing your voice. That is the delivery in this context and at this scale.

Service maps and workshops are instruments for making leverage points legible. It would be a mistake to treat the instrument as the real output, which is system change. In a post from last week, Simon Morgan-Wilson draws a sharper line between service design and interaction design than I would – he uses interaction/UX design as a foil in a way that I don’t think is entirely fair – but his test for a service design engagement is exactly right:

The honest test of a service design engagement is whether anything structural is different a year later.

Much of what makes a service hard to improve is not the software. That is usually the (relatively) easy part, and it is downstream of the service proper, which is itself downstream of the policy and broader system they all exist within.

---

It is not much of a stretch to see the parallel between this formulation of design and capital-P politics. Both are a means to shape the world toward something that does not yet exist, something that ought to be, as defined by your values and ideology. Both work on problems that resist clean specification. Both require you to hold a position while remaining open to revisiting it. It is thus a little surprising that this mindset and methodology is not more widely used in government. Except, maybe it isn’t surprising at all, because what design asks of a policy-driven environment is the thing that environment finds most difficult: to begin without fully deciding and to treat the act of doing as a form of knowing.

Follow that parallel far enough and it becomes hard to avoid the idea that service design methods are not supplementary to policy methods, they are or ought to be the same thing. I am not saying that designers should be put in charge of government, not quite. I am saying that where policy works by analysis and declaration, service design works by conjecture and revision, and that the latter is better suited to the class of problems government finds hardest. If policy colleagues want to take that work up and own it, great, I can go home.

Some already are. The Public Policy Design community is evidence of that, as is the Policy Lab. More broadly, policy colleagues who reframe a brief to make a problem workable are designing. Delivery teams that change course based on what they observe are designing. The question is not whether this happens – it does, constantly – but whether it happens in spite of the institution rather than because of it.

---

Government already knows how to be analytical. What it needs, and often struggles to make space for, is what Cross called a designerly way of knowing: the one that works by making things, that learns through resistance, and that treats unresolved problems as material to work with rather than gaps to be papered over. That is the territory wicked problems occupy. It is the territory designers have always worked in. Design is not just what something looks like, or even (to paraphrase Steve Jobs) how it works; it is a way of knowing what could be.

In grad school, we used to talk about “thinking through making”, by which we meant that design ideas couldn’t be fully developed before you started making something. The act of designing was itself a way to think, a way to create knowledge, which would be embodied by the thing you had made. Ideas were discussed as seeds of an investigation to come, but weren’t treated with any degree of preciousness. Different tutors had different relationships to pure concepts; one flat out refused to talk about unmade ideas and had a rule against “air crits”. And I get it – when you’re a student having grand ideas for the first time, they all seem important. The novice does not yet know that design concepts that exist solely as words are not yet fully thought.

I didn’t know it at the time, but industrial designer Nigel Cross had worked out a theory of all this as early as 1982, in a text titled “Designerly Ways of Knowing”. The article was the third in a series on design studies published by the Open University, aiming to “establish the theoretical bases for treating design as a coherent discipline of study.” Drawing on theorists like Herbert Simon and Horst Rittel, Cross posited that design is a third form of knowledge, separate from the sciences and the humanities, with its own epistemology. In Cross’s formulation, the sciences concern themselves with how things are, and the humanities concern themselves with how things are understood and expressed. Design, however, concerns itself with how things ought to be. Design works on problems that are, by their nature, ill-defined and without a single correct solution. Design outputs must always be concrete and closed – you have to make a decision and ship something, after all – and yet the process that produces them is stubbornly non-verbal. You cannot fully describe your way to a design. The reasoning resists language.

That last point matters more than it might seem. Design outputs cannot be separated from how they were made without losing something essential. (This is both why “design thinking” is absolute bullshit and why the current crop of AI design tools are a dead end.) I can’t solve most design problems by sitting in a chair and thinking really hard, or at least, I won’t be able to solve them well. Some elements of the design simply cannot be thought until their details have been worked through. There is something in the resistance and grain of materials – pixels, code, infrastructure – that generates an understanding you couldn’t have arrived at any other way.

---

The logic Cross is describing is abductive reasoning – neither deductive (if A then B) nor inductive (from enough observations, I conclude A), but conjectural. You form a plausible guess based on what you know and then you test it by making something. This is why we speak so much about testing our assumptions. This is where hypothesis-driven design comes from, even if the framing makes it seem all very scientific, which is to say, deductive. The insight comes from the collision between your conjecture, the thing you’ve made, and the world at large.

Unfortunately design is not a deterministic process. No amount of double diamond diagrams are going to change what is essentially a conjectural method and make it behave in a strict if/then fashion. Even with a robust design system and an extensive body of prior research, teams still end up in messy debates. Some of that is what happens when you operate with imperfect knowledge, but some of it is the process being worked through. In those discussions, the team thinks its way toward a better formed idea.

This is why the first thing pretty much every consultancy team does when starting a project is rewrite the brief. The problem needs to be made workable, more amenable to being solved. It is a form of discovery that draws out the client’s tacit knowledge and uses it to choose a trajectory. Think of it as subtly adjusting one’s aim. The rewriting of the brief is an act of design, often the first one. In the public sector, this can be difficult because often the brief is the policy, and the policy is typically not up for debate. The designer wants to shape the problem, but policy has already decided what the problem is.

Cross was writing primarily about industrial design and architecture – hard things with mass, stuff that can fall on you, objects with literal edges. The question of how a designerly way of knowing operates across software and perpetually mutable services is something he only begins to address. Agile development partly fills the gap. The real point of agile – and it is beyond obvious to restate this in 2026, but here we are – is iteration based on an observation of how things work in the real world. That is it. Everything else is a set of tricks designed to make that easier. The approach has nothing to do with “moving at pace”, “doing more with less”, or any other such middle-management nonsense. The sum total of what should be done cannot be known in advance, so you make small probes that help you learn, adapting the approach and product or service as you go.

---

From here, the question becomes how to apply this at the scale of a whole system, full of diffuse and abstract problems that take years to be worked through. I’ll come back to this next week.

My friend Mo is big on theory. Design theory, product management theory, organisational theory – you name it. He loves a framework that helps explain a working situation. He introduced me to Lean UX sometime around 2015, then to the theory of constraints, and onward to a handful of others I’ve half-forgotten. One concept he told me about – probably over a mixed grill somewhere on the Kingsland Road – was the garbage can model. The model describes a theory of decision-making in complex, unaligned organisations using the unglamorous image of a bin into which problems, solutions, and participants get thrown independently, mixing chaotically until a decision happens by collision rather than intention. I come back to it every so often, partly because the name is so good, and partly because it explains so much about where I work. It isn’t a perfect fit for the NHS, but it is instructive.

---

The Federated Data Platform (FDP) has been in the news a lot lately. Tito Castillo recently wrote an excellent article about it, and while there is a lot to say about supplier selection and national standards, the thing that really jumped out at me wasn’t the FDP story itself, but rather his use of the garbage can model as a framing device and what it reveals about the experience of being a designer in a large public institution. His description of the model:

In a loosely ordered system, the streams move independently. Problems exist without solutions. Solutions circulate looking for problems to attach to. People move in and out of decision-making arenas. And moments of decision arise on their own schedule, driven by budgets, deadlines, or political events.

A decision happens when these streams converge. A funding window opens at the same time that a vendor is promoting a platform, stakeholders are available to approve it, and a recognised problem can be linked to the proposal. The resulting decision is real, but its coherence is coincidental rather than planned. Everyone involved may have acted reasonably within their own context. The system as a whole produces an outcome that nobody quite intended.

If you are a designer, trained to define problems before solutions get explored, the situation described above looks like madness. In a garbage can system, solutions are already circulating before problems are properly defined, and the moments when decisions get made often happen too quickly or too indirectly for careful problem framing to intervene. You can do all the right things – research, analysis, a well crafted problem statement – and still watch a decision get made without fully accounting for accumulated evidence.

The drive to define a problem that teams can work toward solving becomes a never-ending, snake-eating-its-own-tail battle against all of the other streams that aren’t oriented that way. The very nature of the system makes this true. Without reorganising everything, it is hard to see how that changes. Castillo provides a description of how this plays out in practice in the health system (not just with the FDP):

National bodies set direction, but delivery depends on local adoption. Suppliers shape the architecture through product design choices that may not reflect national intent. People move in and out of specific decisions, contributing views that make sense locally but do not add up to a coherent whole.

It is hard not to see this as a form of organised anarchy – a contradiction in terms and another foundational element of the garbage can model. From wikipedia:

Organised anarchies can be characterised by a sense of chaos and dynamism. Problems and solutions are loosely coupled. Proposed solutions change during bargaining. All participants involved do not get the chance to fully participate, and have limitations on their time and energy. Many things happen at once, all competing with each other for attention. Amongst the confusion, participants try to make sense of their role in the organisation.

In a garbage can system, decisions get shaped by whomever happened to be present. Part of the job in this environment is being in the right rooms at the right moments. Not because you’re playing politics, but because if design methods and mindsets are present when the streams collide, the outcome will (hopefully) reflect that. If the lenses brought to bear on a particular problem reflect technology and suppliers and policy, but not users, you have a problem. So showing up and staying in the conversation is itself a design activity.

---

The NHS is changing. It is always changing. I’ve been here for three and a half years and this is my second org-wide merger. Lots of people are leaving, and with good reason. I wish them all well, and I’m sad many of them are going, but I didn’t take voluntary redundancy and I hope to stay on to try to see some of our work through. Part of that is straightforward: this is the most meaningful work I can put my time into. Part of why I want to stay is probably less flattering: when the streams align and something actually lands, the feeling is disproportionate to the outcome, and I suspect intermittent reinforcement is part of what keeps me pressing the lever, like a pigeon whose brain has been moulded through operant conditioning.

Within the App programme, I have influence over what we work on and how we do it. I contribute to shaping our priorities and the approach taken to the work. What’s harder are the service design problems that require the wider system to change in order to produce a better result for users. I can name them. I can make a case for them. But I can’t force the system to respond. No one team can. The processes and tools that need to change are beyond our reach. I am almost certainly not in the right rooms.

The native replatforming work is a good example of what work looks like when we can reach all of the levers. The team can research, design, and build things. The scope is bounded and the quality bar is ours to set. When moments of decision arrive, there’s something coherent already in place. A codebase. A design language. A team with a working practice. The streams have something to find and adhere to.

Keeping the right problems alive is hard. In the garbage can model, resolution – where a problem and a solution genuinely meet and get worked through – is the rarest way decisions get made. Most happen through oversight, where a decision is made so quickly that problems don’t get a chance to attach to it, or flight, where problems simply detach and drift away because the moment has passed. The main risk isn’t that a problem gets solved badly – it’s that it gets outpaced or abandoned. Plans don’t get completed because there’s a new plan to supplant them. To stay relevant you need to maintain and resurface and reattach the problem to the other streams. That is less glamorous than designing a new interface but it is arguably the more important skill in this kind of environment.

In practice, this work doesn’t look like much from the outside. You run research that no one asked for to investigate a hunch. You articulate a problem that isn’t part of one of the big plans to surface what you’ve learned. You document the work so that it outlasts you. You turn up to basically every meeting there is, even if it doesn’t obviously concern you, because the participant stream determines what mindsets direct the decision-making. None of that is control. Done consistently though, it builds influence to keep the problems you care about alive and in the conversation for a little bit longer.

While the garbage can model mostly fits, the work might be better described by a different image. A garbage can implies waste, destruction, an ending, a lack of care. The work of keeping problems alive by working within a complex ecosystem lends itself to gardening as the obvious replacement, but perhaps that is too genteel. Better still might be the image of a compost heap: it is messy and a little terrifying, it confounds easy analysis, it has a certain life of its own and over time, if you keep turning it and adding to it, it becomes generative. When the conditions and season are right, there’s something there to meet the moment.

Patience and persistence, yes. But not just waiting. Tending.