Most design projects that go wrong do so before anyone opens a design tool. The brief was vague on scope, the client had an implicit definition of success that was never written down, and the team started executing before anyone had agreed on what the deliverable actually was. A few weeks in, the misalignment becomes impossible to ignore. At that point, recovering takes more energy than the work itself would have required.
I have been on both sides of this. Early in my practice, I absorbed scope ambiguity as a normal cost of working with clients. I would resolve it through iteration: show work early, adjust based on feedback, refine toward something that felt right. That works, but it is slow, and it transfers the cost of unclear thinking onto the production phase, where it is most expensive to absorb.
What a scoping document actually contains
At some point I started spending the first week of any significant engagement on a single document: a scoping brief. Not a project plan. Not a timeline. A written agreement on what problem we are solving, for whom, and what constitutes a finished and successful deliverable.
The structure I use has five sections. The problem statement: one or two paragraphs describing the situation we are responding to, written in plain language, with no solution language in it. The target user or stakeholder: who specifically is experiencing this problem, and in what context. The scope of delivery: what the engagement produces, described in terms of artifacts and decisions rather than activities. The explicit exclusions: what is out of scope, written down and signed off on. And the success criteria: how we will know, at the end, whether we did what we set out to do.
The explicit exclusions section is the one that generates the most productive friction. Clients rarely push back on what is in scope. They push back when they realize something they assumed was included is not. Writing the exclusions forces that conversation into week one, when it is still cheap to resolve.
Why this is design work, not administrative overhead
There is a tendency to treat scoping as paperwork: something you do to protect yourself or satisfy a procurement process, not something that has design value. That framing is wrong, and it produces scoping documents that no one reads.
A well-written problem statement is a design artifact. It requires the same skill as writing a good brief for a creative team: precision, economy, and the discipline to leave out what is not yet known. Writing it forces you to surface the assumptions embedded in the client's request. "We need a redesign of the onboarding flow" contains at least three hidden assumptions about where the problem lies, what users need, and what success looks like. Unpacking those assumptions in writing, before work starts, is the first act of design thinking on the project.
The scoping document also functions as a shared reference during the project. When scope creep happens, and it always does, having a written agreement creates a decision point rather than a drift. "This is interesting, and it falls outside the scope we agreed on. Do we want to extend the engagement, or do we deprioritize it?" That is a better conversation than the one that happens when the boundary was never written down.
The template I use and what it replaces
I built a scoping template over several projects and make it available as a resource on this site. It is intentionally minimal: a few pages, plain language, no graphics. The point is that anyone on the project, including a client who is not a designer, can read it in ten minutes and understand what the project is.
What it replaces is the meeting where everyone nods and thinks they agreed on the same thing. Those meetings are where the misalignment gets baked in. The document creates a moment of accountability: you have to write down what you think the project is, and the client has to confirm or correct it. That exchange, done properly, is more valuable than any subsequent delivery review.
The discipline this requires from a practitioner is real. Spending week one on a document instead of on wireframes or research feels counterproductive when the pressure to show output is high. But the compounding effect over a three-month engagement is significant: fewer revision cycles, cleaner decisions, and a final delivery that both sides recognize as what was promised.