The brief is the bridge between “we need a better website” and work a provider can estimate. It should be specific enough to expose uncertainty without pretending every answer is already known. If two capable providers read the same brief, they may propose different solutions, but they should understand the same business problem and boundaries. Use this guide with the other resources in the website hiring and project-planning hub.

Begin with the change, not the deliverable

Weak openingDecision-ready opening
Business needWe want a modern, cutting-edge websiteQualified prospects cannot tell which of our three services fits, so sales spends the first call correcting basic misunderstandings
AudienceEveryone who needs our servicesOperations leaders at regional manufacturers comparing maintenance partners before requesting a site visit
SuccessMore traffic and conversionsMore complete assessment requests and fewer inquiries from projects we cannot serve
ScopeAbout ten pages, maybe moreA shared service framework, three service pages, proof, company, resources, and a qualified inquiry path; recruiting remains on the current system

Design adjectives such as clean, bold, premium, or friendly can help later, but they are interpreted differently by different people. A business condition is easier to investigate. Include what happens now, why it matters, and what should be different after launch. Do not promise an exact sales or ranking result the website alone cannot control.

The 12-part website brief

Write these sections in plain language

01

1. Organization and offer

Explain what the business sells, who buys it, the geography served, the sales process, meaningful differentiators, and any terms an outsider will not understand.

02

2. Reason for the project

Describe the event or problem behind the work: an outdated position, new service, difficult editing, poor mobile use, fragmented sites, weak lead quality, or a platform that no longer fits.

03

3. Primary users and tasks

Name the most important visitor groups and the job each needs to complete. Include known barriers, questions, context of use, and accessibility needs rather than demographic labels alone.

04

4. Evidence

Link to analytics, search queries, recordings, support tickets, sales objections, customer interviews, form data, usability findings, and competitor notes. Mark assumptions as assumptions.

05

5. Desired outcomes

State the behavior or operational change expected, such as completing a qualified estimate request, booking a consultation, finding a location, or reducing repetitive support calls.

06

6. Measurement

Define the events and business signals that will indicate progress. Google Analytics calls an action important to business success a key event; choose meaningful actions rather than treating every page view as success.

07

7. Scope and content model

List known pages, reusable content types, languages, locations, products, resources, and user flows. Label undecided areas that need discovery instead of hiding them.

08

8. Functions and integrations

Describe what forms, booking, search, payments, CRM, email, inventory, maps, logins, or other systems must do. Include system owners and available documentation.

09

9. Content and assets

Assign owners for research, copy, editing, photography, video, illustrations, legal text, testimonials, case studies, downloads, product data, and migration cleanup.

10

10. Constraints and requirements

Record platform obligations, security and privacy reviews, accessibility target, browser support, hosting, data handling, branding, legal requirements, procurement rules, and deadlines that cannot move.

11

11. Delivery and decisions

Name the project owner, day-to-day contact, reviewers, final approver, review windows, meeting rhythm, preferred tools, and the process for resolving conflicting feedback.

12

12. Budget, timing, and non-goals

Give a budget range or decision threshold, explain the date and its reason, and explicitly list work not included. Non-goals protect the main outcome from attractive distractions.

A fill-in framework you can actually send

PromptWhat to writeExample
This project is necessary because…Observable current conditionVisitors use the general form for support, sales, and jobs, and staff manually reroutes every message
The first audience is…Specific person in a buying or service situationA facility manager checking emergency coverage on a phone outside normal hours
They must be able to…Important user taskConfirm coverage, understand response steps, and call the correct number
We know this because…Source of evidenceCall logs and form records show repeated misrouting
We will know it is improving when…Measure and review periodEmergency calls use the correct path and general-form misroutes decline after launch
The provider must account for…Constraint or dependencyThe CRM accepts only documented fields and is managed by an outside vendor
This phase will not include…Explicit non-goalThe customer account portal, which remains a separate future project

Attach evidence rather than pasting everything into the main document. A one- or two-page brief can link to a content inventory, analytics summary, brand guide, technical notes, and stakeholder list. Label each attachment with an owner and date so providers know whether it is current. A website design partner should be able to trace the proposed scope back to these inputs.

VISUAL CHECKPOINT · PlanningDo not wait for final QA to mention who must be able to use the site

W3C defines web accessibility in terms of people being able to perceive, understand, navigate, and interact with the web. Include the intended standard, required testing, content responsibilities, and known user needs before layouts and components are…

Separate requirements from possible solutions

State the need first so the provider can test the solution.

Prescribed solutionUnderlying requirementQuestion to resolve
Put a video on the home pageHelp first-time visitors understand the physical processWill video, a sequence of images, or a short diagram explain it most clearly and accessibly?
Add a chatbotAnswer common qualification questions outside office hoursCan structured page content and a better form solve this with less maintenance?
Use a mega menuMake many services findableHow do customers group these services, and how many levels are truly necessary?
Copy a competitor’s calculatorHelp buyers form a realistic budgetWhich inputs are reliable, and can the business support the estimate the tool presents?

Some solutions are genuine requirements. If an enterprise agreement mandates a platform, say so. If payment must run through an existing processor, identify it. The distinction is whether the choice has already been made for a documented reason or is simply an early idea. Honest constraints improve proposals; unexplained preferences narrow thinking.

What not to hide from potential providers

  • The current site has hundreds of URLs, even if only thirty will appear in the new navigation.
  • Several executives expect to approve the work, or a founder may override the named team.
  • No one has been assigned to write, review, or approve content.
  • A brand change, merger, new product, or system replacement may occur during the project.
  • The domain, analytics, hosting, or software account is controlled by a former employee or outside vendor.
  • A fixed launch date depends on legal review, photography, procurement, or another project.
  • Past website attempts stalled and the reason is known.

Review the brief before it leaves the business

  • A person unfamiliar with the project can explain the business problem after reading it.
  • The primary audience and its main task are specific enough to make design tradeoffs.
  • Claims are supported by evidence or clearly marked as assumptions to investigate.
  • Every required feature has a user or operational reason.
  • Content and account ownership have named people, not unnamed departments.
  • Success measures can be observed and do not depend entirely on the website.
  • Required reviewers and the final approver are identified.
  • Budget, timing, exclusions, and major unknowns are stated plainly.

The brief is ready when it creates better questions. It does not need to solve information architecture, write final copy, or choose components before the project starts. Bring it to the website kickoff checklist, then update assumptions as discovery produces evidence. Keep the original goals visible so later choices can be judged against the reason the project exists.

How long should a website design brief be?

A small-business brief is often one to four focused pages plus links to supporting material. Length is not the goal. It must provide enough information to understand outcomes, users, scope, content, constraints, measurement, budget, timing, and decision ownership.

Should the brief include websites we like?

Yes, if each example includes a specific reason tied to the project. “We like the clear service comparison on this page” is useful. A list of attractive sites with no explanation can lead the team toward borrowed style rather than the right solution.

Do we need a final sitemap before requesting proposals?

Not always. Provide the current site inventory, known required content, and your best view of the structure. If information architecture needs research, ask providers to include that work rather than forcing a premature final sitemap.

Can a designer help write the brief?

Yes. Paid discovery can be a sensible first phase when the business problem, audience, content, or technical scope is unclear. Define the discovery deliverables and make sure you can use them even if a different team performs the build.