What a good client brief actually looks like

We've read a lot of client briefs at this point, ranging from a single rushed paragraph to documents running dozens of pages, and length has almost no relationship to how useful a brief actually turns out to be. A one-page brief with sharp, specific answers in the right places beats a twenty-page document full of generic ambition every time.

What separates a genuinely useful brief from a padded one is where the specificity lives. Most briefs are specific about the wrong things, company history, mission statements, competitor lists, and vague about the handful of details that actually determine whether the resulting project succeeds.

A good brief states, in one clear sentence, what problem this project is actually solving for the business, not what feature it includes. "We're losing leads because our current site doesn't explain our service clearly enough" is a real problem statement. "We need a new website" is not, and it leaves too much room for two reasonable people to build toward different goals.

We ask for this sentence explicitly if a brief doesn't already contain one, and we don't move forward with scoping until we have an answer specific enough to actually test against later. If we can't tell, at the end of a project, whether that sentence's problem got solved, the brief wasn't specific enough to begin with.

"We want something modern" is nearly useless on its own. "We want something like this specific competitor's site, but with a warmer color palette and simpler navigation" is immediately actionable, because it gives us a concrete reference point to agree or disagree with specifically, rather than an abstract adjective we'd otherwise have to interpret independently and hope we guessed right.

We ask every client for at least three reference examples, with a specific note on what they like and don't like about each one. This single request produces more useful design direction than almost anything else in the intake process, because it forces specificity that abstract descriptions almost never achieve on their own.

A good brief says what's fixed, budget ceilings, brand elements that can't change, a hard deadline tied to a real external event, as plainly as it states what's open for exploration. Constraints left implicit tend to surface midway through a project as unpleasant surprises, right when they're most expensive to accommodate.

We ask directly: what would make this project a failure in your eyes, even if everything else went well. That question reliably surfaces constraints a client hadn't thought to mention explicitly, because it approaches the brief from the opposite direction of most intake questions, which tend to focus only on what a client wants rather than what they specifically can't accept.

A brief that doesn't name a single final decision-maker is setting up a project for exactly the kind of stalled, contradictory feedback that derails timelines. We ask for this by name before a project starts, not as a formality, but because we've seen projects lose weeks to feedback that came from three different people with three different, unreconciled opinions.

This can be an uncomfortable question for a client to answer if their own organization hasn't sorted it out internally, but that discomfort is far cheaper to resolve before a project starts than during it, when unresolved authority questions turn every revision round into an unpredictable negotiation.

A brief that defines success only as "we'll know it when we see it" gives a team nothing concrete to build toward or measure against afterward. A brief that says "a twenty percent increase in form submissions within three months of launch" gives everyone a shared target, and it changes design and content decisions throughout the project, not just at the very end.

Not every project has a number this clean available, and that's fine, but we push for the closest measurable proxy a client can offer. Even a softer target, stated explicitly, is more useful than no target at all, because it gives the whole team something concrete to check decisions against along the way.

Most briefs we receive are missing at least half of these elements, and that's genuinely normal, not a red flag about the client. We treat an incomplete brief as the starting point for a structured intake conversation, not as a document to simply accept and build from as written.

We've never had a client push back on being asked these questions directly, even when their original brief didn't cover them. Most are relieved that someone is asking, because it means the resulting project is far more likely to actually solve the problem they came to us with in the first place.

The clients who write the strongest briefs, unsurprisingly, tend to have already done real thinking about their own problem before writing anything down. That thinking shows up as specificity, not length, and it's the single best predictor we've found of how smoothly a project is going to run from kickoff to delivery.

We now share our own intake questions publicly with prospective clients before a first call, specifically to help them arrive with a stronger brief already in hand, because a strong brief benefits everyone in the relationship, not just us.

A good brief isn't a longer document. It's a document that's specific in the handful of places that actually determine whether a project succeeds: the real problem, concrete references, real constraints, real decision-making authority, and a measurable definition of success.

Everything else, company history, broad ambition statements, market context, is useful color but rarely changes what we actually build. We read it, we appreciate it, and then we go looking for the parts that actually matter if they're not already there.

Clients who write briefs this way consistently get better projects, not because the brief itself does the work, but because writing it forces exactly the kind of clarity that a project needs from the very first day to run well.

We'd rather spend an extra hour on intake questions upfront than discover, three weeks into a build, that we were solving a different problem than the one the client actually needed solved all along.