Email three web design providers “we need a new website, can you quote?” and you will get three proposals for three different projects. One prices a five-page refresh, one a custom build connected to your CRM, one a strategy workshop. None of them is wrong, and none can be compared. A website brief fixes that.
A brief, also called a web design brief, is a short document that describes your business, what the website must achieve, who it is for and what it must do, so every provider prices the same job. Writing it also forces a useful conversation inside your organisation before anyone’s meter is running.
The short answer
A good website brief describes problems and outcomes rather than solutions, and covers ten things:
- Background: who you are and why you need a new site now.
- Goals and KPIs: what the site must achieve, and how you’ll measure it.
- Audiences: who visits, and what they need to know.
- Key visitor actions: the one to three things visitors should do.
- Features and integrations: forms, booking, CRM and other must-haves.
- Content and languages: who writes it, in the languages your customers use.
- What to keep: what still works on your current site.
- Budget range: a realistic range, and what it covers.
- Decision-makers: who approves, and how you’ll choose.
- Deadlines: the dates that genuinely matter, and why.
A few pages is usually enough. Precision matters more than length.
What a website brief is for, and what it isn’t
A brief has three jobs: it gets you proposals you can compare like for like, it makes your team agree on priorities before money is spent, and it becomes the reference for decisions once the project starts.
It is not a finished specification. You don’t need a sitemap, wireframes or a list of every button. Working those out is the provider’s job, usually in a discovery phase, and a brief that tries to do it for them often locks in the wrong answers.
Nor does it replace knowing what the website is for. If your team can’t agree on who the site serves, settle that with a website strategy first, then write the brief from it.
Describe problems, not solutions
This is the biggest improvement most briefs can make. Prescribe a solution and every provider quotes it, so you learn nothing about how they think. Describe the problem and each proposes their best answer, and the differences start to tell you something.
| Instead of prescribing | Describe the problem |
|---|---|
| “We need a chatbot.” | “Visitors ask the same few questions before booking, and reception answers them by phone all day.” |
| “Make it modern, like Competitor X.” | “Next to Competitor X, we look smaller and less established than we are.” |
| “We need SEO.” | “People find us when they search our name, but not our services.” |
| “Use a page builder.” | “Marketing can’t update a price without paying a developer.” |
Real constraints do belong in the brief. If your sales team lives in a particular CRM, IT requires a specific hosting set-up, or you have legal obligations around accessibility or data protection, label them as constraints. Mark preferences (“we’d like to stay on WordPress”) as preferences, so providers know which is which.
What to include in a website brief, section by section
1. Background and why now
Briefly: what the organisation does, who it sells to, and how the current website fits in. Then the most important line in the brief: why now. A rebrand, a new service line, a merger, a site that breaks on phones, a sales team that no longer sends people to it. The trigger tells a provider what the project is about.
2. Goals and KPIs
Pick two or three goals, ranked, and write each as an outcome rather than an activity. “More qualified enquiries from overseas buyers” is a goal. “A new homepage” is not.
For each, say how you will measure it (tracked form submissions, calls, bookings, quote requests) and include today’s numbers if you have them. If you don’t, write “we don’t know”: it tells providers that setting up tracking belongs in the scope. Not sure which numbers matter? See which website KPIs are worth tracking.
3. Audiences
List your main audiences in order of importance, and what each needs to know before it will contact you. Ask sales or customer service for the questions they answer every week. Add how each audience usually arrives and the languages it uses. Include job applicants, investors or distributors only if the site has to serve them.
4. Key visitor actions
When visitors are ready, what should they do: request a quote, book a visit, call? Name the one to three actions that matter most, then describe what happens next today: where does a form submission go, and who replies? A polished form that feeds an inbox nobody checks is an expensive failure.
5. Must-have features and integrations
Sort features into three lists: must have, nice to have, and not needed. The third list saves more money than you would expect.
For every integration, name the system and what should move where: “web enquiries create a lead in our CRM, tagged by product”. (See how website integrations work for the common options.) Then add the requirements nobody sees but everyone depends on:
- Accessibility. If you have obligations, name the standard and level that your policy or the law refers to (some laws still cite WCAG 2.1). Otherwise, WCAG 2.2 level AA, the current W3C version, is a sensible target.
- Privacy. Consent requirements for forms, cookies and analytics.
- Hosting and security. Who hosts the site, and the IT policies it must meet.
- Speed and search. Spell out what you expect, such as meeting Google’s Core Web Vitals thresholds on mobile. “SEO included” means very different things to different providers; see what a new website’s SEO should cover.
6. Content and languages
Content is where many projects slip, so be honest. Roughly how many pages? What is usable, what needs rewriting, and who writes the rest? Do you have photos of your own people and projects, or need a shoot?
List the languages your customers use. For each, say whether it needs the full site with its own search optimisation or just key pages, and who translates. Our guides to preparing website content and planning a multilingual website go deeper.
7. What to keep from the current site
A redesign shouldn’t throw away what works. Note:
- Pages that bring in traffic and enquiries, so they are kept or redirected. The Pages tab of Search Console’s Performance report shows search traffic by page; your analytics shows enquiries.
- Content, case studies, downloads and images worth carrying over.
- Brand assets, the domain and email, and anything connected to the site.
- What people like about the current site, not only what they dislike.
Say who holds the logins for the domain, hosting and analytics. Search Console and Google Analytics can both give shortlisted providers view-only access, which you can remove later.
8. Budget range
Many businesses leave the budget out to see who comes in cheapest. Often one provider quotes the minimum that could work, another the ideal, and the two can’t be compared. A range lets everyone propose the best site they can deliver within it, and quickly shows who is the wrong fit.
Say what the range covers: the build alone, or also content, photography, translation, hosting, licences and the first year of maintenance. For a reference point, look at published packages such as those on our pricing page, and at why quotes for the same website vary so much.
9. Decision-makers and how you’ll decide
Name the day-to-day contact, the people who give feedback, and the one person who signs off. List every approval the project needs, such as brand, legal, IT or the board, because each one adds time and should be planned for rather than discovered.
Then say how and when you will choose. Sharing your criteria (relevant experience, approach, ownership terms, price, support after launch) gets you proposals that address them directly.
10. Deadlines that genuinely matter
Separate hard deadlines from preferences, and give the reason behind each hard one. “Live before the trade fair in March, because our printed catalogue points to the new pages” is a deadline a provider can plan around. “As soon as possible” is not.
Mention when your approvers are away, too. Then let providers propose the timeline: a realistic plan, phased if a hard date requires it, shows someone has read your brief properly. For the stages and roles between brief and launch, see how to plan a website project.
A website brief template you can copy
Paste this into a document and fill it in. Where you don’t know an answer, write “not sure yet”: that tells providers where discovery needs to focus.
WEBSITE BRIEF: [Organisation name]
Date:
Contact: [name, role, email]
1. BACKGROUND
- What we do, for whom, and where:
- Our current website in one sentence:
- Why we need a new website now:
2. GOALS AND KPIs (most important first)
- Goal:
How we’ll measure it:
Where it stands today:
3. AUDIENCES (most important first)
- Audience:
What they need to know before contacting us:
How they find us:
Languages they use:
4. KEY VISITOR ACTIONS
- Action:
Where it goes and who handles it:
5. FEATURES AND INTEGRATIONS
- Must have:
- Nice to have:
- Not needed:
- Systems to connect (and what data moves):
- Constraints (hosting, IT, legal, accessibility):
6. CONTENT AND LANGUAGES
- Approximate number of pages:
- Content we have / to rewrite / to create:
- Who writes it:
- Photography and video:
- Languages, and which need their own SEO:
7. KEEP FROM THE CURRENT SITE
- Pages that bring traffic or enquiries:
- Content and assets to carry over:
- Who holds domain, hosting, analytics logins:
8. BUDGET
- Range:
- What it must cover:
9. DECISIONS
- Day-to-day contact:
- Feedback from:
- Final sign-off:
- How we’ll choose, and by when:
10. DEADLINES
- Hard deadlines, and why:
- Preferred launch window:
- Dates our team is unavailable:
PLEASE INCLUDE IN YOUR PROPOSAL
- Your approach and what you’d change in this brief
- Scope: pages, features, languages
- Timeline and what you need from us
- Fixed price, and what is not included
- Running costs after launch
- Who we would work with day to day
- Examples of similar work
Questions by: [date] Proposals by: [date]Don’t skip the last block: asking every provider for the same things, in the same order, turns a pile of proposals into a real comparison.
When you need a formal website RFP instead
A brief is enough for most businesses. A formal request for proposal (RFP) makes sense when:
- procurement rules or a funding body require competitive tendering;
- finance needs a documented, scored decision for a budget of this size;
- several departments, brands or countries share the site and all need a say;
- IT, legal or compliance need formal answers on security, data protection or accessibility.
An RFP keeps the brief at its core and adds the process around it: submission format and deadline, a question window with answers shared with every bidder, weighted evaluation criteria, contract terms, required documents such as references, and a standard pricing format so bids line up.
Two cautions. An RFP that dictates every feature gets box-ticking answers rather than thinking. And build in conversation: a short call with each shortlisted provider reveals more than pages of written answers.
You may also meet a website requirements document, sometimes called a functional specification. Terms vary, but it usually goes further than a brief: page templates, functions, user roles and acceptance criteria. It is often written with the chosen provider during discovery, starting from your brief.
Who to send your brief to
Match the provider to what your brief describes. A focused site with one clear goal and a modest budget can suit an experienced freelancer. A site with several audiences, languages and integrations is better served by a provider covering strategy, design, development, content and search together, because those parts have to work as one. A large site that changes weekly may justify an in-house team. Our comparison of agencies, freelancers and in-house teams weighs up each option.
Shortlist three or four providers whose past work resembles your project, and send them the same brief with the same deadline. Then watch who asks good questions: they have read it. One that sends a fixed price within the hour, without a single question, probably skimmed it. When proposals arrive, test them against these questions to ask before hiring a web designer.
What to do next
A website brief takes a few hours and repays them many times over: comparable proposals, agreed priorities and fewer surprises later. Copy the template, get your approvers to agree on goals, budget and decision-makers, then send it.
If you are planning a new website or a redesign, send us your brief, or even rough notes, through our contact page, or fill in our online project brief, which walks you through the same questions. A real person replies within one business day, and after a free 30-minute call you receive a fixed-price proposal in writing within three business days. If half the sections still say “not sure yet”, that call is a good place to work them out together.