The brief is the most important document in a web design project. It sets the frame for every decision that follows. When the brief is good, the project tends to go well. When the brief is vague, you spend the design process discovering what the client actually wanted.
Most people who commission websites don’t write briefs for a living. But there are structural differences between briefs that help and briefs that don’t, and they’re worth knowing.
The most common mistake: describing the output instead of the problem
A brief that says “we need a five-page website with a homepage, services page, about page, blog, and contact form” is describing what should be built. It doesn’t tell a designer anything about why, for whom, or what success looks like.
The same brief written from a problem perspective might say: “We’ve been running the business for three years through referrals. When referred prospects go to check us out, our site doesn’t match the quality of the work we do, and we lose deals we should be winning. We need a site that works for someone who’s been referred to us and is doing due diligence.”
These two briefs will produce different sites. The second one gives the designer something to design for: a specific person with a specific job to do.
What a useful brief actually contains
The problem you’re trying to solve
What’s wrong with the current situation? Why is this site being built or rebuilt now? If there’s no existing site, what gap does the new one fill?
Who the site is for
Not “our target audience” in the abstract. One specific person: what do they know when they arrive, what are they trying to figure out, what would make them take an action. “B2B decision-makers in the SaaS space” doesn’t help a designer. “A head of marketing at a 25-person software company who has been referred to us by a colleague and is checking whether we can handle a project of their scale” does.
What success looks like
How will you know if the site is working? More enquiries from qualified leads? Fewer support calls from people who couldn’t find what they were looking for? These are measurable, and they tell a designer what to optimise for.
What you don’t want
Negative constraints are often more useful than positive ones. “We don’t want to look like a large agency” is clearer than “we want to look boutique.” “We don’t want stock photography of people in offices” is actionable.
What you have and what you need
Do you have a brand identity or does one need to be developed? Do you have copy or does it need to be written? These aren’t secondary questions — they have a significant effect on scope, cost, and timeline.
What to do with constraints you can’t articulate
Sometimes you know something’s wrong but can’t fully describe it. That’s fine. “The site doesn’t feel right but I can’t say exactly why” is a legitimate starting point. In those cases, describe what you’re seeing behaviourally: “People who come from ads seem to leave quickly.” “We get compliments on the site but always from other designers, not clients.”
A note on scope and budget
Including a budget in a brief is one of the things clients are most reluctant to do, usually because they’re worried it will anchor the quote upward. The opposite tends to be true. Without a budget, a designer doesn’t know whether to propose a simple landing page or a multi-section custom build.
Saying “we have around €5,000 for this” doesn’t commit you to spending €5,000. It gives the designer the information they need to propose something realistic.
The brief is not a legal document. It’s a starting point for a conversation. The goal is to give the designer enough to understand your situation — not to specify every detail of the solution, which is the designer’s job.