What to leave out of a project brief

What a brief is for, and what it is not

A brief is the document that lets a studio understand the job without sitting in your head. It is not a specification, a design, or a shopping list. It says what is wrong, for whom, what exists already, and what cannot change. The studio's work is to propose what to build in response, and a brief that has already decided that leaves nothing to propose.

We have written about the sections a brief needs elsewhere, in the website brief resource, which is the public version of the template we send to clients. This piece is about the other half: the judgement that a template cannot hold. What to leave out, how to say what you want without saying how to build it, and the mistakes that make a brief cost more than it saves.

It helps to know how ours is used. Our project brief is written by us, after the first conversations, and sent back to the client. It opens by saying that it is what we understood, and that if any of it is wrong, ten minutes now is cheaper than a rebuild later. Confirming it starts the work, and every later document refers back to it. So when you write yours before talking to a studio, you are writing the first draft of that thing. Expect it to be corrected.

A brief that is allowed to be wrong in the right places is more useful than one that is falsely certain. Our delivery process starts with discovery, which looks for the real goal rather than the brief's first guess at it. Write what you know, mark what you are unsure of, and do not dress a guess as a requirement.

Describe the problem, not the solution

This is the central discipline, and the most common failure. The UK Government Digital Service puts it in one line in its service manual guidance on user needs: focus on the user's problem rather than possible solutions, for example needing a reminder rather than needing an email or letter. The reasoning is that the first form leaves the best answer open, and the second may rule it out. The email might be the wrong channel for the people involved. You will not find out if the brief has already said email.

The same guidance suggests a plain shape for a need: who has it, what they need to do, and why. It is a good test for any line in a brief. If it names a feature, ask what the feature is for, and write that instead.

Instead of	Write	What it leaves open
We need a booking calendar on the home page.	People phone to book, and we lose bookings when nobody answers. We want them to book without calling, at any hour.	Whether that is a calendar, a form, a messaging link or something else
Add a blog and a news section.	Customers ask the same six questions before they buy, and we answer them one at a time by message.	Whether the answer is articles, a help section, or a better product page
It should look like this competitor's site.	Our customers should trust us as quickly as they trust the larger names in the market.	What actually builds trust for your audience, which may not be that site's look
Build it in a particular platform.	Our team must be able to edit prices and pages without a developer.	Which tool achieves that, and whether the platform you named does

Solution-shaped lines, and the problem each one is hiding. The examples are invented for illustration.

Notice what changed in every row. The right-hand wording tells the studio what is wrong and how you would recognise it fixed. It does not take any of the studio's decisions away, and a good studio will often come back with something better than what you first named.

Goals, audience, content and constraints, one at a time

Four parts of a brief are where solution-thinking creeps in. Each can be written without it.

Goals. Write the outcome and how you would know. One primary goal, in a sentence, and then at most a few secondary ones in order. A goal that cannot be checked months later, like looking modern, is a feeling, and our own brief template asks for success criteria that are measured at the end rather than against how the work felt.
Audience. Describe a specific person and what they came to do, not an age bracket. Include what they do today instead, because that is the thing your site competes with: a phone call, a marketplace listing, a competitor, a spreadsheet. You are describing behaviour, not a layout.
Content. Say what exists, where it lives, who owns it, and what is missing. Do not say how it should be arranged. The practical risk is almost never the design; it is that nobody has written the words or taken the photographs. Name who will supply each piece and by when, and what you want the studio to help write. If content is coming from you, that is a dependency with a date.
Constraints. List what is fixed, and be strict about it. A constraint is something that costs you if broken: a launch date tied to a real event, a system the site must keep working with, a legal or brand rule. A preference is something you would like. Mixing them is how a negotiable colour ends up weighted the same as a fixed integration.

If you are unsure whether something is a constraint, test it by asking what happens if it is not met. If the answer is that you would be disappointed, it is a preference. Preferences are welcome in a brief, in their own labelled place, because a studio can then trade them against each other.

What to leave out

Cutting is half of writing a brief. These are the things that most often go in and should not, and why.

Page layouts and wireframes. Drawn before the problem is understood, they become the answer by default. If you have a sketch that explains the problem better than words, include it as an example of the problem and say that it is not a requirement.
Feature lists with no reason attached. Each feature should carry the need behind it, or be cut. A list of twenty features with no reasons is a menu, and a studio can only price it, not improve it.
Technology choices that are not constraints. Naming a platform, framework or hosting product because someone recommended it removes options silently. State what the site must do and what it must connect to, and let the studio explain what fits. If a choice is a real constraint, such as an existing system you must use, say so and say why.
Detailed visual taste. Keep brand rules that are fixed: logo, colours already in use, a required typeface. Leave out adjectives. Words like clean, bold and premium describe five different sites to five different people.
Competitor sites with no explanation. A list of links says what you like and nothing about why. If you include examples, write one line each on what you admire and what you do not want to copy.
Internal politics and history that do not affect the work. Do include who decides, and any disagreement that will have to be settled before work starts, because that is a dependency. Leave out the backstory that does not change what gets built.
Numbers you cannot stand behind. Traffic figures, conversion rates and target improvements pasted from memory send the studio towards the wrong goal. Say where each figure came from, or leave it out.

