How to Write a Website Brief That Gets Better Results

A website brief is the context package you bring into a project — not a miniature design document. Its job is to help the team understand why the work exists, who it serves, what must improve, and what constraints are real. A brief that already “solves” the site usually locks bad assumptions in before anyone has checked them.

Discovery turns that input into a plan. A proposal turns the plan into a commitment. Keep those jobs separate: this article is about what to bring, not how an agency runs workshops or what belongs in a signed scope. Earlier still — before a formal brief — is what to prepare for a first agency conversation.

Why the project is happening

Start with the business reason. What changed — competition, sales process, product mix, brand, hiring, a broken handoff from marketing to sales? What problem exists today that a better website should reduce?

“We need a redesign” is a tactic, not a brief. “Inbound leads stall because visitors cannot tell what we sell or how to start” is a problem. The clearer the problem, the less time everyone spends arguing about aesthetics that do not move the commercial outcome.

Who the site is for

Name the audiences that matter commercially, not every possible visitor. For each, what are they trying to understand or do: evaluate fit, compare options, book a call, request a quote, recruit, self-serve?

If two audiences need different paths (buyers vs partners vs candidates), say so. Vague “everyone” briefs produce homepage compromises that serve nobody well.

What success looks like commercially

Be explicit about the job of the site: lead generation, sales support, booking, evaluation, recruiting, education, self-service — or a ranked mix. “More modern” is not a goal. “Fewer unqualified inquiries and clearer routing into CRM” is.

If you have a baseline (inquiry volume, close rate, bounce on key pages, sales complaints), include it. Numbers do not need to be perfect; they need to be honest enough to judge later whether the project worked.

What the current site should teach

List what works, what fails, and what must survive. Surviving assets often include strong case studies, useful service explanations, ranking URLs, forms that already route correctly, or content that sales already trusts.

Also note political landmines early: pages a founder loves that analytics show nobody uses, or a navigation structure that only makes sense internally. Discovery will pressure-test these; the brief should not hide them.

Content reality

State what content exists, what needs creation, and who owns it. Content delay is one of the most common timeline killers. If subject-matter experts are unavailable until “later,” say that now — it changes scope and sequencing more than most design debates do.

Technical and system requirements

Capture the non-negotiables: CMS preference or constraint, hosting, forms, CRM, analytics, booking tools, access requirements, accessibility expectations, multilingual needs. Distinguish must-haves from nice-to-haves. An integration wishlist without owners is not a requirement — it is a risk list.

SEO and migration context

If the site already has organic visibility, name important URLs, known ranking themes, and whether a rebuild will change domains or URL patterns. Migration is not a footnote. Teams that skip this section often discover SEO emergencies in launch week.

If the site is new, say what discovery demand you already know about — even if that knowledge is incomplete.

Who decides

Name who approves creative direction, who provides content, who owns technical access, and who can say yes to scope changes. Ambiguous stakeholders produce late reversals. One decision owner with named contributors beats a committee that “all need to be happy.”

A useful length, not a novel

One to three pages of honest context beats a 40-page brief that restates the brand book. If a section is unknown, write “unknown — needs discovery” instead of inventing certainty. Empty confidence is worse than a named gap.

Include links to analytics access, CRM examples of good and bad leads, competitor sites that win for the wrong reasons, and any legal or brand constraints that actually bind decisions. Those artifacts save more time than adjective-heavy brand language.

What a brief should not do

It should not specify exact layouts, colour systems, or component inventories as if discovery were optional. Inspiration links are useful; instructions that freeze the answer before the problem is understood are not.

It should not pretend every stakeholder already agrees. If marketing wants lead volume and sales wants fewer weak inquiries, put that tension in writing. Discovery can resolve it; a silent conflict will resurface as revision theatre.

How this connects to what comes next

The brief is the package you hand over. Discovery pressure-tests it against evidence and produces decisions. The proposal commits to scope, roles, money and change control. Choosing an agency is a separate evaluation of process and fit — not a substitute for writing down what you already know.

A strong brief gives context. A weak brief tries to design the website in a PDF. Bring enough for web design or website redesign work to start honestly — then let discovery interpret it before anyone commits to a proposal.