How to Write a Website Brief: Structure, Template, and the Sections People Skip
A website brief exists to answer one question before work starts: what does "finished" mean? Projects that overrun almost never do so because the work was harder than expected. They overrun because that question was never settled, and every ambiguity gets resolved mid-build, expensively.
Below is a section-by-section structure you can copy. It takes an afternoon to fill in properly, and it will save you weeks. For remote production teams, a related reference is this resource, which looks at how activity signals should be interpreted.
1. Business context
Two or three paragraphs. What the company does, who it sells to, how it makes money, and where it is going.
Agencies read this to understand whether your priorities are credibility, conversion, or scale. A law firm and a subscription app need opposite things from the same budget, and the brief should make it obvious which you are.
2. Objectives
What the site is for, stated as outcomes rather than features. Performance requirements can be checked against the web.dev Core Web Vitals guidance.
Weak: "a modern, responsive website." Useful: "generate at least 40 qualified enquiries a month, and let the sales team send prospects a page that answers their objections without a call."
Rank them. Every project reaches a point where two goals conflict and someone has to decide which wins. Better that you decide now than that a developer decides for you at 6pm on a deadline.
3. Audience
Who visits, what they arrive wanting, and what stops them.
If you have analytics from an existing site, include the real numbers: device split, top entry pages, where people leave. Actual data changes design decisions more than persona documents do.
4. Scope
The section that determines whether your quotes are comparable. Security reviews should also account for the OWASP Top 10.
Page inventory. List every page or template. Not "an about section" — the specific pages. If you have twelve service pages that share a layout, say so: that is one template, not twelve builds.
Functionality. Every interactive element: forms, search, filtering, booking, payment, accounts, calculators, multi-step flows. Each of these is a discrete piece of work.
Integrations. CRM, email platform, analytics, payment gateway, ERP, live chat. Name the specific products. "CRM integration" can mean an afternoon or a month depending on which CRM.
Languages. If the site needs more than one language, state it here. It affects URL structure, layout, content workflow, and the CMS — see section 9.
Content. Who writes it, who supplies photography, and whether existing content is being migrated. Content is the single most common cause of delay in website projects, and briefs routinely leave it unassigned.
5. Technical requirements
CMS preference and why. Hosting arrangements. Performance expectations. Accessibility level. Browser and device support. Security or compliance obligations. Whether the site must be editable by non-technical staff, and how often.
If you have no preference, say so — that is a legitimate answer and better than inventing a requirement you cannot justify.
6. Design direction
Existing brand assets: logo, palette, typography, guidelines. Whether those are fixed or open to revision.
Three to five reference sites, each with a sentence on what specifically you like about it. "This one, for the way the pricing table explains tiers without a wall of text" is useful. "This one, it's clean" is not.
Include what you dislike, with the same specificity. Negative references narrow the field faster than positive ones.
7. Budget
Give a range. Withholding it does not get you a better price; it gets you proposals scoped for the wrong project and several wasted meetings.
A range lets an agency tell you honestly whether your scope fits, and propose a phased approach if it does not. Both outcomes are better than discovering the mismatch three weeks in.
8. Timeline
Launch date and any fixed constraint behind it — a trade show, a funding announcement, a lease starting. Real deadlines get planned around; arbitrary ones get quietly ignored.
Include your own availability for reviews. A two-week feedback cycle on your side extends the project by two weeks, and it is fairer to everyone if that is visible in the plan.
9. The sections most briefs skip
Migration and redirects. If you have an existing site with traffic, every URL that changes needs a 301 redirect to its replacement. Without this, you lose the search rankings you already have — sometimes permanently. Ask for a redirect map as an explicit deliverable, and require the old site to be crawled before it is switched off.
Analytics and tracking. Which events matter, what counts as a conversion, who has access to the dashboards. Sites launch without measurement more often than you would think, and then nobody can say whether the rebuild worked.
Multilingual mechanics. More than one language is not a translation task. Specify URL structure, hreflang handling, how language switching works, which language is the default for a first-time visitor, and who maintains parity between versions as content changes.
Handover. What you receive at the end: source code, repository access, hosting credentials, design files, documentation, training. And who owns them. State that ownership transfers on final payment, in the brief, before anyone quotes.
Post-launch. Warranty period for bugs. Ongoing support terms and rates. What happens when you need a change in month four. Most disputes in web projects happen after launch, over things nobody wrote down.
10. Evaluation criteria
Tell people how you will choose. Price, portfolio relevance, timeline, team composition, communication style — in order.
It sounds bureaucratic. In practice it improves the proposals you receive, because agencies address what you actually care about instead of guessing.
A note on length
A good brief for a small business site runs four to eight pages. Longer than that and it usually contains material that belongs in a specification written after the discovery phase, not before.
The goal is not to pre-decide the solution. It is to define the problem precisely enough that different people can propose different solutions to the same thing — which is the only way comparing quotes means anything.
Before you send it
- [ ] Could someone outside your company understand what the business does from section 1?
- [ ] Are objectives stated as outcomes, not features?
- [ ] Does the scope list every page template and every interactive element?
- [ ] Is content ownership assigned to a named person with a date?
- [ ] Is a budget range included?
- [ ] Are migration, redirects, and analytics explicitly in scope?
- [ ] Is handover and ownership stated in writing?
- [ ] Have the people who will approve the final site read it?
That last one is the one that bites. A brief signed off by marketing and discovered by the managing director at the design review costs more than every other item on this list combined.
Нужна помощь с брифом или готовы обсудить проект? Услуги веб-дизайна и разработки приложений. .