How to write a design brief that people actually use

The brief that nobody reads is one of the standard artifacts of design organizations. It gets written during the kickoff phase when everyone is enthusiastic and aligned, added to the Notion page, linked in the project document, and opened once by the designer before they start working. Then it sits there as evidence that there was a brief, which is not the same thing as the brief being useful.

Most briefs fail because they're written for the wrong purpose. They're written to demonstrate that the problem was thought through, rather than to give the designer information they need to make decisions. These are different documents with different structures, and the second one is the only one worth writing.

What a brief actually needs to do

A brief that changes design decisions needs to do three specific things. It needs to define the problem precisely enough that the designer knows when they've solved it. It needs to state the constraints that are real, separately from the constraints that are preferences. And it needs to say explicitly what failure looks like so the designer can self-evaluate against something concrete.

The problem definition part is where most briefs fail first. "Improve the onboarding experience" is not a problem definition. "New users aren't completing account setup. 60% drop before adding payment information, and our qualitative research suggests the form length is the biggest reported reason" is a problem definition. The first brief leaves the designer to choose what to solve. The second tells the designer what to solve.

The constraint distinction matters because designers working against a brief can't tell which constraints are real and which are negotiable. "Must use the current design system" is a real constraint if breaking it means a significant engineering lift. It's a preference constraint if someone just doesn't want to revisit that decision right now. Treating both as equally fixed produces designs that work around things that could have been addressed and miss the things that genuinely couldn't.

The success criteria problem

Most briefs include a goals section. Most goals sections are aspirational: "create a better experience for users," "increase completion rates," "reduce confusion." These aren't wrong. They also don't give the designer a way to evaluate whether their design is working.

A useful brief has success criteria that are specific enough to argue about. "The redesigned flow should be completable in fewer steps than the current one" is evaluable. You can count steps. "The form length concern should be addressed directly" is a directive the designer can make decisions against. "Better experience" is something the designer can believe they've achieved without actually achieving it.

Arguing about success criteria during the brief is the point. If the product manager says "improve retention" and the designer asks "what would a 5% improvement in onboarding completion look like as a brief criterion" and nobody knows the answer, that's a conversation that needed to happen before design started. The brief forces the question. The question produces clarity that the design work needs.

Length and format

The briefs that get read are short. Not because short is inherently better, but because a four-page brief tells the designer that understanding the problem requires four pages of reading, and the first time someone is trying to make a quick decision they'll skip to the work instead.

A brief that works can be structured as three sections without headers: the problem (two to four sentences), the constraints (a short list, distinguished between real and preference), and the criteria for evaluation (two to three sentences specific enough to be falsified). Total length: half a page to one page. If it takes more than that to describe the problem, the problem probably isn't defined clearly enough yet.

The exception is a brief for a large, complex piece of work where multiple teams need to be aligned. These can be longer and should be. But they're a different document than the brief that guides the design work. Treating the stakeholder alignment document as the design brief is a common mistake. The alignment document is for getting everyone on the same page. The design brief is for giving the designer what they need to work. They have different audiences.

Who should write it

The brief is usually written by whoever is responsible for the product decision. A product manager, a design manager, occasionally a designer who owns their own scope. The question of who should write it is less important than the question of who should review it before the work starts.

The designer who will do the work should read the brief and have the opportunity to push back on it before committing to it. "I don't think this constraint is real. Can we talk through why it's here" is a conversation worth having upfront. So is "I'm not sure I understand what success looks like. Can you give me an example of a design you'd reject against this criterion." These conversations surface ambiguity when it's cheap to resolve it, instead of after several design cycles.

The brief review is also the moment where the designer can flag if they think the problem definition is wrong. "I think the form length is a symptom of a deeper problem with the information architecture" is easier to raise before the work starts than three weeks in.

The living brief

Briefs get outdated as the work reveals things the brief assumed. The form length was the problem, except it turns out users don't trust the product enough to enter payment information, and that's the actual issue. When this happens, the brief needs to be updated, not abandoned.

An outdated brief that isn't updated is worse than no brief, because it gives the impression that the work is still solving the original problem while actually solving a different one. The review cycle that happens against the original brief and produces misaligned feedback is a real cost.

Updating the brief when the understanding changes is one of those habits that feels like overhead and prevents a lot of work from going in the wrong direction.

The brief that gets used isn't the most thorough one. It's the one that gives the designer something concrete to argue with. A problem they can recognize when it's solved. A constraint they can test against the ones that aren't real. A success criterion specific enough to be wrong about. A brief that can't be falsified isn't doing its job. Most of the briefs that go unread are exactly that: too vague to disagree with, which means too vague to act on.