The website brief — six things an agency has to guess without

A brief has a reputation as a formality — a document to fill in before the real work starts. It is the opposite: the brief is the only part of a project where changing your mind is free. Everything missing from it gets guessed, and the guess only surfaces once fixing it costs dozens of times more.

Length is not the point. We have seen twenty-page briefs from which you could not tell why the site was being built, and one-page briefs you could start working from immediately.

Why write one if you will agree it all in conversation anyway

Because conversation leaves no trace, and the two sides' memories diverge in predictable ways.

Three things a brief does that a conversation does not:

It closes the list. While scope is spoken, every meeting can enlarge it — and usually does, because adding one thing sounds harmless. Written scope turns "let's also add" into "we are changing what we agreed", and that is a conversation both sides have deliberately.

It exposes disagreement inside your own company. The most common moment a brief pays for itself has nothing to do with the agency: it is when two people on your team read the same point and turn out to understand it differently. Better that it happens now.

It gives you a basis for comparing proposals. Three quotes from three different conversations cannot be compared. Three quotes from one document differ in what actually differs — the work and the rate.

Six things an agency has to guess without

What follows is not a list of fields to fill in, but six pieces of information and what happens when they are missing.

The business goal — what should happen. Not "a modern website", but: an enquiry through the form, a phone call, a booking. Missing: the agency designs a handsome template, because there is no other criterion — and you get a site that looks good and collects nothing. This is the most expensive omission of the six, because it only surfaces after several months.

The audience — who this speaks to. Somebody who knows the industry and is comparing suppliers needs something different from somebody meeting the subject for the first time. Missing: the copy gets written "for everyone", which means for nobody, and fixing it after launch means rewriting half the site.

The scope — how many pages and which. A list of sections, not a number. Missing: the quote prices something other than the project, and the gap surfaces halfway through the work, when changing scope is a renegotiation rather than a decision.

Integrations — what this has to talk to. The sales system, stock, invoicing, a booking calendar, the newsletter. Missing: this is the most treacherous item on the list. An integration priced up front is a line in a proposal; an integration discovered mid-build is work added to a project that already has a date and a budget — so both get renegotiated. On top of that, access to the system often belongs to somebody who has to be found first, and that is what stops the project, not the code.

Assets — what you supply and what you are buying. Copy, photographs, the logo in source files. Missing: the project reaches a state where everything is ready and waiting for photographs. The most common delay in the whole process and the only one a single sentence in the brief removes.

The budget — a range, not a figure. Missing: you get a quote that misses what you can actually spend — a proposal several times your ceiling, or, just as often, one far thinner than you were ready to buy. Both sides then lose a week to a conversation one sentence would have prevented. What quotes are built from and how billing models differ is the cost section's subject, not this one's.

What a brief does not need — and what actively hurts

Here is the most common client mistake, and it deserves its own paragraph because it looks like diligence.

Do not write solutions into the brief. "The site should be on WordPress with a blue enquiry button" looks like precision, and is in fact an instruction that removes the agency's ability to propose something faster or cheaper. If your goal can be reached with a static generator at a fraction of the price, and the brief has already settled the technology, nobody will suggest it — because it would look like questioning your decision.

A brief describes the problem and the goal. The solution is what you are paying for.

There is one exception and it is worth naming: if you have a genuine constraint — a team that knows only one system, a contract with a supplier, a legal department requirement — that is not imposing a solution, it is a boundary condition. Write it down together with the reason, because the reason is often negotiable and the requirement on its own is not.

Three things a brief does not need, and which regularly inflate it:

A colour palette and a typeface. That layer comes after the layout is agreed. It is enough to say whether a brand book exists and whether it is binding.

Inspiration as a list of websites. One or two make sense if you say what specifically you like about them. Ten links without commentary is a set of contradictory signals.

A detailed content architecture. Tempting, because it looks like work already done — but it belongs to the wireframe stage and comes out better after a conversation about goals. We cover it separately.

What to do when you do not know the answer

This is the real reason briefs do not get written — not lack of time, but questions you cannot yet answer. It is worth saying plainly that "I don't know" is a valid answer, provided it comes with one sentence about what you do not know.

You do not know who the audience is. Look in the inbox and the call history. The last five enquiries say more about your customers than an hour of thinking about a persona. Write down who asked, what they asked and how they found you — that is a finished answer.

You do not know what the goal is. Ask yourselves what you would want to happen in the week after launch. If the answer is "for somebody to call", that is a goal, and it is better than most goals written into briefs.

