How to Write a Website Brief: A Checklist for Business Owners

A website brief explains what your business needs the website to do, who will use it and what must be delivered. Include your goals, priority audiences, proposed pages, content responsibilities, required features, budget range, timeline and handover expectations. Mark uncertain decisions clearly so your development partner can investigate them before committing to a scope.

You do not need to choose a framework or write a technical specification first. A useful brief gives the team enough context to ask better questions, identify dependencies and estimate the work on a shared basis. Here is a practical way to put one together.

Start with the business problem

Describe why the project matters now. “We need a modern website” tells a designer little about the problem. A more useful statement might be: “Our service pages do not explain the differences between our offers, and most inquiries arrive without enough information for our sales team to respond.”

Identify one primary goal and a small number of supporting goals. Examples include helping prospects choose a service, making appointment requests easier, supporting a new location or allowing staff to update content without developer help.

Separate the website’s responsibilities from the business outcome. A functioning inquiry form is something the project can deliver and test. More qualified inquiries also depend on the offer, traffic and follow-up. Record the measures you want to monitor without treating them as guaranteed results of the build.

Define the audiences and their next steps

List the people who need to use the website and what each group is trying to accomplish. Be specific enough to make design decisions. “Everyone” does not help a team decide which content should appear first.

For a professional services business, a new prospect may need to compare services, review relevant work and request a conversation. An existing client may only need a support route. For a clinic, new patients may need practitioner and first-visit information before they contact the practice.

Write a short journey for each priority audience: where they arrive → what they need to understand → the action they should be able to take. Include the action that follows behind the scenes. If someone submits an inquiry, who receives it and what happens next?

List pages, content and responsibilities

Create a first-pass page list, rather than a final sitemap. Identify which pages exist, which need rewriting and which must be created. If you are replacing a website, include a list of existing URLs so useful content and important destinations are considered during migration.

Distinguish page count from layout count. Ten service pages may share one reusable layout, while a directory, booking flow and product comparison each require different behaviour. Both the amount of content and the variety of templates affect scope.

Content item	What to record in the brief
Page copy	Existing, needs revision or new; who writes and approves it.
Brand assets	Available logo files, colours, typography and any usage rules.
Images and video	Available assets, permission to use them and any production needed.
Project examples	Confirmed scope, approved images and evidence for any claims.
Policies and specialist information	Who supplies and reviews the final wording.

Content readiness is a delivery dependency. Agree when approved material will be available and what happens if it arrives late. For a healthcare project, our clinic website planning guide provides a more specific starting page checklist.

Describe features through real scenarios

Avoid relying on labels such as “CRM integration” or “online booking” alone. Explain the action, the information involved, the destination system and the result the visitor or team should see.

For example: “A prospect selects a service, enters their contact details and submits an inquiry. The website shows a confirmation, creates a record in our existing CRM and notifies the assigned team. Duplicate submissions and delivery failures need an agreed handling process.”

For each feature, record:

• Whether it is essential for launch or can follow later.
• The existing system or account it must connect to.
• What access, subscription or documentation is available.
• Who will manage the feature after launch.
• What should happen when the normal flow fails.

Do not put passwords or customer records in a shared brief. Access can be arranged through an appropriate secure process once the team and permissions are agreed. Our web development service connects these requirements with implementation, testing and handover.

Explain design and editing needs

Share a few reference websites and explain the specific qualities you find useful: readable service pages, straightforward navigation, a clear booking flow or an effective project presentation. A reference helps communicate preferences; it is not permission to reproduce another business’s design or content.

Say what should stay from your existing identity and what can change. If the brand needs work, distinguish that from applying an established identity to a website. Web design can then address page structure, visual hierarchy and visitor journeys with a clearer starting point.

Also explain who will edit the site, how often and what they need to change. A team publishing weekly articles has different editing needs from a business updating a few pages each year. These requirements should inform platform selection alongside functionality, budget and maintenance responsibilities.

Agree budget, timing and approval

Provide a realistic budget range and state what it needs to cover. Separate the initial project from recurring costs such as hosting, subscriptions, maintenance and future content work. If the budget is undecided, identify the essential launch scope first and ask for options with clear tradeoffs.

Explain whether the deadline is a genuine external commitment or a preferred date. List dependencies such as brand approval, photography, content delivery, account access and third-party integration checks. A launch date is easier to assess when these dependencies are visible.

Name the person who can approve decisions and how feedback will be collected. Consolidated feedback prevents the development team from having to resolve conflicting instructions from several people. Agree review stages and how additions to the scope will be estimated and authorised.

Define what “ready to launch” means

Acceptance criteria make the brief testable. Replace “the website must work well” with specific checks that match the agreed scope.

• Approved pages and content are present, and navigation reaches the intended destinations.
• Important journeys work on the agreed mobile and desktop browsers.
• Forms show useful errors and confirmations, and submissions reach the correct system.
• Keyboard access, visible focus and form labels have been checked.
• Search settings, canonical URLs, sitemap and any required redirects have been reviewed.
• Performance is assessed against agreed pages, conditions and measures.
• Editing access, account ownership, documentation and support responsibilities are handed over.

Accessibility should be considered during planning and implementation, rather than left to a final automated score. W3C’s Easy Checks can help a team perform an initial review, but these checks are not a comprehensive accessibility evaluation.

For a replacement site, agree which URLs remain and which genuinely need to change. Google’s site-move guidance recommends mapping old URLs to their appropriate new destinations when URLs change. Do not make unnecessary URL changes just to make a rebuild feel new.

Copy this website brief template

Use the prompts below as the first draft of your project document. “To be confirmed” is a useful answer when it identifies a decision that still needs work.

Business and current website: What do we offer, and what is the existing URL?
Reason for the project: What is not working, or what has changed?
Primary goal: What should the website help people do?
Priority audiences: Who are they, and what information do they need?
Key journeys: What should happen before and after the main action?
Pages and templates: What exists, what is new and what can share a layout?
Content and assets: What is ready, who supplies the rest and when?
Features and systems: What must work at launch, and what can wait?
Design direction: What should stay, change or guide the visual approach?
Editing needs: Who updates the website, and how often?
Budget and recurring costs: What range and responsibilities should the estimate cover?
Timing and dependencies: What is the target date, and what could affect it?
Decision-maker: Who approves scope, content and the final release?
Acceptance and handover: How will we test delivery, and what must we receive?
Open questions: What needs discovery before a commitment can be made?

Use the brief to compare proposals

Send the same core brief to the partners you are considering. Look beyond the headline price: compare deliverables, assumptions, exclusions, content responsibilities, review rounds, recurring costs and post-launch support.

A brief is the starting point for agreement, not a substitute for a detailed scope or contract. Ask the chosen partner to resolve the open questions and document what is included before work starts. Keep changes visible so that the final website is assessed against the decisions you actually agreed.

You can start a conversation with an incomplete brief. Share your website requirements with OctalFox and explain the business problem, your priority audience and the parts you are still deciding. We can help turn that starting point into a practical design and development scope.