What belongs in a useful website project brief

Start from visitors and their goals

One familiar way to frame a need is a short user story: who the person is, what they want to do, and why. The GOV.UK Service Manual describes that format for building services, and it stresses the goal as the most useful part. That is a team method from one organisation, not a rule for your business, but the habit travels well. For a website, write one line per visitor type, for example: as a homeowner, I want to see which areas you cover so that I know whether to ask for a quote.

If you struggle to state the goal for a page, question whether the page is needed.

The brief to copy

Paste this into a document and answer each line in a sentence or two. This is advice on structure, so adapt it freely.

• Business in one sentence: what you do and for whom.
• Visitors: up to three types, each with a goal written as who, what and why.
• Page inventory: each page, its main message, and the one action it should lead to.
• Actions: every way a visitor can act, such as call, send a form, or download a price list, and where each one goes.
• Content: for each page, who writes the text and who checks facts, prices and claims.
• Provided assets: logo, photos, documents, brand colours and fonts you already have, plus who has the right to use them.
• Missing items: anything not yet decided or not yet existing, each with a named person to resolve it.
• Decision owner: one person who gives final answers when feedback conflicts.
• Exclusions: things this project will not include, written plainly.
• Mobile and accessibility expectations: see the section below.
• Review outcomes: what a reviewer should be able to do or confirm when the site is ready.
• After launch: who updates text, prices and hours, and how a change is requested.

Mobile and accessibility expectations

State what you want in plain words. For mobile, you might ask that every page can be read and every action completed on a phone without sideways scrolling. For accessibility, the W3C WAI planning pages warn that approaching accessibility only as a checklist risks missing the real purpose, the user experience, and say that involving people with disabilities throughout design and development can be more effective. Write down who will be asked to try the site and what you will do with what they find. A brief can state this intent, but it cannot by itself show that a site meets any standard.

Scope boundaries and ownership

Exclusions prevent quiet disagreements. Examples: no online payments, no member login, no blog, no translation into a second language, no product photography. Mark each as excluded or later.

For content and assets, separate three cases: you already have it, you will supply it by a stated point, or someone else is expected to create it. Unclear ownership of text and images is a common reason pages stall, so list it openly.

A hypothetical example

Imagine a small bike repair shop. Visitors: a commuter who wants to know whether a flat tyre repair is offered and what it costs, and a parent who wants opening hours. Pages: Home, Repairs and prices, Contact. Actions: call the shop, or send a short form. Provided assets: a logo file and six phone photos; the owner supplies prices. Missing: opening hours over holidays, to be settled by the owner. Decision owner: the shop owner. Exclusions: online booking, shop, and blog. Review outcome: a person on a phone can find the tyre repair price and send an enquiry within a minute. This example is invented and untested.

Approval and ongoing updates

Decide in advance who approves each stage and what form approval takes, such as a written reply from the decision owner. Collect feedback in one list, not scattered messages. After launch, say who edits what, how often content is likely to change, and where requests go. If nobody owns updates, prices and hours go out of date quietly.