How to write a brief, or an RFQ, that gets you better proposals

The brief is the most leveraged document in any engagement. An hour spent making it clear saves weeks of proposals that answer different questions, and months of work that solves the wrong one. We read a great many briefs, and the good ones share the same 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, and sales spends the first call explaining it” is a problem, and it invites better answers. Design practice keeps the problem open before converging on a solution: the Design Council’s Double Diamond spends its whole first half discovering and defining it.¹ Government service teams do the same in a discovery phase before they commit to building anything.²

The sections that matter

1. The problem: what is happening, for whom, and what it costs today.
2. The people: who uses the result and who decides. Write their needs as needs: 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 real deadline and why, regulation, security reviews, languages and markets.
6. How you will decide: who is involved, the steps and dates, and what you need in a response.

Budget and time: say the number

A range is enough. It lets every respondent propose the best version of the work you can afford, instead of guessing and either pricing themselves out or under-scoping. The same goes for time. A launch tied to a trade show is a real date; “as soon as possible” is not, and it tends to buy the most expensive version of everything.

For an RFQ, publish the scoring

When the brief is a formal request for quotation or proposal, tell respondents how answers will be scored and with what weights, and how many will be invited to present. It produces comparable proposals and fewer clarifying questions.

The mistakes we see most

• A solution written as if it were the problem, so every proposal looks the same.
• Twenty “must-haves” in no order, so none of them is.
• 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 walks through the same sections and takes attachments, or you can download the template as a text file first.