How to write a brief for better proposals

The brief is the most useful document in a project. An hour spent making it clear saves weeks of proposals that answer different questions, and months of work on the wrong problem. The good briefs we read share one shape.

Start with the problem, not the solution

“We need a new website” is a solution. “Prospects cannot tell which of our three products fits them, so sales spends the first call explaining it” is a problem. It invites better answers. Design practice keeps the problem open before choosing a solution: the Design Council’s Double Diamond spends its first half discovering and defining it.¹ UK government service teams run a discovery phase before committing to a build.²

Six sections a brief needs

1. The problem: what is happening, for whom and what it costs today.
2. The people: who uses the result and who decides. Write each need in this form: as a [person], I need [something] so that [outcome].³
3. What success looks like: the two or three measures you will report, with a baseline if you have one.
4. Scope and what already exists: brand assets, systems, data, content and contracts that must stay.
5. Constraints: budget range, the deadline and its reason, regulation, security reviews, languages and markets.
6. How you will decide: who is involved, the steps with their dates and what you need in a response.

Give a budget range and a deadline

A range is enough. It lets each respondent propose the best work you can afford, instead of guessing and pricing too high or scoping too little. Deadlines work the same way: a launch tied to a trade show is a firm date. “As soon as possible” is not, and tends to buy the most expensive version of everything.

For an RFQ, publish the scoring

In a formal request for quotation or proposal, list the scoring criteria, their weights and how many respondents you will invite to present. You get comparable proposals and fewer clarifying questions.

Five common mistakes

• A solution written as the problem, so every proposal looks the same.
• Twenty “must-haves” in no order, so none of them gets priority.
• No measure of success, so nobody can tell whether it worked.
• Context held back until after selection, when it changes the scope.
• A deadline with no reason behind it, set before the work was understood.

A template you can copy

# Brief: <project name>

## The problem
What is happening, for whom, and what it costs today.

## The people
Who uses the result · who decides · who else is affected.

## Success
The 2–3 measures we will report, and today's baseline.

## Scope and what exists
In scope · out of scope · assets, systems and contracts that stay.

## Constraints
Budget range · deadline and why · compliance · languages and markets.

## Decision
Steps and dates · who decides · how responses are scored · what to send.

When you are ready, our brief form follows the same sections and takes attachments. You can also download the template as a text file first.