Project brief

A brief describes the problem and the goal. It is not a contract and it does not list every task; that is the job of the scope of work. A good brief fits on one to three pages and can be read in five minutes by anyone joining the project.

The test of a brief is whether two different suppliers reading it would propose roughly the same kind of solution. If the brief says only "a modern website that converts", they will not, because it leaves every important decision open.

How it works

The brief is usually written by the client, by the supplier after a discovery phase, or by both together. It typically covers background on the business, the goal in measurable terms, the target audience, the main pages or features, content and assets already available, technical constraints, budget range, deadline and who has final say.

Once agreed, the brief becomes the reference point for decisions. When a new idea comes up mid-project, the team checks it against the brief's goal before adding it.

A brief also records what is deliberately left out. "No online shop in this phase" or "no new logo" stops later debates before they start. Many briefs end with a short list of open questions, so both sides can see which decisions are still pending and who will make them. Briefs work best when they separate needs from preferences. "Customers must be able to request a quote from a phone in under a minute" is a need that can be tested. "We like dark green" is a preference that design can respond to. Mixing the two makes every colour choice feel like a requirement and hides the few things that genuinely decide whether the project succeeds. Marking each line as "must", "should" or "nice to have" is a simple way to make the difference visible to everyone reading.

Example

A landscaping company's brief says: the goal is more enquiries for garden design in three nearby towns; the audience is homeowners aged roughly 35 to 65; the site needs a gallery of finished projects, a service page per offering and a quote form; photos exist but need sorting; the owner approves all copy; launch before spring. That is enough for a designer to start and for anyone to see later whether the result meets it.

When the landscaper sends this brief to three studios, the quotes arrive in a similar range and describe similar sites, which makes the choice a question of quality and fit rather than guesswork. Midway through, the owner's brother suggests adding an online shop for garden tools. The team checks the brief: the goal is design enquiries, so the shop goes on a list for later.

Why it matters for your business

A clear brief gets you comparable quotes, fewer revision rounds and a project that solves the problem you actually have. It also limits scope creep, because there is a written goal to measure new requests against. Writing one costs a few hours of thinking. The trade-off is that a brief can be too rigid: if you are exploring a new product, keep it focused on the problem and the audience rather than dictating features. A quick test before you send it: give the brief to someone outside the business and ask them to describe the site they would expect. If their answer matches yours, the brief is clear enough.

Common mistakes

• Describing a solution ("we need an app") instead of the problem it should solve.
• Leaving out the budget range, so suppliers propose work at wildly different scales.
• Naming no single decision-maker, which leads to conflicting feedback from several people.
• Setting goals that cannot be measured, such as "look more professional", with no link to a KPI.

Questions people ask

What should a website project brief include?

Include the business background, the goal in measurable terms, the target audience, the pages or features you expect, content you already have, technical limits, a budget range, a deadline and who approves the work. Examples of sites you like and dislike, with reasons, also help.

Who writes the project brief, the client or the agency?

Either can. Clients often write a first version, and the agency refines it after asking questions. What matters is that both sides agree on the final text before design starts, so it can settle disagreements later.

What is the difference between a project brief and a scope of work?

The brief explains why the project exists and what success looks like. The scope of work lists exactly what will be delivered, when and for how much. The brief usually comes first and shapes the scope.