The Logic LoopStart a project
← Journal

How to brief a design studio so scope doesn't balloon

Scope creep almost never starts with someone asking for something unreasonable. It starts with a brief that described the deliverable but never defined success — so every stakeholder who joins the review has an unspoken, undocumented idea of what "better" means, and the project quietly grows to satisfy all of them at once.

The single highest-leverage thing a good brief does is set the KPI before any design decision gets made — not after the work ships, when it's too late to prove anything moved. If nobody agreed what you're measured against before wireframes exist, there's no way to say a request is out of scope, because scope was never actually defined. It was implied, and implied scope is infinitely negotiable.

Past that, the parts of a brief that actually change how a project goes: who the final decision-maker is, named, not "the team." What's explicitly not being solved this round — a good brief is as clear about exclusions as inclusions. And a realistic account of your own bottleneck, because the honest answer to "why did the timeline slip" is almost always waiting on the client, not the studio — late content, slow feedback rounds, an internal approval chain nobody mapped out up front.

What a brief doesn't need: a folder of competitor screenshots with no reasoning attached. "Something like this" without why tells a studio what you like, not what you need, and a studio optimizing for what you like instead of what moves your number is optimizing for the wrong thing entirely.

Keep reading

All writing