A useful website brief is not a request for a particular colour, page count, or technology. It is a decision document. It explains why the work matters, who it needs to help, what must be true when it is finished, and which constraints the team cannot ignore.
The brief does not need to predict every design decision. In fact, prescribing the solution too early can hide the real problem. Its job is to give the people planning, writing, designing, and building the site enough context to make good choices together.
Start with the business outcome
Open with a short description of the situation today and the change you want the website to support. Keep this concrete.
Weak goal: “We need a modern website.”
Stronger goal: “Prospective customers struggle to understand which service fits them, and the current enquiry form does not capture enough context for a useful first conversation.”
The stronger version gives the team something to investigate and improve. It also avoids treating visual style as the only measure of success.
Include:
- the reason the project is happening now;
- the primary business outcome;
- one or two secondary outcomes;
- known problems with the current experience;
- decisions that have already been made.
If an outcome depends on something outside the website—sales follow-up, stock availability, service capacity, or a third-party platform—name that dependency rather than assigning the whole result to the site.
Describe the audiences and their tasks
Avoid broad labels such as “everyone” or “small businesses.” Describe the situations that bring people to the site and the questions they need answered.
For each important audience, note:
- What prompted the visit?
- What do they already know?
- What concern could stop them moving forward?
- What information would help them decide?
- What is the most useful next action?
This creates a better foundation for navigation and content than a list of demographic traits alone. A returning customer looking for support has a different task from a first-time visitor comparing services, even if both work in the same industry.
Define success without inventing certainty
Choose measures that can actually be observed. Useful examples may include completed qualified enquiries, calls from suitable prospects, successful purchases, demo requests, downloads, or fewer support questions about information the site should explain.
Record the current baseline when reliable data exists. If tracking is missing or untrusted, say so and make measurement setup part of the scope. Do not turn an estimate into a fact or promise a conversion increase before the new experience has real usage data.
Separate three things:
- Delivery checks: the agreed pages and functions work as specified.
- Experience signals: visitors can find information and complete key tasks.
- Business outcomes: suitable enquiries, sales, or operational savings improve over time.
Inventory the content before estimating the build
Page count alone says little about effort. A five-page site with new positioning, photography, legal review, and several integrations can require more work than a larger site with approved content.
List the material that exists, who owns it, and what condition it is in:
- current pages and downloadable files;
- service or product information;
- brand guidelines and visual assets;
- approved photography or illustration;
- testimonials or project evidence with permission to publish;
- policy and compliance content;
- content that must be written, migrated, reviewed, or retired.
Mark facts that still need confirmation. This prevents placeholder copy, unapproved claims, and invented proof from quietly reaching launch.
Turn functionality into testable requirements
“Add a contact form” is not a complete requirement. Explain the job the feature needs to do and what should happen in both success and failure cases.
For a project enquiry form, the brief might specify:
- which information is genuinely needed;
- which fields are optional;
- where a valid submission is stored or sent;
- who receives and owns the follow-up;
- what the visitor sees when delivery succeeds or fails;
- spam, privacy, and retention requirements;
- how the flow will be tested without sending live enquiries.
Apply the same approach to search, account areas, payments, bookings, maps, chat, CRM connections, and content management. Name the systems involved and the people who can provide access.
Record constraints and non-negotiables
Constraints are useful when they are explicit. Include the approved budget range, target date and its reason, required technology, hosting limitations, security or privacy rules, internal review process, supported languages, and accessibility expectations.
Also state what is out of scope. That may include ongoing content production, paid advertising, data cleanup, product photography, or integrations planned for a later phase. Clear exclusions protect both the budget and the quality of the agreed work.
Include search and migration requirements early
Search visibility is easier to protect when it is considered before page structures and URLs are changed. The brief should identify valuable existing pages, known search demand, planned redirects, canonical-domain decisions, metadata ownership, and who will verify the sitemap and indexability at launch.
Search requirements should support useful pages, not a quota of near-duplicate pages. For a broader measurement framework, read how to measure SEO without ranking promises or review the scope described on the SEO services page.
Assign decisions, inputs, and approvals
A project can stall even when the technical work is clear. Name the person responsible for supplying content, approving designs, answering integration questions, reviewing legal text, and accepting the finished work.
Add realistic review windows and explain what happens when an input is late. If several stakeholders can approve the same item, choose one person to provide the consolidated decision.
A compact website brief template
Use these headings as a starting point:
- Business context and reason for the project
- Primary and secondary outcomes
- Priority audiences and their tasks
- Current website and known evidence
- Required content and content owners
- Functional requirements and integrations
- Search, accessibility, performance, and privacy requirements
- Brand assets and visual constraints
- Budget range, timing, and dependencies
- Responsibilities, approval process, and exclusions
- Measures of success and post-launch review
Keep the brief short enough to use. Link to detailed inventories or technical documents rather than turning the main document into an archive.
What happens after the brief
The next step is not automatically a quotation. Important unknowns may need a short discovery phase, a content audit, or a technical review first. Those findings can turn assumptions into an agreed scope, delivery plan, and acceptance criteria.
If you are preparing a new build or redesign, explore website development. You can also use the browser-only word counter to review draft page copy, or share your project context when you are ready for a conversation.