How to Write a Web Design Brief That Gets You Exactly What You Want

Why most briefs don't work

The most common web project problems — scope creep, misaligned expectations, endless revision cycles, and deliverables that miss the mark — almost always trace back to an inadequate brief. Not because the client didn't try to explain what they wanted, but because they explained it in terms of what they wanted to see, rather than what they needed to achieve.

A design brief is not a wish list. It is a business document that answers four questions: What problem are we solving? Who are we solving it for? What does success look like? What are the constraints? Every other piece of information in a brief is supporting context.

Section 1: Business context

Before any design team can make good decisions, they need to understand your business well enough to make judgement calls on your behalf. This section should cover: what your business does and who your primary customers are, what your current website does and doesn't do, what has prompted the need for a new website now, and who the key decision-maker is for this project.

Most briefs skip the "why now?" question, and it's one of the most valuable ones. A company that needs a new website because they're about to raise a Series A has different constraints and priorities than one that needs it because their existing site was built by a freelancer six years ago and is breaking.

Section 2: Target audience

Be specific. "B2B decision-makers" is not a useful audience definition. "Head of Marketing at B2B SaaS companies with 50–250 employees, who is evaluating design agencies for a website redesign with a budget of £20k–£50k" is. The more specific the audience definition, the more targeted the design team can be in every decision they make about tone, content, and hierarchy.

Section 3: Goals and success metrics

What does a successful outcome look like, and how will it be measured? "A better website" is not a success metric. "A 30% increase in contact form submissions within 90 days of launch" is. "More leads" is not measurable. "Moving from 2 to 5 qualified leads per week from organic traffic within six months" is.

Defining success metrics before the project starts does two things: it aligns the design team with business outcomes rather than aesthetic preferences, and it gives everyone a clear framework for evaluating whether any given design decision moves toward or away from the goal.

Section 4: Scope and deliverables

List every page or section that is in scope. Include the content hierarchy for each page if you have it. Specify what you're providing (copy, imagery, existing brand assets) and what the agency is responsible for. Ambiguity here is where scope creep enters. If you're not sure whether something is in scope, it should be explicitly listed as either in or out — not left undefined.

Section 5: Constraints

Budget range (even a rough range helps agencies scope accurately), timeline (especially any hard deadlines and the reason for them), technical constraints (existing CMS, integrations required, hosting requirements), and any brand or legal constraints that affect the design. A brief without constraints is a blank cheque — it invites proposals that don't match reality.

What not to put in a brief

Avoid specifying design decisions in the brief — "I want a blue header with a large hero image and three columns below the fold." This reduces the design team to pixel-pushers rather than strategic partners. Brief the outcome, not the solution. "The homepage should immediately communicate our premium positioning to first-time visitors" is a more useful brief than a pixel-by-pixel description of what you think that should look like.