The MacGuffin Pattern: A Working Guide
For service designers putting the pattern to work on a live brief.
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.
This is the working half of The MacGuffin Pattern, which argues that a project can be designed so that delivering it puts pressure on a constraint nobody would have agreed to change directly. That essay makes the case. This is the part you can run on a real project.
It is meant to be worked through with a brief in front of you rather than read straight down. The three passes start from what you have been funded to deliver, go down to the constraint sitting underneath it, and end on whether your implementation choices genuinely connect the two.
How to Think About Your Own Work
Asking whether a project already is a Macguffin is less useful than asking whether it could have been designed as one, which is a question you can put to anything currently in front of you.
1. Start With What’s Fundable (Matter Layer)
Every project begins with something stakeholders agreed to fund, so start by writing down what you are actually producing, how the problem has been framed officially, and what somebody has already decided will count as done. Those are usually easy to establish and worth having in front of you before anything else.
You can tell quickly enough which territory you are in. Constraint-shaped work is audible in its verbs, which are reliably implement, comply with, ensure. Its success metrics measure delivery and then stop, which tells you the outcome was never really the point. The timeline gives it away as well, running to twelve months because that is how long a budget year lasts. And the constraints will be sitting in the brief with nobody having asked where they came from, as though they arrived with the building.
Constraint-shaping work reads differently. The problem statement contains phrases like test whether, or explore alternatives to, or evaluate assumptions. Learning and evidence appear in the success criteria alongside delivery. The scope admits that something systemic is wrong without claiming to know how to fix it, and somebody involved is audibly frustrated with the way things are done.
2. Surface What Actually Needs Changing (Meta Layer)
Dig beneath the official project to find what really needs to change.
Start with what the brief has already settled. Which constraints are baked into it, and what does the problem statement assume without ever saying so? A useful move is to imagine the project with one constraint removed and see what survives, because whatever survives is the part somebody actually wanted. Then find out who wrote the problem definition. People protect things when they write definitions, and it is usually possible to work out what. Every problem statement embeds assumptions: “improve verification process” assumes verification is necessary, “design fraud journey” assumes fraud is intentional deception. The work is finding what has quietly been taken as given.
The stakes are harder to see. If this project succeeds perfectly, what still will not have changed? Solving a visible problem tends to expose a second one behind it, and the second is frequently the more interesting of the two. Imagine flawless execution, every deliverable met and every metric hit, then look for the systemic problem that survives it. That is usually the real target, and naming what would make it untenable is the beginning of a plan.
The evidence question is the one that turns any of this into a plan. Ask what the project will generate that does not exist today, and which stakeholders would find it compelling enough to act on. The sharper version of that question is what data would make the current approach difficult to defend out loud. Every project produces data whether or not anyone planned it, so the question is what yours is designed to produce.
3. Design the Connection (Intent Layer)
Every implementation choice is a small bet about which layer you are serving. The useful ones do one of two things. They generate evidence the constraint cannot easily absorb, or they create a dependency the system then has to accommodate. Either route leaves the old way harder to defend, which is the mechanism actually doing the work, and the best choices also leave capability behind that the organisation keeps after you have gone. Most choices do none of this, which is usually fine and occasionally the whole problem.
The difference shows up in decisions that look purely operational. Where you run a pilot is the clearest case. Easy locations produce quick wins and tell you nothing, while a location chosen because it stresses the policy’s core assumptions produces an argument. Success metrics behave the same way, in that an eighty per cent adoption rate is a number nobody can act on, whereas completion rate broken down by demographic will surface exclusion patterns whether or not anyone wanted them surfaced.
Delivery approach and documentation are less obvious. Building inside the existing systems is the path of least resistance; building a prototype that demonstrates the legacy system is the bottleneck converts a widely held suspicion into something citable. And user research written for the design team stays with the design team, where research formatted for policy stakeholders occasionally travels.
Every choice either reinforces the constraint or puts pressure on it. Which of the two is happening tends to be clearer in a finished project than in a live one.
Practical Application: Reframing Problem Statements
The clearest signal of constraint-shaping work is how the problem gets framed.
A constraint-shaped problem statement accepts the constraint and gets on with delivery. Implement digital identity verification. Improve the fraud prevention journey. Design the benefits application process. Each of those treats something as settled and asks only how well you can execute inside it.
Put the constraint itself in scope and the sentence gets longer and considerably more awkward to say in a governance meeting. You end up asking whether universal upfront identity verification is compatible with digital service delivery and equitable access, or whether current fraud prevention assumptions cause more harm than the fraud they prevent. The awkwardness is doing the work here, because nobody can agree to a sentence like that without also agreeing to find something out.
A good reframe makes the constraint explicit and positions it as something being tested instead of assumed. It has to carry the delivery and the systemic question together, and it has to leave room to challenge on the basis of evidence instead of opinion. Hill quotes a distinction that helps here. Analysis tells us how things are, whereas synthesis tells us how things should be. The reframe is what creates permission to generate the inconvenient version of the second one.
What Makes Constraint-Shaping Possible
Not every constraint can or should be shaped. The ones worth attempting are usually organisational habits rather than legal requirements: procurement or technology decisions made years ago by people who have since moved on, assumptions nobody remembers choosing, practices that persist because that is how it has always been done. Demonstrable user harm strengthens the case considerably, since harm is the one argument that survives contact with another department.
The poor candidates matter just as much, because recognising one early saves a year. Legal and regulatory requirements need policy change first, and no quantity of evidence generated inside a delivery project will substitute for it. Constraints that exist to protect vulnerable people deserve the benefit of the doubt until proven otherwise. Resource limits will not move because you documented them well, and neither will anything genuinely outside your organisation’s control.
The test I would apply is whether changing the constraint would serve the people using the service, or whether you are simply frustrated by organisational friction, which is a different problem and not one the pattern solves.
Using It
On a new project the four-question diagnostic in The MacGuffin Pattern is worth running before you commit to an approach, mostly because it forces you to say out loud which constraint you’ve decided to accept. Mid-project it works as a check on whether the connection between the layers is still holding, and as permission to admit that the work has become incremental. On finished work it is more interesting still: some of the transformations we all cite as deliberate strategy turn out, on inspection, to have been luck with good post-hoc narration.