What to Include in a Website Development Brief

A useful website development brief makes decisions visible. It explains what visitors need to do, what the business needs to achieve, and what must be included before anyone can approve launch. It also identifies what is unknown. You do not need to prescribe a technology stack to write a strong brief; you need enough clarity for different teams to estimate the same work.

Use the sections below as a working document for a new website or a substantial rebuild. Replace broad adjectives with examples, observable acceptance criteria, and named decision owners.

Start with purpose and visitor tasks

Describe the organisation, its offer, and the reason for the project. Separate the business outcome from the website feature proposed to support it. “Add a contact form” is a feature; “help suitable prospects send enough information for an initial conversation” describes its purpose.

List the audiences and their priority tasks. For each task, note the information visitors need, the action they should be able to take, and the destination after that action. Avoid declaring every audience equally important: name the primary journey for the first release.

A hypothetical professional-services site might prioritise a prospective client's path from a service description to an enquiry. Its acceptance test could require a visitor to find the relevant service, understand its scope, and submit an enquiry that reaches the designated team. This is a testable scenario, not a promised commercial outcome.

Define scope and content responsibilities

List the pages and distinct page layouts separately. A collection of articles may share one layout while still requiring substantial writing, migration, and review. Identify languages, downloadable documents, forms, search, accounts, or other functions only where they are needed.

Give every content group an owner. State who writes, approves, enters, translates, and checks the content. Include images, usage permissions, brand assets, and legal copy. Mark material as ready, awaiting review, or missing rather than assuming content will arrive before launch.

Record explicit exclusions. If photography, translation, email campaigns, or customer account migration are outside the first release, say so. Keep a separate later-phase list so an interesting suggestion does not silently become a launch requirement.

Explain functions, data, and integrations

For each feature, describe what initiates it, what information it uses, what success looks like, and what happens when something fails. For forms, identify fields, recipients, confirmation messages, validation, spam handling, and the approved approach to personal information.

List connected systems and the person who can confirm their capabilities. Specify which system owns each record and whether information moves in one direction or both. Request documentation and suitable test access through a secure process; do not place passwords, access tokens, or customer records in the brief.

Ask who can publish content, approve changes, and manage users. A request for “an editable website” is incomplete until the team knows what editors must change without technical assistance.

Turn quality expectations into checks

“Accessible, responsive, and fast” needs a verification plan. Specify supported browsers and devices, important page types, keyboard journeys, readable error messages, and how accessibility issues will be assessed. Agree the applicable accessibility standard and evaluation scope with qualified stakeholders rather than claiming compliance from an automated score.

W3C's accessibility planning guidance treats accessibility as work to integrate throughout projects and includes guidance on involving users with disabilities.3 Assign responsibility during design, content preparation, development, and review, not only at the final sign-off.

For performance, agree representative pages, test conditions, and the evidence expected before and after launch. Google's Core Web Vitals describe loading, interactivity, and visual stability through LCP, INP, and CLS.4 Use those definitions when discussing targets, while distinguishing controlled testing from real visitor measurements. A test result is evidence for its conditions, not evidence for every device or connection.

Set commercial boundaries and approval rules

Provide an available budget range or spending constraint and explain what it must cover. Ask proposals to distinguish implementation, content work, third-party charges, and continuing support. If a launch deadline is fixed, state the reason and any dependencies rather than requesting an unsupported delivery promise.

Name one accountable approver and the people who review content, technology, privacy, and accessibility. Define how feedback is consolidated and how scope changes are assessed. Include ownership of domains, hosting, source files, and service accounts, plus the expected handover and support arrangements.

Copy this website brief worksheet

Use “unknown” where necessary and assign someone to resolve it. Attach relevant documents rather than duplicating inconsistent versions of them.

• Purpose: Why this project, why now, and what outcome matters?
• Visitors: Primary audience, priority task, and evidence behind that choice.
• First release: Pages, layouts, languages, functions, and explicit exclusions.
• Content: Inventory, source material, rights, owner, readiness, and approver.
• User journey: Starting point, actions, successful outcome, and failure handling.
• Systems: Integrations, record ownership, documentation, and access owner.
• Quality: Accessibility scope, browser coverage, performance conditions, and acceptance tests.
• Governance: Budget boundaries, deadline dependencies, reviewers, and final approver.
• Launch and support: Migration needs, release authority, handover, and maintenance owner.
• Open decisions: Question, owner, evidence required, and decision deadline.

Before requesting proposals, walk through one visitor journey with the business, content, and technical owners. Resolve contradictory assumptions and give the brief a version identifier. Ask each proposal to reference that version and state its exclusions. Bring the remaining questions to a project discussion; uncertainty is manageable when it is visible.

References

• 3: W3C accessibility planning and policies overview
• 4: Google's Web Vitals overview