A useful brief creates a boundary, not a finished answer.
The brief should make the project understandable without pretending that discovery has already happened. It records what the business knows, shows where decisions are still open and identifies the people and systems that will affect delivery.
That boundary helps a studio assess fit, recommend the right level of work and explain where assumptions could change cost or complexity. It also gives everyone something concrete to return to when new requests appear later.
What should a website brief include?
Include the business context, audience, current problem, desired outcomes, working page list, content ownership, required user tasks, technical constraints, reference points, budget, timing and approval process. Mark anything uncertain so it can be resolved during scoping.
Eight parts of a clear website brief.
Write for the person who has not been inside the internal conversations. Each section below removes a different kind of guesswork.
- 01
Explain the business context
Start with what the organisation does, how the website supports it and why the project is happening now.
Include the relevant products or services, the commercial model and any change behind the brief. A launch, repositioning, new service, merger or outdated platform will each create a different set of priorities.
- What does the business offer?
- What has changed since the current site was made?
- Why is this project important now?
- 02
Describe the audience and their decisions
Name the people the website needs to serve and the questions they must answer before they can act.
Useful audience information is behavioural. Explain what visitors already know, what may make them hesitate and what they are trying to compare or complete. Avoid broad labels unless they change the experience.
- Who is the primary audience?
- What brings them to the site?
- What evidence or information helps them decide?
- 03
Separate the current problem from the outcome
Describe what is failing today, then state what should become easier when the project is complete.
A request such as ‘make it modern’ leaves the goal open to interpretation. Explain whether the problem is unclear messaging, weak enquiries, difficult editing, poor mobile behaviour, slow performance or a product that has outgrown its structure.
- What cannot the current site do well?
- What should a visitor understand or complete?
- How will the business judge whether the change was useful?
- 04
List pages, content and ownership
Provide a working page list and show which content exists, which needs work and who can approve it.
Content affects design, development and timing. Include important documents, photography, illustrations, video, legal text and downloads. If the sitemap is uncertain, say so rather than turning an early guess into a fixed requirement.
- Which pages are essential?
- What content can be reused accurately?
- Who writes, supplies and approves each asset?
- 05
Explain features as user tasks
Describe what people need to do, not only the component you expect to see on the page.
‘Users need to choose a service and send the right project details’ gives more context than ‘add a form’. This approach helps uncover validation, notifications, data handling, permissions and accessibility requirements.
- What task must the feature support?
- What information goes in and where does it go?
- What should happen when the task succeeds or fails?
- 06
Record technical and operational constraints
List the systems, standards and ownership arrangements that the website must work with after launch.
Include domains, hosting, CMS access, forms, analytics, consent, CRM, payments, search, languages, user accounts and data sources. Note security, privacy or accessibility requirements that affect the scope. Unknowns can be marked for discovery.
- Which existing systems must remain connected?
- Who owns the domain, accounts and data?
- Who will update and support the site after launch?
- 07
Use references to explain judgement
Share examples and state what is useful about each one, rather than asking for a copy of another website.
A reference may demonstrate pacing, clarity, typography, navigation or a particular interaction. Explaining the reason helps the designer distinguish a genuine requirement from a passing visual preference.
- What specifically works in the reference?
- What would feel wrong for this business?
- Which brand assets or guidelines already exist?
- 08
Make budget, timing and approvals visible
State the budget range, important dates and the people who can make decisions on behalf of the project.
A date is only useful when the reason behind it is clear. Include launches, events, contract end dates or internal reviews, then identify content and approval dependencies that may affect the route. If scope must be phased, name the first useful release.
- What budget range is available?
- Which dates have an external reason?
- Who gives consolidated feedback and final approval?
A website brief template you can copy.
Use these headings as a starting structure. Short, specific answers are enough. Attach detailed inventories or technical documents separately.
Business
What you offer, what has changed and why this project matters now.
Audience
Who they are, what brings them here and what they need to decide.
Problem
What the current experience prevents or makes unnecessarily difficult.
Outcome
What should become clearer, faster or possible after launch.
Scope
Known pages, content, features and anything that may be phased.
Technical
Platform, integrations, ownership, accessibility and operational needs.
Delivery
Budget range, important dates, dependencies and decision makers.
Technical details that are easy to miss.
A website can look self-contained while depending on several accounts, services and data flows. Recording them early reduces the risk of finding a critical dependency during launch.
Access and ownership
Domain registrar, DNS, hosting, CMS, analytics, email and third-party account ownership.
Data and integrations
Forms, CRM, payments, booking tools, product data, user accounts, APIs and notification routes.
Standards and compliance
Accessibility goals, privacy requirements, consent, retention, security review and legal approvals.
Operations after launch
Who edits content, who handles incidents, what needs monitoring and how future changes are requested.
Leave the right things unfinished.
A good brief makes the starting point clear. It does not need to decide the final sitemap, platform or design direction before the people doing the work have reviewed the problem.
Website brief questions.
How long should a website brief be?
Long enough to make the problem, audience, required outcomes and important constraints clear. A focused document of a few pages can be more useful than a long specification filled with assumptions. Supporting content lists, brand files and technical notes can sit alongside it.
Do I need to know every page before contacting a web designer?
No. List the pages you believe are needed and mark anything uncertain. Part of scoping is testing whether that structure supports the audience and the business goal.
Should a website brief include a budget?
A realistic range helps a studio recommend an appropriate scope and identify trade-offs early. If the budget is not fixed, explain which outcomes are essential and which parts could be phased.
What technical details belong in a website brief?
Include the current platform, domain and hosting arrangements, required forms, analytics, CRM or payment integrations, user accounts, languages, accessibility requirements and any systems that exchange data with the website.
Can Subtle Standard help shape an unfinished brief?
Yes. A complete brief is useful but not required. Bring the current problem, what needs to change and any known constraints, and we can use the first conversation to identify the missing decisions.
