Write a useful website brief
Turn a website idea into a practical brief covering visitor tasks, pages, content, responsibilities and acceptance checks. Includes a complete example.
A website brief should let a supplier explain what they will build, what they need from you and which decisions affect the cost or delivery date. The useful detail is the work the site must support: who arrives, what they need to know and what should happen next.
Write the brief in plain language. If the technology is undecided, describe the outcome you need before naming a platform. A requirement such as “the owner can correct opening hours without changing the layout” gives a supplier more to work with than “easy to update”.
Begin with the visitor's task
Gather questions from actual enquiries, staff conversations and existing website feedback. Separate what you know from what you assume. The GOV.UK Service Manual's user-needs guidance recommends basing needs on evidence and revisiting them as you learn.
For your brief, record three things together:
- The person and situation: a householder has a loose dining chair and is deciding whether a workshop can help.
- The information they need: repair scope, exclusions, assessment arrangements and what photographs to prepare.
- The next step: request a review of the item, rather than book a repair before its condition is known.
“More enquiries” is a business objective. “Understand whether my chair is suitable for assessment” is a visitor task. Both belong in the brief, because a higher enquiry count is not useful if the enquiries concern work the business cannot undertake.
Specify pages and functions separately
A page is a place to answer a question. A function does something, such as taking a payment or sending an application. Listing these separately exposes requirements that might otherwise be hidden in the word “website”.
For each proposed page, write its purpose and next action. For each function, write its inputs, result, owner and failure behaviour. If you want an enquiry form, for example, agree what happens when delivery fails and who handles the information. Do not assume it is included because a proposal mentions a contact page.
Use the pages and navigation guide to decide which questions need their own page.
A complete fictional website brief
Teaching scenario: Alder & Grain is an invented furniture repair workshop. The requirements below are assumptions for this example, not a real business offer or a model contract.
| Brief field | Completed example | Why this helps the supplier |
|---|---|---|
| Business objective | Help households recognise suitable repair work and prepare useful assessment enquiries | Establishes the decision the website should support |
| Primary audience | People who can bring wooden dining chairs or small tables to the workshop by arrangement | Defines practical suitability without inventing a broad service area |
| Visitor tasks | Check repair scope; understand assessment; prepare photographs; find the correct contact route | Supplies tasks to test in the draft site |
| Required pages | Home; furniture repairs; how assessment works; workshop information; contact and preparation checklist; current policies | Gives each page a distinct role |
| Functions | Readable pages, an image gallery and a clearly labelled email link; no payments, accounts or booking calendar in this scope | Removes uncertainty about transaction features |
| Content owner | Workshop owner confirms service facts and writes the first draft; designer edits structure and loads the approved content | Separates factual responsibility from production work |
| Available assets | Original wordmark and six workshop photographs; owner checks permissions before use | Makes asset preparation an explicit dependency |
| Scope limits | Wooden chair joints and minor wooden-table repairs; no upholstery, home visits or national collection | Prevents the site attracting unsuitable work |
| Delivery constraint | Launch after the owner approves the copy and the six images are ready; dates are agreed after that review | Shows which inputs control the schedule |
| Supplier responsibilities | Responsive design, agreed page templates, content entry, technical setup, route handling and a recorded handover | Gives the proposal tangible deliverables |
| Owner responsibilities | Confirm facts, supply usable assets, approve one consolidated set of feedback and retain business account access | Exposes work that cannot be delegated by implication |
| Review process | Agree page map first, review homepage and service page next, then test the complete site | Avoids reviewing everything for the first time at launch |
| Acceptance criteria | A new reader can identify suitable work, explain the assessment sequence and find what to prepare; the owner can amend the agreed text fields | Makes “finished” demonstrable |
| Open questions | Confirm the real contact address, appointment arrangements, image permissions and whether ongoing editing support is wanted | Keeps unknown facts visible instead of filling them with guesses |
The open questions are part of a complete planning document. They are not permission to publish missing business details. Allocate each question to an owner and a decision date before it affects the build.
Make budget and timing usable
If you have a spending limit, state what it includes: initial work, content, photography and any first-year operating costs. Ask the supplier to separate recurring charges from the build. There is no universal price or delivery time for the page list above; scope, supplied material and support arrangements change the work involved.
For timing, distinguish a fixed business event from a preferred date. Record what can be reduced if the deadline matters more than the optional scope. “Launch the approved information pages before an event; assess a gallery enhancement separately” is a decision a supplier can act on.
Replace vague acceptance statements
| Vague wording | A checkable requirement |
|---|---|
| “Make it professional” | Use the approved colours, type styles and image set consistently across the agreed templates |
| “Make it mobile friendly” | Review the main visitor tasks on a narrow phone screen, with readable text and usable navigation |
| “Optimise it for Google” | Agree the content, metadata, crawlability, sitemap and old-URL checks included; do not treat a ranking as a deliverable |
| “Make it accessible” | Agree an accessibility target, evaluation scope, responsibilities and how identified barriers will be fixed |
| “We want full ownership” | List domain, hosting, source files, assets, licences, access and exit arrangements for explicit agreement |
A brief supports a quotation and discussion. Contract wording, rights and responsibilities still need to be agreed between the parties.
Use the brief to obtain comparable proposals
Send the same version to each supplier. Ask them to mark included work, exclusions, assumptions and owner-supplied items against it. An unanswered requirement should stay visible until somebody accepts responsibility for it.
Download the website brief worksheet, then use the proposal comparison to evaluate the responses. The finished local-service example shows how these requirements become pages.
The source notes
Sources and further reading
- GOV.UK Service Manual: Learning about users and their needs Checked 4 November 2026