This is the second of two notes on the particular way of knowing things that design represents. The first part is here.
When you are working at the scale of an object or an interface, design methods feel clear. Constraints, requirements, 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.