A vague brief is not a failure of the client — it's a design problem in its own right. Clients give vague briefs because the problem isn't yet well-understood, the stakeholders haven't aligned, or the team doesn't yet have the language to describe what they need. Scoping is the work you do before the design work to make the design work possible.

Don't ask for clarity — offer it

Asking a client to 'tell you more' often produces more vagueness. A better approach is to come with your own tentative interpretation of the brief and ask them to correct it. 'Based on what you've shared, I'm reading this as: you need a way for customers to self-serve their account upgrades without contacting support. Is that right?' This gives the client something to react to, which is far easier than generating clarity from scratch.

Identify the actual decision maker

In complex engagements, the person who briefed you often isn't the person who will sign off on the outcome. Understanding who holds the final decision and what they care about is scoping work, not political manoeuvring. Ask early: 'Who else has a stake in the outcome of this project? Who will need to approve the final direction?' The answer changes how you frame the problem and the solution.

Bound the scope with a problem statement

The most useful output of a scoping conversation is a written problem statement that both sides have agreed to. Not a solution, not a set of requirements — a clear description of what's wrong, for whom, and what a better state would look like. This statement becomes the test against which all subsequent decisions are measured. If a stakeholder asks for something that doesn't serve the problem statement, that's your anchor for the conversation.

Name what's out of scope

Scope creep rarely announces itself. It accumulates through individually reasonable requests that collectively shift the scope beyond what was agreed. Naming what's explicitly out of scope at the start — in writing — creates a reference point for those conversations. 'That's outside the scope we agreed. It's worth adding to the backlog, and we can discuss whether to expand the engagement to cover it' is a professional, clear response. It's only possible if you defined the edges early.

Deliver a scope document, not an email

The output of your scoping work should be a short document — one or two pages — that captures the problem statement, the agreed scope, the key assumptions, and the decision-making process. Ask the client to confirm it in writing. This is not bureaucracy. It's the foundation that every subsequent design decision will be built on. A project without a confirmed scope document is a project that will reopen its scope at every difficult conversation.