Website Design Brief Template: Scope the Build Before Asking for Quotes

A useful website brief does not prescribe colours and page counts before the problem is clear. It tells a designer or agency:

• what the business needs the website to change;
• who must act and what stops them;
• which content and proof already exist;
• which journeys, systems and search assets must be protected;
• who decides and supplies material;
• what budget and deadline are real;
• how the finished site will be accepted and owned.

Copy the template below into your working document. Use plain answers. Write unknown where discovery is needed. A visible gap creates a better quote than invented certainty.

Checked: 14 July 2026 · UK business template · Suitable for a new site, refresh, redesign or ecommerce brief

The one-page brief

Complete this first. It is enough for an initial fit conversation.

textPROJECT
Business:
Website URL:
Project owner:
Target launch window:
Working budget range:

WHY THIS PROJECT EXISTS
The current business problem is:
The website should help us:
The single most important visitor action is:
If nothing changes, the cost or risk is:

CUSTOMERS
Our highest-value customer is:
They arrive because:
Their main questions or objections are:
They currently find us through:

OFFER
The services/products we most want to grow are:
We are a strong fit when:
We are not a fit when:
Our best proof is:

SCOPE
This is a: new site / refresh / redesign / migration / ecommerce build
The essential journeys are:
The essential pages or content types are:
The systems that must connect are:

CONTENT
Existing copy, images, reviews and case studies:
Content that must be created:
The factual approver is:

SEARCH AND DATA
Existing search traffic or URLs that matter:
Analytics and Search Console access:
The actions that must be tracked:

OWNERSHIP
Accounts the business will own:
Who will update the site after launch:
Required support after launch:

SUCCESS
In 90 days we will look for:
In 12 months we will look for:

If those answers fit on one useful page, agencies can decide whether the project matches their capability before everyone spends hours on a proposal.

The complete website design brief template

1. Business context

textLegal business name:
Trading name:
Current website:
Primary contact:
Final decision-maker:
Other approvers:

What the business sells:
How the business makes money:
Average or typical customer value, if shareable:
Primary locations/markets:
Main competitors or alternatives:

Why the project is happening now:
What has changed in the business:
What must remain true after launch:

Why it matters: the same design can be sensible for a low-risk brochure and reckless for a revenue-critical booking site. Context sets the acceptance standard.

2. The commercial problem

textThe current website is failing because:
Evidence for that belief:
The most valuable improvement would be:
The primary action visitors should take:
Secondary actions, if genuinely needed:

Current monthly traffic, if known:
Current monthly enquiries/sales, if known:
Current conversion rate, if trustworthy:
Current lead quality or operational problem:

Cost of doing nothing:
Cost of a failed or delayed launch:

Avoid “we need a modern website”. Modern is a visual preference. “Qualified homeowners cannot see whether we cover their area or request a survey on mobile” is a project.

3. Audience and buying situations

textPrimary audience:
What triggers them to look:
What they already know:
What they fear or distrust:
What they compare:
What proof they need:
What stops them taking action:
The words they use for the problem:

Secondary audience:
How their journey differs:

Audiences the website does not need to prioritise:
Accessibility or language needs known today:

Use customer calls, reviews, emails and sales notes. A demographic persona with no buying situation is difficult to design for.

4. Offer and positioning

textPriority services/products:
Who each is for:
Who each is not for:
Price or price factors we can publish:
Process or delivery model:
Geographic/service boundaries:
Key differentiators we can prove:
Claims requiring evidence or approval:

Primary proof:
- Reviews:
- Case studies:
- Results/data:
- Accreditations:
- Team expertise:
- Client/customer logos:
- Guarantees/warranties and conditions:

Do not ask the copywriter to “make us sound different” when the business has not agreed what it can prove.

5. Existing website baseline

textCurrent platform/CMS:
Hosting provider:
Domain/DNS owner:
Approximate number of pages/products:
Current integrations:
Current forms/bookings/checkout:

What works well and should remain:
What users complain about:
What the team cannot update:
Known mobile/performance issues:
Known accessibility issues:
Known SEO/indexing issues:

Access available:
- CMS:
- Hosting:
- Domain/DNS:
- Google Search Console:
- Analytics/tag manager:
- Business Profile/Merchant Center:
- CRM/email/booking/payment:

For a redesign, attach a crawl, Search Console exports and analytics evidence. Do not let the new sitemap erase an existing asset by accident.

6. Scope and journeys

