J. Paul is a London based designer and researcher with expertise in Speculative Design, Service Design, Design Research, and Strategy.
NKD_1 — Anytime we consider anything less than everything, we are missing something.
The misconception it corrects
The dominant habit in modern strategy is to cut scope ruthlessly. Narrow the problem. Define the system boundary. Decide what is in-scope and what is out, and protect the in-scope from contamination by the out. This is taught in business schools and most design programmes as a virtue: discipline, focus, rigour.
It is also where most projects' real risks live. The risks that take down products, brands, partnerships, and strategies are almost never inside the scope as drawn. They are in the part of the world the team decided not to look at — because it was deemed irrelevant, out of scope, someone else's problem, or simply too messy to include.
NKD_1 is the principle that names this. It does not say "consider everything." That would be paralysis. It says: anytime we consider anything less than everything, we are missing something — and that we should know, in writing, what we have chosen to miss.
What it changes in practice
Three concrete shifts.
Scope is documented twice. Once as what is in-scope. Once as what is deliberately excluded. The second list is the more useful artefact. It surfaces the assumptions the team has made about what is safe to ignore, and lets those assumptions be challenged before they become buried.
Risk reviews look outward, not inward. Standard risk processes look at risks within the scope: timeline, budget, delivery quality. NKD_1-trained risk review asks the harder question: what is the biggest risk to this project from outside the scope as drawn? That is almost always the question that finds the real failure mode.
Stakeholder mapping includes the not-yet-present. A scope drawn around current stakeholders systematically excludes future ones: future customers, future regulators, future affected parties. NKD_1 forces the question — who is not at the table whose absence will be a problem in three years?
A working method: the exclusion register
This is the single technique we have found most useful for applying NKD_1 in client work. It takes about an hour to set up and pays for itself within the first month of any non-trivial project.
At the start of an engagement, alongside the scope statement, build an exclusion register. It is a table with three columns:
| What we are not considering | Why we have excluded it | What would force us to reconsider |
|---|---|---|
| (a system, a stakeholder, a timescale, a domain) | (the reason — capacity, relevance, jurisdiction) | (the specific signal that would re-open this) |
Every row is a declaration. Every row is also a tripwire: if the third column's signal appears during the project, the register is reopened.
Two things happen when this is done well.
First, the act of writing the register is itself revealing. Teams discover, in the writing, that they had been planning to ignore something they should not have been. That discovery is far cheaper to make in week one than in month nine.
Second, the register provides a defensible answer when stakeholders ask "did you consider X?" The answer is not the defensive "yes, we considered it." The answer is "we deliberately excluded X for these reasons; here is what we would need to see to reconsider." That is a far more credible posture, and it ages much better.
Where this principle lives in our work
In every framing workshop, the exclusion register is part of the output. It is the artefact most clients tell us, six months later, was the one that changed how they ran the rest of the project. We did not invent it; the discipline of explicit exclusion is borrowed from systems thinking. But NKD_1 is why we will not run a project without it.
Key takeaway: the biggest risk to most projects is outside the scope as drawn. Document what you are excluding as carefully as what you are including, and write down what would force you to reopen the exclusions.
← Series introduction | Next: NKD_2 — Designing for connection →