How to write a website project brief that keeps the build focused

Start with the decision your website should make easier

A website project brief explains who the site serves, what those visitors need to do, and what a successful first release must accomplish. It gives a designer or developer enough context to make sensible choices without pretending every detail is already decided. The most useful brief begins with a business problem rather than a list of visual effects.

For example, a fictional repair business might need visitors to understand its service area and request an appointment. That is a clearer goal than ‘build a modern website.’ A modern design can support the goal, but it cannot define it. Write the desired visitor action in one sentence, then list what visitors need to know before taking it.

Describe the audience and the current problem

Explain whether visitors are first-time buyers, returning customers, partners or staff. Describe their likely questions and the device or situation in which they will use the site. A customer checking opening hours on a phone has a different need from a procurement manager comparing capabilities.

Include what fails today: unclear services, repeated email questions, inaccessible forms, missing content or a difficult editing process. Distinguish observations from assumptions. ‘We receive questions about coverage’ is evidence if recorded; ‘visitors probably want a chatbot’ is a hypothesis to test.

List the first-release pages and content owners

A short page inventory is often enough: Home, Services, About, Contact and the policies appropriate to the site. Give each page a purpose, primary action and content owner. Identify who supplies photographs, service descriptions, brand assets and any evidence supporting claims.

Separate essential features from later ideas. If appointment requests can be handled manually at launch, do not quietly turn the first release into a scheduling, payment and customer-account platform. Each additional workflow adds permissions, errors and maintenance decisions.

• Required: visitors can find services and submit a request.
• Optional later: appointment scheduling and customer accounts.
• Excluded initially: online payment and automatic eligibility decisions.

Make constraints visible before design starts

Record the domain, existing hosting, integrations, languages, accessibility needs, editing expectations and budget boundaries. Mark unavailable details as unknown. A missing server account is a dependency to resolve, not an invitation to invent access.

Use anonymized examples to explain integrations. Describe a system and the information it needs without including keys or production records. For initial inquiries, follow the website’s data policy and keep confidential information out of public forms.

Turn preferences into acceptance criteria

Acceptance criteria say what can be checked. ‘Looks professional’ is a preference; ‘a visitor can complete the inquiry on a narrow screen using labeled fields and receives a clear confirmation’ is observable. Include error behavior: what happens if the request times out, the email is invalid or a visitor retries?

For the fictional repair business, a first-release acceptance list could require a visible service area, a working contact route, correct opening hours, keyboard navigation and a verified mobile layout. W3C’s preliminary checks offer a starting point for accessibility review, although passing those checks alone does not establish full accessibility conformance.

A brief template you can use today

Keep the brief readable enough that everyone can explain the same project after one pass. Add supporting detail where a decision depends on it. Before the build begins, agree who approves scope changes and who signs off on release. A brief organizes the conversation; the project agreement defines commercial commitments.

• Goal: the visitor action and business problem.
• Audience: who uses the site and what they need to understand.
• Scope: required pages, workflows and explicit exclusions.
• Content: assets needed and the owner of each item.
• Constraints: integrations, permissions, timing and budget boundaries.
• Acceptance: observable results, error cases and release approver.