How to write a design brief that gets you better work
Written by David • September 12, 2026
The quality of design work you get back is closely tied to the quality of the brief you send out. A vague brief produces guesswork, several rounds of revisions and a result nobody is quite happy with.
The good news is that a strong brief doesn’t have to be long. Two pages of clear thinking beats twenty pages of background.
Start with the problem, not the deliverable
The most common brief opens with “we need a new website”. That’s a solution, and it may be the right one, but leading with it closes off better answers.
Describe the situation instead. Enquiries have dropped. The team can’t update anything. You’re launching in a new market. You’ve merged with another organisation and have two identities. A good supplier will tell you whether a new website is the answer, and sometimes it isn’t.
What to include
Who you are. Short. What the organisation does, who it serves and anything unusual about how it works.
What’s prompting this. The trigger. Something has changed, or something isn’t working.
What success looks like. Be specific where you can. More enquiries, fewer support calls, a site the team can update themselves, a brand that works across three sub-organisations. If you have numbers, share them.
Who it’s for. The actual audiences, in order of importance. If everyone is your audience, nobody is.
What exists already. Current site, brand assets, guidelines, photography, content, systems you need to keep. Say what’s staying and what’s up for grabs.
Constraints. Technical requirements, accessibility standards, procurement rules, systems that must integrate, things you can’t change.
Budget. More on this below.
Timescales. Including the reason for them. “Before the new season opens in March” is far more useful than “as soon as possible”.
Who decides. Name the person who signs off, and anyone else who’ll need to be consulted. Getting this clear at the start prevents most late-stage upheaval.
Share the budget
The most common objection is that naming a budget means you’ll be charged all of it. In practice, withholding it wastes everyone’s time.
Design problems can be solved at many different levels of investment. Without a figure, a supplier is guessing which version of the project you want, and you’ll get proposals that are all differently wrong. A range is fine. So is “we’ve set aside around X, tell us what that buys.”
What to leave out
Prescribed solutions. Saying you want a slider, a particular font or a homepage laid out a certain way narrows the work before it starts. Describe what you need it to do instead.
Design by reference alone. Sharing sites you like is useful, but say *why* you like them. Otherwise you’ll get imitation without understanding.
Everything you’ve ever thought about. Long background documents bury the important points. Put the essentials in the brief and offer the rest as appendices.
The questions worth answering internally first
Before you send anything, make sure you can answer these:
- What will be different after this project that isn’t true now?
- Who has the final say?
- What’s genuinely fixed, and what’s open?
- What content do we have, and who is writing what’s missing?
- What happens to this after it launches, and who owns it?
That last one catches more projects out than any other. Plenty of good work is undermined by nobody being responsible for it six months later.
A brief is a starting point
Expect a good supplier to come back with questions, and to challenge parts of it. That’s a sign they’ve read it properly. The brief’s job is to get everyone to the same starting point, not to specify the answer.
