A good website brief gives a designer enough context to solve the right problem. It does not need to describe every colour, animation or layout. In fact, prescribing the finished design too early can hide the decisions that matter: who the site is for, what they need to understand and what the business must be able to manage after launch.
The template below is deliberately practical. Copy the headings into a document, answer what you know and mark uncertain items as questions. Honest gaps are more useful than invented certainty.
1. Business and project summary
- Business name and website address, if one exists.
- What the business sells or provides, in two plain sentences.
- Why the website project is happening now.
- The person responsible for decisions and final approval.
- People who need to contribute content, technical access or legal review.
A useful reason is specific: “Most enquiries ask whether we serve their area, and the current site does not answer that” is more actionable than “the website looks old”.
2. The outcome the website should support
Choose one primary outcome and up to two supporting outcomes. Examples include receiving qualified project enquiries, selling a defined product range, reducing routine support questions or giving existing customers access to documents.
Describe how the business will recognise improvement. That might be more enquiries containing the information needed to quote, fewer calls about opening hours, successful online bookings or less staff time spent copying form details into another system. Avoid using traffic alone as the definition of success.
3. Priority audiences and their questions
Do not create fictional personas with decorative details. Name the real groups that use the site and the decisions they are trying to make.
For each group, complete these prompts:
- They arrive because…
- Before taking action, they need to know…
- They may hesitate because…
- The most useful next step for them is…
Use questions taken from actual enquiries, sales calls or support requests where available. They are stronger inputs than assumptions about what visitors “should” care about.
4. Pages and content
Create a simple content inventory. For each proposed page, record its purpose, owner and status.
- Page: a working name such as Website Services or Delivery Information.
- Visitor question: the main question this page answers.
- Action: what a visitor can reasonably do next.
- Evidence: relevant specifications, examples, process details or verified feedback.
- Content owner: the person who supplies and approves the facts.
- Status: ready, needs editing, needs writing or unavailable.
Include policy pages, confirmation messages and error states in the inventory. They are part of the experience even though they rarely appear in a visual mood board.
5. Functional requirements
Describe what users need to accomplish rather than naming a plugin or fashionable technology. For example: “A customer chooses a service, provides billing details and receives a paid invoice” is clearer than “add Stripe”.
Cover forms, booking, payments, accounts, search, downloads, maps, languages and integrations. For each integration, include the existing provider, account owner, available access and data that must move between systems.
6. Brand and visual material
List the assets that actually exist: vector logo files, colour references, font licences, photography, illustration and document templates. Link to the approved files rather than attaching several conflicting logo versions.
If the brand needs work, say so. The designer can then separate essential identity decisions from page design instead of quietly improvising a new brand inside the website budget.
7. Technical and operational constraints
- Current domain registrar, hosting provider and website platform.
- Systems that must remain in use.
- Accessibility, security or sector requirements.
- Who will update the site after launch and how confident they are doing so.
- Known seasonal dates, campaigns or operational blackout periods.
- Data that must be retained, migrated or deleted.
Never place passwords in the brief. Share access through an agreed secure method after appointing the supplier.
8. Scope, timing and budget
State whether the date is fixed or preferred, what creates the deadline and when content and approvals will be available. A launch date is not credible if the people supplying product data or legal wording cannot participate.
If there is a budget range, include it. This allows the supplier to recommend a proportionate first phase and identify work that should be deferred. If the budget is unknown, ask for options that explain the trade-off rather than one unexplained total.
9. Review and acceptance
Name one person who consolidates feedback. Agree review windows and define what must be tested before approval: priority journeys, forms, mobile layouts, supported browsers, redirects, analytics and content accuracy.
Also record who can approve a change to scope. Without that rule, small requests accumulate and neither side knows whether cost or timing has changed.
10. Questions for the supplier
- Which parts of this brief are assumptions that need discovery?
- What will you deliver, and what must we supply?
- How will mobile, accessibility, performance and forms be checked?
- Which accounts and files will we own?
- What is excluded from the fee?
- What support is available after launch?
Sources and further reading
- GOV.UK Service Standard: understand users and their needs — a public-service standard that explains why delivery should begin with real user needs.
- W3C WCAG overview — the source for treating accessibility as defined, testable requirements rather than a visual preference.
A completed brief should make the first supplier conversation shorter and more useful. If you want Xapner to review yours, send the document with your enquiry and remove passwords or confidential customer data first.