A good website brief explains the business situation, audiences, goals, scope, content, brand, functional requirements, constraints, stakeholders and success measures. It gives direction without prescribing unsupported solutions.
Key takeaways
- Describe the problem and desired outcome before features.
- Name audiences and priority journeys.
- State constraints and unknowns honestly.
- Provide one accountable approval owner.
Who this is for: Founders and marketing teams preparing to hire a web designer, freelancer or agency.
Brief versus requirements document
The brief provides context and direction. A requirements document defines detailed behavior and acceptance. Small projects may combine them; complex projects should keep the brief readable and attach detailed specifications.
The essential sections
Complete these before asking suppliers for a proposal.
- 1Company and current situation
- 2Business outcome and success measures
- 3Priority audiences and journeys
- 4Scope and important page types
- 5Content status and ownership
- 6Brand assets and constraints
- 7Functional needs and integrations
- 8Reference sites with reasons—not requests to copy
- 9Timeline, stakeholders and approval process
- 10Budget context or procurement constraints
Annotated example
The example focuses on decisions rather than adjectives.
## Outcome
Increase qualified consultation requests from SME decision-makers.
## Primary audience
Operations leaders comparing website redesign partners.
## Priority journey
Search/article -> redesign service -> evidence -> consultation.
## Scope
Homepage, 5 service templates, resources, 3 case studies, contact.
## Constraints
Existing domain and high-value URLs must be preserved.
## Success
Track qualified form submissions and service-page assisted conversions.Common briefing mistakes
A brief should reveal uncertainty rather than hide it.
- Make it modern with no business outcome
- Copy this competitor without explaining why
- Listing pages without journeys
- Leaving content responsibility undefined
- Giving every stakeholder final approval
- Setting a date without dependencies
- Requesting SEO without defining migration or measurement
Use the brief during delivery
Revisit the outcome and audience during sitemap, design and scope decisions. When a new request appears, ask whether it supports the brief or belongs in a later phase.
How to use this guide with your team
Use this guide as a working conversation document rather than a one-time article. Ask the person responsible for sales, marketing, operations and technology to review the same assumptions; each function usually sees a different dependency.
Where the team cannot answer a question, label it as a discovery item with an owner and decision date. An acknowledged unknown is manageable. A hidden assumption usually appears later as delay, rework or an unexpected cost.
The final plan should be understandable to someone outside the project. Plain language creates better accountability than a document that only a designer or developer can interpret.
Practical next steps
Use the following actions as a short working session. Record decisions, owners and unresolved questions so the article becomes an implementation aid rather than passive reading.
- 1Confirm the primary audience and desired action.
- 2List missing content, access and decisions.
- 3Assign one owner to every dependency.
- 4Separate launch requirements from later improvements.
- 5Review scope before requesting or approving a quote.
Frequently asked questions
Should the brief include a budget?
Budget context helps suppliers recommend an appropriate approach. If procurement prevents disclosure, define priorities and ask for phased options with explicit scope.
How long should a website brief be?
Long enough to make the important context and constraints clear. A concise 2–5 page brief with linked evidence is often more useful than a long unstructured document.
Sources and further reading
Last reviewed: September 1, 2026
