You've been here before. The kickoff meeting went perfectly. Everyone nodded along as you walked through the brief. The client signed off, the project began, and then — somewhere around week three — everything started falling apart.
The client wanted something different than what was written. Or they wanted what was written, but also this other thing they forgot to mention. Or they wanted exactly what was written, but they're disappointed now that they're seeing it. The brief that was supposed to prevent these problems turns out to have prevented nothing at all.
This is so common that we've almost stopped questioning it. Briefs fail. Projects drift. That's just how it works.
But it doesn't have to be. Most briefs fail for predictable reasons, and those reasons are entirely fixable once you understand what's actually going wrong.
The Gap Between What Clients Say and What They Mean
The fundamental problem with briefs is that they're built on a foundation of miscommunication that nobody acknowledges.
When clients describe what they want, they're doing their best to translate internal visions into external language. But that translation is inherently lossy. The words they choose carry connotations they don't intend and miss meanings they assume are obvious. "Clean design" means something different to everyone who says it. "Easy to use" is subjective in ways that only become apparent when you're arguing about it later.
Designers hear these words and translate them again, this time into professional concepts. The client's "clean" becomes your "minimalist." Their "easy to use" becomes your "intuitive navigation patterns." Each translation adds another layer of potential misunderstanding.
By the time these twice-translated ideas appear in a brief, they may bear only passing resemblance to what the client actually imagined. And here's the cruel part: both parties look at that brief and see their own interpretation reflected back. The misalignment is invisible until the work begins.
The solution isn't to use more precise language, though that helps. The solution is to externalise the translation process. Show clients how you're interpreting their requirements, explicitly, in the brief itself. "When you say clean design, we understand this to mean generous whitespace, limited colour palette, and prominent typography. Here are some examples of what we're envisioning." Now the gap is visible. Now it can be corrected.
Assumptions Masquerading as Agreements
Every brief contains assumptions. Some are explicit — the project assumes the client will provide content by a certain date, or that the existing brand guidelines will remain in force. These explicit assumptions are relatively safe because everyone can see them.
The dangerous assumptions are the implicit ones. The designer assumes the client understands how design iterations work. The client assumes the designer will be available for meetings during business hours. Neither assumption is stated, because both parties think it's too obvious to mention.
The most destructive assumptions are the ones nobody thinks to question.
These invisible assumptions don't cause problems until they collide. The designer delivers three concepts expecting feedback on direction; the client expected three finished designs to choose from. Both had assumptions; neither stated them; now there's conflict where there should have been clarity.
I've started including an "Assumptions" section in every brief, not for the obvious assumptions, but specifically for the ones that feel too obvious. How many revision rounds are included? What does a "revision" mean versus a "new direction"? Who makes final decisions when stakeholders disagree? What happens if timelines slip due to delayed feedback?
These questions feel awkward to raise when everyone's optimistic about the project. But answering them in the brief is vastly preferable to answering them during an argument.
The Problem of Premature Agreement
Clients sign briefs they haven't really read. This is an uncomfortable truth that designers rarely acknowledge, partly because acknowledging it would mean redesigning how we create briefs.
It's not that clients are lazy or don't care. It's that briefs are often dense, formal documents written in designer-speak. Reading them carefully requires time and mental energy that busy clients don't always have. So they skim. They catch the headline points. They miss the details that will matter later.
Then they sign, and that signature creates a false sense of security for everyone. The designer thinks they have agreement on specifics that the client never actually absorbed. The client thinks they've understood a document they mostly skimmed. Both proceed with confidence that turns out to be misplaced.
The fix isn't to lecture clients about reading more carefully. The fix is to create briefs that work even when skimmed. Crucial information shouldn't be buried in paragraph seven of section three. It should be highlighted, summarised, pulled out into unmissable callouts. If something is important enough to argue about later, it's important enough to make impossible to miss now.
Better still, walk through the brief verbally before asking for sign-off. Not as a presentation, but as a conversation. "Here's what we're committing to. Here's what we're not including. Here are the decisions you'll need to make and when." This takes longer, but it creates genuine understanding rather than performative agreement.
Briefs as Documentation Versus Briefs as Communication
Here's where most briefs go wrong at a fundamental level: they're written as documentation when they should be written as communication.
Documentation is comprehensive. It covers every base, anticipates every question, creates a complete record. Documentation is what you hand to a lawyer when there's a dispute. It protects you.
Communication is different. Communication is designed to create shared understanding. It emphasises what matters most. It invites response. It aims for alignment rather than coverage.
Most professional briefs are documentation wearing communication's clothes. They're comprehensive records of project requirements that happen to be sent to clients as if they were conversational documents. Clients respond to them the way anyone responds to documentation: they skim, they sign, they file them away.
Effective briefs flip this priority. They communicate first and document second. The primary goal is to align understanding between designer and client. The secondary goal is to create a record of that alignment. When you write with communication as the priority, you make different choices about structure, language, and emphasis.
This shift is subtle but transformative. Documentation asks "What needs to be included?" Communication asks "What needs to be understood?" The former produces complete briefs. The latter produces effective ones.
What Good Briefs Actually Do
A brief that works isn't one that perfectly predicts the future. Requirements will change. Priorities will shift. Discoveries will invalidate assumptions. No brief can prevent this, and none should try.
What good briefs do is create a shared foundation for navigating these changes. When client and designer genuinely understand the project's goals, constraints, and success metrics — not just the words describing them, but the meaning behind those words — they can adapt to changes without losing alignment.
A good brief also creates accountability that both parties can hold. Not legal accountability that gets invoked during disputes, but collaborative accountability that keeps the project honest. When someone suggests adding a feature, a good brief provides the context to evaluate whether that addition serves the project's goals or distracts from them.
Most importantly, a good brief starts a conversation rather than ending one. The best briefs I've worked from were documents that generated questions, clarifications, and discussions. By the time we reached agreement, both sides understood not just what the project was, but why it was that way.
This is what briefs should be: tools for creating alignment, not just recording requirements. Tools for communication, not just documentation. Tools for building relationships, not just defining projects.
The brief that fails is usually a brief that was never really agreed upon, just signed. The brief that works is the one that created genuine understanding before any work began.
That's the difference. Everything else follows from it.