The MacGuffin Pattern
For service designers who want to change the constraints they work within.
Written For
Service designers across public and private sectors. They understand user research, service mapping, agile delivery—but are frustrated by their inability to influence policy, procurement, or organisational design.
Most service design work I see stays trapped in incremental delivery. You can deliver the perfect service, nail every user need, hit every KPI, and still leave the underlying system exactly as broken as when you started.
The diagnostic question I landed on was which constraint we were accepting and which one we were actually targeting.
If you can’t name a constraint you’re trying to make untenable, you’re doing delivery design, not strategic design.
The follow-up is harder. How do you design implementation choices that make a constraint untenable?
Dan Hill’s answer, in Dark Matter and Trojan Horses, is the Macguffin: a project that looks inconsequential but has a ripple effect extending much further than the thing being built.
The Pattern in Everyday Life
Hill talks about zooming in and zooming out. Zoom in on an electric vehicle and you see the curve of a wheel arch. Zoom out and you see charging points, parking policy, and the grid.
The Electric Vehicle as Macguffin
What the buyer thinks they are purchasing is a car: better performance, lower running costs, some environmental credentials, a tax break, and the pleasure of owning something new. What the purchase actually triggers is a nationwide charging network costing upwards of £10 billion in public investment, changes to building codes so that new developments arrive with chargers already fitted, a rewrite of parking policy in every local authority, and a restructuring of the energy system itself to handle time-of-use pricing and eventually vehicle-to-grid capacity. Road space gets reallocated. None of that was on the window sticker.
You couldn’t get political support for “let’s spend £10B on charging infrastructure.” That would die in governance—why should the state build petrol stations?
But you can sell cars. And if the cars don’t work without infrastructure, the infrastructure stops being optional: range anxiety turns into political pressure, adoption becomes a public mandate, and the manufacturers start lobbying for the public goods their own products depend on.
The car, which is what gets sold and funded, is what Hill calls the matter. The infrastructure, which is what actually changes, is the meta. What makes it a pattern rather than a coincidence is that the range limitations were always going to make the infrastructure unavoidable.
Where the Pattern Differs From Coincidence
Things have knock-on effects all the time, sometimes good and mostly unintended. The pattern is the deliberate version: you design the visible deliverable so that delivering it successfully creates pressure on a constraint you could never have moved head-on.
Hill’s own test is whether a clear design intent survives the entire journey, gone through policy, procurement and legal, and comes out the other end still intact. That needs three things holding together: something fundable and defensible to deliver, a constraint that genuinely needs to move, and implementation choices that tie the first to the second. His formulation of the shift is that you go in saying you need to change the building codes, not that you need to design a timber building.
Remove any one of the three and it stops being the pattern: an accidental connection is only luck, a vague meta layer produces theatre, and a matter layer that doesn’t genuinely deliver for the people using it is simply deception.
The Pattern in Government: GOV.UK
The electric vehicle is a clean example because it’s over, and we can see both layers from here. When GOV.UK launched, none of this was obvious. It looked like a website project.
The funded project was a consolidation: replace 1,882 government websites with one, deliver 25 exemplar services, demonstrate £1.3bn of savings over the Parliament, and improve citizen satisfaction scores. Every one of those is measurable, and none of them frightens anybody. It was fundable and politically safe precisely because it read as a website project.
Almost none of that was what actually needed to change. The real targets were the IT supplier oligopoly that controlled government technology, the waterfall procurement and multi-year contracts that sustained it, a policy culture that treated the PDF as an interface, the near-total absence of service design as a profession inside government, and the departmental silos that made any cross-government service impossible to assemble. You couldn’t get funding for “restructure government’s relationship with technology suppliers.” Nobody would sponsor it, and governance would kill it on ambition alone.
The connection was made in the implementation choices, each of which left the old way harder to defend. Insisting on multidisciplinary teams meant GOV.UK could not be built by developers alone or policy people alone; it needed designers, researchers and product managers, and so created demand for skills the civil service did not yet have. User research came first, which made “start with user needs” the default question and left policy-first approaches looking backwards. Two-week sprints turned the slowness of waterfall into evidence rather than opinion. Open source by default broke the dependency on proprietary systems and made vendor lock-in visible to anyone who cared to look. The service standard then set a quality bar the legacy approaches could not clear, so that “meet the standard or explain why not” quietly relocated the burden of proof.
The visible project was a website. It was designed so that the invisible constraints of procurement, culture and skills became impossible to sustain.
Another Everyday Macguffin
Contactless Payment Cards
Convenience was the pitch. Tap to pay, no PIN below a threshold, faster checkouts, shorter queues, and marketing that talked about nothing except speed and ease.
The payment infrastructure of an entire country changed underneath it. Small merchants who had always dealt in cash (corner shops, market stalls, food trucks) began taking cards as a matter of course. Payment terminals were replaced across the retail sector, and the terminals that replaced them could handle phone-based payment, which is how Apple Pay and Google Pay arrived without needing a rollout of their own. Cash moved from being the default to being the exception.
The connection ran through the customer rather than the merchant. Consumer adoption created merchant pressure, because a shop that didn’t take contactless had to explain itself to people standing at the till. The speed advantage made cash feel slow at precisely the moment of comparison. Terminal manufacturers had every reason to keep the upgrade cycle moving. No bank ever had to persuade anybody to go cashless; the behaviour shifted on its own, which is what makes it a design rather than a campaign.
Mandating the end of cash was never available; it was a political nightmare with real exclusion concerns attached. Making cards convenient enough that cash became the awkward option was available.
Across all three examples the meta layer was unfundable on its own terms, while the matter layer was legitimate enough to stand up by itself and still did the work of making the old arrangement unsustainable.
How Macguffins Fail
Failed Macguffins tend to collapse in one of three places.
1. The Matter Layer Loses Focus
The deliverable becomes too ambitious and the scope creeps until you are trying to fix everything at once. A digital service project becomes a departmental transformation, teams add features and expand remit, and whatever made the original proposition fundable is gradually lost. When the matter layer collapses you get neither the delivery nor the change, and governance cancels you for being unrealistic, which by that point you are.
2. The Meta Layer Stays Vague
Here you can claim strategic intent but cannot say which constraint you are targeting. The tell is in the language: this will drive cultural change, this will modernise government, this enables transformation. Vague meta layers mean nobody designs the connection, so the project delivers, generates no pressure, and changes nothing.
The NHS Apps Library is the clearest worked example I know of. The matter layer was straightforward: assess third-party health apps and publish the ones that pass. The meta layer, as claimed, was a shift from reactive treatment towards prevention. What happened instead is that the assessment became the problem. A review of some 18,000 health apps against more than 350 criteria found only around a fifth met acceptable thresholds for clinical assurance, privacy and usability, and MPs found most of the listed apps failing on efficacy, security or cost. The library closed in 2021, with the department deciding to link to recommended apps from the NHS website instead. It had already closed once before, in 2015, after research found NHS-approved apps leaking user data, and relaunched in 2017.
The library was built twice and retired twice, and by early 2025 the department was reported to be examining the objectives around an app library again. A vague meta layer produces a matter layer that can be built and retired repeatedly without anything upstream ever having to move.
3. The Connection Between Layers Breaks
The deliverable succeeds on its own terms and generates no pressure at all on the constraint.
GOV.UK Verify is the case worth studying, partly because it was genuinely ambitious. The matter layer was a single digital identity system for accessing government services. The intended meta layer was a change in how departments handled citizen data: fewer duplicated identity checks, more sharing, less of every department maintaining its own front door. The platform got built. The meta layer never arrived.
The numbers show where the connection broke. GDS forecast 25 million users by 2020 and had 3.9 million by March 2019. It expected at least 46 services to have adopted Verify by March 2018, and 19 had done so a year after that. The National Audit Office put this down to optimism bias and a failure to set clear objectives, and the Public Accounts Committee concluded that the programme was failing its users and that its leadership lacked accountability. Verify was eventually decommissioned, its remaining services moved across to GOV.UK One Login.
Adoption was the connection, and adoption was the one thing the delivery could not compel. Departments were never required to use Verify, so a department with a working identity check of its own had little reason to take on somebody else’s. The matter layer shipped. Because the implementation never forced the issue, the meta layer stayed theoretical, and what you are left with in that situation is incremental delivery with a strategic aspiration attached to it.
The Uncomfortable Distinctions
Each of these confusions makes the pattern sound easier than it is.
Side Effects Are Not the Same Thing
Everything has unintended consequences. That isn’t strategy, it’s entropy.
What the pattern asks for is intentional design from the outset. The work is to engineer the conditions in which the change becomes unavoidable, which is a different activity from noticing afterwards that it happened.
Nor Is It a Hidden Agenda
A Macguffin is not a way of smuggling something past people. The matter layer has to genuinely deliver for whoever is using it, and if you are misrepresenting what you are building in order to get the other thing done, you have left strategy behind and started manipulating.
The honest difficulty is that the meta layer often cannot be written into the initial business case, because the evidence that would justify it does not exist yet. Producing that evidence is what the project is actually for, and designing it properly is what makes the argument sayable out loud later.
And Most Projects Shouldn’t Be One
Most projects don’t need to be Macguffins. Sometimes optimisation within constraints genuinely serves users best; often the systemic change isn’t politically ready, or you simply don’t have the organisational position to force it.
Strategic theatre is worse than honest incremental delivery.
If you call something strategic when it’s not, you waste everyone’s time and exhaust good designers. Delivering well and serving users is the honest alternative, though it takes some discipline to admit that is what you are doing.
Examples of Strategic Theatre
Theatre is easier to recognise in other people’s work than in your own.
The commonest version is the transformation programme: multi-year, glossy roadmaps, the full vocabulary. What it delivers is paper forms put online, which is digitisation. The organisational structure, the policy assumptions and the burden on the user all survive intact, only faster.
Another is the strategic partnership, in which a department pairs up with technology companies in the name of innovation. A pilot runs, the PR is positive, the learning is captured in a report, the partnership concludes, and procurement is exactly where it was. Aspiration without mechanism.
What both share is the absence of any designed connection between the delivery and the change it is supposed to cause.
A harder case sits alongside them. The National Fraud Initiative has been matching data across public sector databases since 1996, and it is easy to caricature: thousands of matches, a good number of them false positives, and an exercise that recurs every two years without the underlying vulnerabilities going anywhere. But the matter layer genuinely delivers. It reports £443 million of fraud and error prevented, detected or recovered in the two years to March 2022, and roughly £2.4 billion cumulatively since it began. Its own strategy is candid about needing better matching rules and risk scoring to bring the false positive rate down.
So the initiative is not theatre. It is something more common and harder to see: a matter layer that works, attached to no meta layer at all. Nobody designed it to make the upstream processes that generate the vulnerability harder to defend, and so those processes have gone on generating it for thirty years while the detection has steadily improved. A project can be genuinely valuable and still leave the constraint completely untouched.
When You Have Leverage vs. When You Don’t
Service designers often lack any real power over meta layers. You can design the perfect Macguffin on paper, but if you cannot influence policy, procurement or organisational design, it stays on the paper.
The pattern asks for three things that are not usually in a designer’s gift: enough political sense to know who needs which piece of evidence and when, enough patience to let pressure accumulate over years instead of sprints, and a position close enough to the people who actually control the constraint. Embedded in a delivery team you have limited access to any of them. You can build implementations that generate evidence, and you can surface contradictions, but you cannot force systemic change on your own.
The narrower version is still worth doing. You can design your deliverables so they produce evidence a policy team would find awkward to ignore, and frame what you find as a learning question rather than an accusation, which keeps the conversation open rather than closing it. You can build alliances with the people who do sit near the constraint. And you can document the pattern well enough that whoever comes after you starts further along than you did.
You cannot force a constraint to move through delivery alone, or design your way around a political reality, or transform a system that nobody has given you permission to touch. The honest version is to use the pattern where you have the position for it, and to do excellent delivery where you don’t.
Pace Layers and Strategic Timing
Hill connects the Macguffin to Stewart Brand’s pace layers, which is what makes the timing legible. Brand had architecture in mind, though the idea landed more usefully in thinking about platforms. In the public sector the layers double as a read on where there is any appetite for risk at all.
Your deliverable sits in the fast layer, measured in six to eighteen months. Organisational practice and procurement move in the medium layer, over two to five years. Policy assumptions and institutional culture are the slow layer, and they shift across a decade if they shift at all. The move is to design fast-layer deliverables that create pressure on the medium layer.
A six-month pilot will not change ten-year policy assumptions directly. It can shift two-to-five year procurement practices, and those eventually create the conditions in which policy can move.
A worked example: a six-month trial of a new service delivery approach in one location, aimed at the medium layer, where procurement sits. The trial is legitimate on its own terms, since whether agile delivery shortens time-to-market is a reasonable thing to want to know. But the implementation choices are all pointed at procurement. Building with a multidisciplinary team instead of contractors sets a skills precedent that is hard to unset. A demonstrable improvement in delivery speed becomes the efficiency argument for changing how contracts get let. The integration problems the trial runs into are evidence of how legacy contracts create barriers, documented in the course of ordinary work instead of in a complaint. Improvements the users themselves notice build the political case for scaling.
Funding for “let’s redesign our entire procurement approach” was never going to arrive. Funding for “let’s trial a new service delivery method” was. The trial is built so that scaling it requires exactly the procurement changes nobody would have approved on their own.
The timing rule is to match the Macguffin to the layer next door. Fast work can shift the medium layer and the medium layer can shift the slow one, but fast work aimed straight at slow constraints just dissipates.
The Diagnostic Questions, Expanded
The question I opened with, about which constraint we’re accepting and which we’re targeting, expands into something more usable.
- Which constraint are we targeting? (meta layer, and be specific)
- What evidence would make it untenable? (What you need to prove)
- What are we delivering that generates that evidence? (matter layer)
- How do our implementation choices ensure the connection? (Design intent)
Answer all four and you’re designing a Macguffin. Without the first, what you have is incremental delivery, which is often the right call; without the fourth, it’s theatre, which never is.
None of this needs elaborate documentation. It needs you to be clear about what you’re actually trying to change, and honest about whether the project is built to create the pressure that would change it.
Most strategic work happens in small implementation choices that nobody records as strategy. Which users you recruit for research decides whose experience gets to count as evidence. How you structure a findings presentation decides which conclusions are easy to reach and which take effort. The metric you pick, the location you pilot in and the way you write up what happened are all places where the status quo gets quietly reinforced or contradicted in writing, usually before anyone has called it a strategic decision at all.
How to work through this on an actual brief, including which constraints are worth trying to shape and which are better left alone, is in The MacGuffin Pattern: A Working Guide.
Where This Leaves Me
Most “strategic” government projects are complicated delivery with aspiration attached. If you can’t articulate how your implementation choices connect the delivery to the systemic change, you’re not being strategic, you’re being hopeful.
The failure I opened with, perfect delivery into a system that stays broken, is a failure of ambition rather than craft. It happens because you optimised inside the constraints instead of using the project to move them. I have written elsewhere about the opposite move, designing the friction so that the constraint becomes the thing that teaches, which is the same question asked from the other end. Not every project has to be transformational. But where the constraints are doing real harm, where they create poverty traps or exclude the people least able to work around them, “excellent delivery within constraints” starts to look like a choice rather than a limitation.
Which is where the pattern gets uncomfortable, because it asks you to be honest about three things at once: what you’re actually trying to change, whether you’re positioned to change it, and whether the implementation creates any real pressure. Without those, the pattern gives you a vocabulary for the work rather than the work itself.
Further Context
The Macguffin concept comes from Dan Hill’s writing on “dark matter”—the organisational, political, and cultural context that shapes what’s possible in design. He argues that most designers focus on the visible project layer whilst ignoring the constraint layer that determines whether change is possible.
His worked examples are worth reading directly: Low2No, a residential building in Helsinki that pulled nineteenth-century timber building codes with it, and the iPlayer as a Macguffin for change inside the BBC.
Stewart Brand’s “Pace Layers” framework helps explain why the pattern works: fast-moving layers (projects) can create pressure on slow-moving layers (policy, culture) if designed correctly.
Donella Meadows’ “Leverage Points” framework complements this: the highest-leverage interventions aren’t about optimising system parameters, but about changing the rules that govern the system.
The Macguffin Pattern sits at the intersection of these ideas: using fast-layer delivery to shift medium-layer constraints by designing the connection between them.
The figures quoted above are drawn from the National Audit Office’s 2019 investigation into GOV.UK Verify and the Public Accounts Committee’s follow-up; from reporting on the closure of the NHS Apps Library and the committee work that accompanied it; and from the Cabinet Office’s own National Fraud Initiative report covering 2020 to 2022.
A Note on Language
I’ve used “Matter/Meta/Design Intent” language in this piece because it’s precise. But you don’t need to use this terminology with stakeholders.
In business cases and governance papers, frame it as:
- “What we’re delivering” (Matter)
- “What we’re learning” (Meta, reframed as evidence generation)
- “How our approach ensures valid findings” (Design Intent, reframed as methodology)
The pattern works regardless of what you call it, as long as the implementation choices actually connect the delivery to the change.
With your colleagues and other designers, you might stick with the more accessible language from my LinkedIn post: “Which constraint are we accepting vs. which constraint are we targeting?” This tends to land faster than the technical terminology.
The point was never to make everything a Macguffin. It’s to be able to tell the difference between work that changes a system, work that optimises one, and work that only performs the change. I find that much harder to do on my own projects than on other people’s, which is probably the real test.