You do not know your budget. Invert the question: how much are you prepared to spend before you would consider it too much. That figure exists even when nobody has said it out loud, and the agency will learn it eventually — better at the start.

You do not know whether you need integrations. List the programs your company works in every day. If any of them holds data that should reach the site or come back from it, that is a candidate, even if you cannot say how it would work.

The overriding rule: a brief with five honest "I don't knows" is worth more than a brief with twenty invented answers. The first shows the agency what to ask about; the second steers the project in the wrong direction and nobody notices until handover.

Who on your side should write it

The question sounds trivial and decides whether the brief survives the project.

One person writes, several comment. A brief written by committee is a set of compromises in which every point carries somebody else's sentence and none of them binds. Let it come from one hand and let the rest of the team comment on it — those are two different activities, and mixing them costs a week.

Somebody among the reviewers has to be able to say no. The most expensive changes in projects come from the person who first saw the site just before handover and held a veto. If such a person exists in your company, their quarter of an hour now is worth more than their opinion at the end.

Ask whoever will maintain the site. The person who adds a post or corrects a price list every week knows requirements the board does not — for example, that the current system means phoning somebody for every change. That is a requirement and it belongs in the brief.

Name one contact for the duration of the project. Not because the rest have no say, but because contradictory comments from three people have to be resolved by the agency alone — and it will resolve them its own way.

Comparing three proposals against one brief

This is the practical return on the work, and it is worth knowing what to look at when the answers come back.

Check whether the proposal answers your brief or describes itself. A document setting out the agency's service packages rather than your project says the brief was not read. It is the one signal you can check in a minute, and it predicts the rest of the relationship unusually well.

Check what the agency asked back. No questions does not mean everything was clear — it means the gaps will be guessed. Three specific questions are a better signal than a quote ten per cent lower.

Compare scope, not totals. Two proposals that differ by a factor of two usually differ in what is inside: the number of pages, who writes the copy, whether testing is a separate line. Set those differences out in columns before you look at the sums.

Check what is excluded. The most important sentences in a quote start with "does not include". If there are no such sentences at all, it does not mean everything is covered — it means no boundary was set, and one will appear anyway, mid-project.

How to read the quote itself, and how billing models differ, we set out separately.

How we do it

On one implementation we built the brief differently from the usual approach, and the difference is worth describing — with a caveat that is part of the result: this is a demonstration site, not a client engagement.

Instead of a list of questions, we produced a document in which every question carries two extra layers: "why we are asking" and "what a good answer looks like".

The difference is larger than it sounds. "Who is your target audience" gets filled in reflexively and usually badly, because the answer is "small and medium businesses". The same question with "we ask because it decides whether the site should explain the problem first or go straight to the scope of the service" gets an answer you can work from. And the note "a good answer names one situation in which a client comes to you" turns a generality into something concrete.

That same project had one more section, one that is usually absent and turned out to be unskippable: professional and legal constraints. In that case it was professional ethics — no superlatives, no comparisons, no promises of outcome. That is not a matter of style; it is a condition that shaped how the entire content was built, and had it surfaced during visual design, the whole site would have been rewritten.

The conclusion we take into every brief since: ask the agency what you are not allowed to write. Regulated industries — law, medicine, finance, insurance — have constraints like this, and they belong in the brief, not in proofreading.

You do not have to write this in a text file

A brief does not have to be built from scratch, and that is where most people stop — not at the missing answers, but at the blank page.

We built an [interactive brief builder](/brief) that walks through the same questions step by step: from the goal and the scope, through the audience and the customer journey, to technical requirements, integrations and accessibility. It saves your progress, so you can fill it in over several sittings, and at the end it leaves you a finished document — to send to us or to any other agency. It is free and needs no account.

The builder also does two things an empty document will not: it asks about matters nobody usually remembers — accessibility, consents, who actually holds access to the domain panel — and it does not let a field stay blank without a decision, because "I don't know" is a separate answer there rather than the absence of one.

If you would rather start with a conversation, that is also a valid order — the brief can be written up afterwards, together.

Where these numbers come from

• The budget mismatch example is an illustration of the gap between expectation and quote, not a market range and not our price list. Actual ranges, with sources and observation counts, are in the cost section.
• The brief structure with "why we ask" layers comes from one of our own implementations, described in the portfolio as a demonstration site. One implementation is one implementation, and that is how we present it here.
• What is not here: the previous version of this text claimed that a good brief saves 30–50% of budget, that projects without one overrun by 50–100%, and that a site based on a brief is 70% more likely to meet its goals. None of those figures had a source, so they were removed rather than corrected.