textProject type:
[ ] New website
[ ] Visual/content refresh
[ ] Full redesign/rebuild
[ ] Platform migration
[ ] Ecommerce
[ ] Web application/integrated workflow

Primary visitor journey:
Entry point:
Decision steps:
Proof needed:
Action:
Confirmation/follow-up:

Other essential journeys:
1.
2.
3.

Staff/admin journey:
What the team must update:
What should remain controlled by a developer:

Write journeys before pages. Pages exist to support decisions and tasks.

7. Page and content inventory

textProposed page/content owner | Purpose | Primary audience | Action | Existing/new

Homepage:
Service/product hub:
Priority service/product pages:
Location pages:
About/team:
Case studies/projects:
Articles/guides/resources:
Pricing/process:
Contact/booking/quote:
Customer service/policies:
Legal/privacy/cookies:
Other content types:

Use “content owner” to mean the page responsible for one search intent or buyer question. This helps prevent three pages competing to explain the same service.

8. Content production

textContent strategy owner:
Subject experts available:
Interview time available:
Copywriter/editor:
Factual approver:
Legal/compliance approver, if needed:
CMS entry and formatting owner:

Existing assets:
- Brand guidelines:
- Copy:
- Photography:
- Video:
- Reviews:
- Case studies:
- Data/research:
- Logos/accreditations:

New production required:
- Copywriting:
- Photography:
- Video:
- Illustration/animation:
- Translation:
- Data visualisation:

Customer permissions or usage rights needed:
Deadline for final material:

“Client supplies content” is not a content plan. Name the material, owner and due date.

9. Design direction

textExisting brand system:
Brand assets that must be used:
Brand qualities the interface should express:
Things the brand should never feel like:

Websites/examples we find useful:
What specifically works in each:
Examples we dislike:
What specifically fails:

Required devices or contexts:
Accessibility target/requirements:
Motion preferences and reduced-motion requirement:
Photography/illustration direction:

Do not write “make it like Apple” without saying whether you mean restraint, product focus, typography, animation or trust. Reference decisions, not brands.

10. Functional requirements

textFeature | User | Business purpose | Must/should/could | Acceptance check

Contact/quote form:
Booking:
Search:
Filters:
Customer account:
Ecommerce/checkout:
Subscriptions/memberships:
Calculator/configurator:
Map/location finder:
Downloads/resources:
Blog/CMS:
Multi-language/market:
Other:

Every feature should have an owner and acceptance check. “CRM integration” is incomplete until the required fields, consent, failure behaviour and destination are known.

11. Integrations and data

textSystem:
Business owner:
Purpose:
Data sent/received:
Authentication/access available:
Source of truth:
Failure behaviour:
Privacy/consent requirement:
Testing contact:

Repeat for:
- CRM
- Booking
- Email marketing
- Payment
- Accounting
- ERP/PIM/inventory
- Reviews
- Analytics/advertising
- Other APIs

Ask whether each provider has an API, sandbox and usage cost before the quote assumes a simple connection.

12. SEO, AEO and migration

textPriority non-brand services/products:
Priority locations/markets:
Existing pages/queries that must be protected:
Existing backlinks or campaign URLs that matter:
Current sitemap/crawl available:

Required outputs:
[ ] Search and content baseline
[ ] Information architecture review
[ ] One-to-one URL map
[ ] Permanent redirects
[ ] Titles/descriptions/canonicals
[ ] Internal-link plan
[ ] Structured data
[ ] XML sitemap
[ ] Robots/indexability checks
[ ] Search Console verification/submission
[ ] Merchant Center/Business Profile checks
[ ] Post-launch monitoring

AI-search/answer visibility needs:
Primary authoritative sources for time-sensitive claims:
Content refresh owner and triggers:

Google recommends involving SEO early in a redesign. If URLs or platform change, use our full website redesign SEO checklist.

13. Analytics and success measures

textPrimary business action:
Secondary actions:
Qualified action definition:
Current baseline:

Events required:
- Calls:
- Forms:
- Bookings:
- Purchases/revenue:
- Quote starts/completions:
- Key tool or account actions:

Consent/cookie requirements:
Analytics owner:
CRM/source reporting owner:

30-day launch health measures:
90-day performance measures:
12-month business measures:
Known attribution limitations:

Do not set “increase traffic” as the only success measure. A redesign can attract more irrelevant visits and fewer qualified enquiries.

14. Technical and quality requirements

