How to Write a Website Brief

A website brief should make the important decisions visible before design and development begin. It does not need to dictate every colour or technical detail. It should explain the business problem, the audience, the required outcome, the boundaries of the project and the evidence by which proposals will be judged.

A clear brief protects both the business and the supplier. It reduces assumptions, exposes missing information and makes quotations easier to compare.

Begin with the business context

Explain the business in plain language:

• what it provides;
• who it serves;
• where it operates;
• how customers currently find and buy from it;
• why the website project is happening now;
• what has changed since the current site was built, if one exists.

Keep this section factual. A supplier needs to understand the commercial situation, not read a promotional company history.

State the website objective

Write one primary objective and a small number of supporting outcomes. For example:

The website should help owners of small hospitality businesses understand our compliance service, see whether it fits their situation and request an initial assessment with enough information for us to respond usefully.

Supporting outcomes might include reducing repetitive questions, making referral checks easier or providing a secure way to distribute documents. Avoid objectives that no website supplier can guarantee, such as a specific Google ranking or sales figure without a reliable baseline.

Describe the priority audience

For each important audience, include:

• their situation and task;
• what they already know;
• what makes them hesitate;
• the evidence they need;
• the action they should be able to complete;
• any audience the project should not prioritise.

This helps the supplier design for real decisions rather than a vague “general public”.

List the required pages and their purpose

Do not provide only a page count. State what each page must achieve.

Example page requirements

Page	Purpose	Content owner
Home	Explain the offer, audience, main evidence and next step	Business owner
Service page	Describe scope, suitability, process, exclusions and enquiry route	Service lead
Case study	Show a relevant problem, approach and verified result	Project manager
Contact	Provide real contact options, service area and response expectations	Office manager

Mark pages that already exist, pages that need rewriting and pages that must be created from nothing.

Describe the required functions

Explain what the user must be able to do, not only the name of a tool.

Instead of “booking system”, state:

• which appointments can be booked;
• who controls availability;
• whether payment or a deposit is required;
• how confirmations and reminders work;
• how rescheduling and cancellation are handled;
• which staff need access;
• what data must be retained or deleted.

Use the same approach for forms, payments, memberships, multilingual content, product catalogues, maps and integrations.

Document the existing technical environment

If a website already exists, list:

• domain registrar and account owner;
• DNS provider;
• hosting or platform;
• business email provider;
• content management system;
• analytics and Search Console ownership;
• payment, booking and marketing integrations;
• important licences;
• known technical problems;
• whether a complete backup and old URL list are available.

Do not send passwords in the brief. Record that access exists and agree a secure transfer method with the appointed supplier.

Explain the content and evidence available

State who will provide:

• page copy;
• product or service information;
• photographs and usage rights;
• logos and brand files;
• team details;
• case-study facts and permissions;
• reviews and their source;
• legal and privacy information;
• translations where required.

Be honest about gaps. “Copy supplied by client” is not a realistic plan if no one has time or authority to write it.

Set ownership and handover requirements

The brief should state that the business expects appropriate control of:

• the domain;
• hosting or platform accounts;
• website administrator access;
• analytics and Search Console;
• payment and booking accounts;
• licences purchased for the project;
• original design and content files where included;
• documentation and recovery information.

Ask suppliers to identify anything that cannot be transferred or exported before the project begins.

Give budget information that produces useful proposals

A budget range helps a supplier propose a realistic route. Without one, you may receive solutions that are impossible to compare.

Separate:

• the one-off project budget;
• ongoing annual costs;
• optional future phases;
• internal time available from the business.

Ask quotations to show VAT where applicable, third-party renewals, support, hosting and assumptions about content.

Set timing and dependencies

Include the desired launch window and any fixed commercial event, but explain what makes the date important. List dependencies such as photography, product data, approvals, domain access or legal review.

A date without a content and decision schedule is not a plan.

Define how proposals will be judged

Tell suppliers what matters most. Criteria may include:

• understanding of the business problem;
• clarity of scope and exclusions;
• appropriate use of established software;
• content and migration approach;
• mobile and accessibility process;
• ownership and handover;
• support and maintenance;
• total cost over several years;
• quality of relevant, verifiable work.

Include acceptance criteria

Define what must be checked before the project is accepted. Examples include working forms, tested payments, correct content, redirects, mobile behaviour, account handover, documentation and a restorable backup.

A practical brief structure

1. Business and project background
2. Primary objective and success criteria
3. Audience
4. Scope and required pages
5. Functions and integrations
6. Existing website and technical environment
7. Content and assets
8. Ownership, security and handover
9. Budget and ongoing costs
10. Timing and dependencies
11. Proposal evaluation criteria
12. Acceptance and post-launch support

What to avoid

• copying a long feature list from another website;
• specifying software before describing the need;
• asking for “SEO included” without defining work and responsibility;
• assuming the supplier will create all content without cost or input;
• hiding the budget and asking every supplier to guess;
• leaving ownership and maintenance until the end;
• requesting guaranteed rankings, traffic or sales.

The next practical step is to complete the brief before requesting a quotation, then give every shortlisted supplier the same version. That makes differences in approach and price much easier to understand.