Our own template has no budget section, and no price in it anywhere. Money is a conversation we have directly, and the brief is the description of the work that makes that conversation concrete. Whether to share a budget with a studio is a separate decision, and this piece takes no position on it.

A worked example: the same brief, rewritten

Invented for illustration. This is not a client, and it is not taken from any client's brief. It shows the pattern.

A founder who runs a small physiotherapy clinic writes: We need a new website with a modern look, a booking calendar, a blog, WhatsApp chat and a gallery. Make it like the big hospital sites. Build it on a popular builder. We want it in six weeks.

Every item there is a solution. A studio can quote it, but cannot tell whether it fixes anything. A rewrite that keeps every fact and removes the decisions might read as follows.

The business. A physiotherapy clinic with two practitioners. Income comes from booked sessions, most of them repeat visits.
The problem. New patients find us through search and referrals, but most first contacts are phone calls during working hours, and calls we miss are usually lost. Existing patients ask the front desk to rebook by message.
The audience. Adults with a recent injury or ongoing pain, searching on a phone, often in the evening. They want to know whether we treat their problem and how soon they can be seen.
What success looks like. A new patient can request a first appointment outside working hours without calling. The front desk spends less of the day rebooking. We can tell, from the enquiries themselves, which treatments people asked about.
Content. We have a short description of each treatment, two practitioner biographies, and photographs of the clinic. We do not have patient stories, and we would like help deciding what we can honestly say.
Constraints. A launch date tied to the opening of a second room. Our existing appointment software has to keep working. We cannot publish anything that implies a medical outcome.
Who decides. One of the two practitioners, named.
Preferences, not requirements. We like the calm feel of some larger clinic sites. WhatsApp contact is how most patients prefer to reach us.

The studio can now say a calendar is the wrong answer if the existing software already takes bookings, or that a form feeding it is a better fit than a new one. It can ask how much of the content is genuinely available. The six weeks became a real constraint, with a reason, instead of a number. None of that was possible from the first version.

The mistakes we see most

Mistake	What it does	The fix
Writing the solution	Removes the studio's best contribution and hides the real problem	Rewrite each line as the problem it solves
No named decision maker	Feedback arrives from several people and nobody can say yes	Name one person with the authority to approve
Success defined as a feeling	The work is judged on taste at the end	Write something checkable, before seeing any designs
Content treated as a later problem	The project stalls waiting for copy and photographs	List what exists, who supplies the rest, and by when
Fixed things not mentioned	An existing system or date surfaces late and is handled as an emergency	List constraints separately from preferences
Sending a different brief to each studio	Replies cannot be compared	Send one brief, unchanged, to everyone
Treating the brief as final	Wrong assumptions harden into the plan	Mark uncertainty, and expect questions back

From our own experience of reading briefs. We have not counted them, so there is no frequency here.

A check before you send it

Pick any line. Does it say what is wrong, or how to fix it? If the latter, rewrite it.
Could someone who has never met you say who the site is for and what they came to do?
Is every success criterion something you could check in six months?
For each piece of content, is there a name and a date next to it?
Is every constraint something that would cost you if broken, rather than something you would merely like?
Is there exactly one name under who decides?
Have you marked what you are unsure of?

If it passes, send it. The best sign that you have written a useful one is that the studio comes back with questions you had not thought to ask, and some of the answers change the brief.

What this does not cover

This is our practice, not a standard. Other studios ask for different things, and a good one will want more than any template covers.
The worked example is invented. It shows a pattern, and it is not a client, a result or evidence that the rewritten version produces a better outcome.
The mistakes table comes from our experience of reading briefs. We have not counted them or compared outcomes, and give no frequencies.
It covers websites and web applications. A brief for a brand identity, a campaign or a physical product needs different sections.
It says nothing about what a project should cost or how long it should take, and takes no position on whether to share a budget with a studio.
The guidance on separating needs from solutions is from the UK government's user research guidance for public services. We apply the idea to private business projects, and the source does not address them.
A brief is not a contract and creates no obligation on anyone. The terms of an engagement are a separate document, and we are not lawyers.

Sources

Start by learning user needs, GOV.UK Service Manual (Government Digital Service). Retrieved 4 October 2026.
What Scene project brief template, documents/transactional/project-brief, and the delivery process in lib/content/process.ts. Read in full on the batch 8 worktree. The piece describes what the template asks for and how the brief is used (written by us after the first conversations, sent back for correction, confirmed before work starts), and does not quote the template. The template holds placeholders only, no client values. Run: documents/transactional/project-brief version 2026.1, read 2026-10-04.
whatscene.in Search Console export, 28 days to 2026-08-23. Query-level impressions for the phrasings behind this piece, read from the committed export in data/search-console/. Run: data/search-console/2026-08-25-performance-28d.zip.

Revisions

4 October 2026 First published, as the companion to the website brief resource: what to leave out and how to write goals, audience, content and constraints without designing the solution.

This page is revised in place rather than replaced, so its address does not change.