textPreferred or required platform, with reason:
Hosting/data location constraints:
Browser/device support:
Accessibility standard or acceptance process:
Performance/Core Web Vitals targets:
Security/access requirements:
Backup and recovery requirements:
Privacy/data-processing requirements:
Environments/staging needs:
Release and rollback requirements:

Acceptance checks:
[ ] Real mobile journeys
[ ] Keyboard and screen-reader basics
[ ] Form validation and delivery
[ ] Test booking/order/payment
[ ] Analytics and consent states
[ ] Redirects and indexability
[ ] Structured data
[ ] Performance on representative templates
[ ] Browser/device matrix
[ ] Content and legal approval

Use “platform required” only when there is a real organisational constraint. Otherwise ask providers to recommend the simplest route and explain the trade-off.

15. Ownership and handover

textThe business must own/administer:
[ ] Domain and DNS
[ ] Hosting/platform organisation
[ ] CMS
[ ] Source repository where relevant
[ ] Analytics, tag manager and Search Console
[ ] Forms, email and booking services
[ ] Payment and customer-data systems
[ ] Design/source files agreed in scope
[ ] Licences and renewal records
[ ] Backups and documentation

Training required:
Documentation required:
Content migration/import included:
Post-launch defect period:
Ongoing maintenance required:
Exit/offboarding requirement:

Ownership is operational access, export and continuity—not just a sentence assigning copyright.

16. Budget, timeline and procurement

textWorking budget range:
Is VAT inside or outside the range?
Budget includes:
Budget excludes:
Preferred payment structure:

Desired launch date:
Reason the date matters:
Hard dependencies:
Internal unavailable dates:
Content deadline:
Decision date:

Number of providers invited:
Selection criteria and weighting:
Pitch/meeting format:
Who selects the provider:

Giving a budget range does not invite an agency to spend all of it. It prevents a £3,000 buyer and a £30,000 provider from producing incompatible theatre.

17. Risks, assumptions and exclusions

textKnown risks:
1.
2.
3.

Assumptions the quote may use:
1.
2.
3.

Explicitly out of scope:
1.
2.
3.

Open questions for discovery:
1.
2.
3.

The open-question section is a quality signal. A good provider will resolve uncertainty before turning it into a fixed promise.

How to send the brief

Give providers:

• the same brief and appendices;
• the same response deadline;
• one route for clarification;
• access to current data under appropriate confidentiality;
• a clear budget range;
• selection criteria;
• permission to challenge or reduce the scope.

Ask the response to separate:

1. understanding of the problem;
2. recommended approach and why;
3. scope and exclusions;
4. content and client responsibilities;
5. milestones and acceptance;
6. team and relevant proof;
7. cost, third-party fees and payment schedule;
8. ownership, support and exit.

Use our guide to choosing a web design agency to score the responses.

Common brief mistakes

• prescribing a platform before defining the requirement;
• listing pages without the job each page performs;
• treating content as a late client task;
• hiding the budget;
• calling a preference a requirement;
• setting a launch date with no content owner;
• omitting existing search traffic and URLs;
• assuming analytics, accessibility and mobile QA are automatic;
• forgetting account and data ownership;
• asking for “something modern” instead of a measurable change;
• inviting too many agencies;
• leaving the final decision-maker out of discovery.

Frequently asked questions

How long should a website brief be?

Use one page for initial fit and a fuller brief for quoting. A small site may need three to five useful pages of detail; a complex migration may need appendices, data and journey maps. Clarity matters more than length.

Should I include a budget?

Yes. Give a realistic range and state whether VAT, content, photography, licences and ongoing support are included. Providers can recommend the best scope inside it.

Should I choose the website platform in the brief?

Only when a real organisational or integration constraint requires it. Otherwise describe the editing, ownership, performance and functionality needs and ask the provider to recommend the simplest fit.

Who should write the website brief?

One project owner should consolidate input from leadership, sales, operations, marketing and technical stakeholders. The final decision-maker must approve the commercial problem, budget and scope.

Do I need a separate SEO brief?

Not for a normal redesign. Search evidence, URL migration, content ownership, redirects and measurement should be part of the website brief from the start. Specialist appendices may be needed for a large site.

A good brief makes the proposal smaller

The point is not to predict every screen. It is to expose the decisions, evidence, ownership and risk early enough for a capable provider to recommend the lightest build that works.

Related: Small-business website design · Web design for UK businesses · Choose a web design agency · Web designer vs agency vs DIY · Website cost UK