A good website brief does not prescribe every design decision. It explains the business problem clearly enough for a capable team to recommend the right solution.
Without that foundation, suppliers are forced to guess. Proposals become difficult to compare, hidden requirements appear halfway through production and feedback is guided by personal preference rather than an agreed objective.
Use the following template as a working document. Short, specific answers are more useful than polished corporate language.
Project summary
Start with a paragraph that a person outside the business can understand.
Template
We are [organisation], providing [service/product] to [primary audience]. We need to [build/redesign/refresh] our website because [business reason]. The new site should help us [priority outcome] while also [secondary outcome]. We aim to launch by [date or business event], subject to a realistic delivery plan.
Explain what prompted the project now. A new offer, poor lead quality, rebrand, technical limitation or expansion into a new market all create different priorities.
Business objectives
List no more than three primary objectives. Make them observable where possible.
Examples include:
- Increase qualified enquiries for a priority service
- Make the company’s new positioning clear
- Reduce repetitive pre-sale questions
- Support recruitment in specialist roles
- Consolidate several outdated websites
- Improve mobile usability and editing efficiency
“Create a modern website” is not yet an objective. Modernity is subjective; a clearer offer or faster task completion can be evaluated.
Measures of success
Record the signals you will monitor after launch. These may include suitable enquiry submissions, booking completion, calls from priority landing pages, resource engagement or the time required to publish updates.
Do not promise an arbitrary uplift without evidence. Establish current benchmarks first and agree how tracking will be configured.
Audiences and user needs
Describe the most important audience groups in practical terms.
For each group, complete:
- Who they are: role, situation or type of organisation
- What triggers the visit: problem, event or question
- What they need to understand: key information or reassurance
- What may prevent action: risk, confusion or objection
- Desired next step: enquiry, booking, purchase, application or another action
Avoid invented personas filled with irrelevant hobbies. Useful audience descriptions explain buying context and information needs.
Positioning and core message
Answer these questions in plain English:
- What do you provide?
- Who benefits most?
- What valuable outcome do you create?
- What makes your approach credibly different?
- What evidence supports that difference?
If stakeholders cannot agree, flag positioning as part of the project rather than hiding the uncertainty. Design cannot permanently solve an unresolved proposition.
Scope and content
Current website
Provide the URL and explain what works, what fails and what must be protected. Include available analytics, user research, search data and customer feedback.
Identify high-value pages, downloadable assets, integrations and content that must migrate. Note any domains, subdomains or separate sites involved.
Proposed pages
Create an initial sitemap or page inventory. For each page, note whether content will be retained, rewritten or created.
Do not worry if the structure is not final. A supplier can improve it, but needs enough information to estimate the content and template work.
Content responsibilities
Specify who will provide:
- Copy and subject-matter input
- Photography, video and illustration
- Case-study and testimonial approval
- Legal or compliance wording
- Product or service data
- Translations, if required
Include internal approval time. Content is often the critical path, even when it is described as “already available”.
Functional requirements
Separate essential functions from future ideas.
Potential requirements include:
- Enquiry and application forms
- Booking or payment
- CRM and email-platform integration
- Search, filtering or resource libraries
- Customer accounts
- Multi-location or multilingual content
- Careers and vacancy feeds
- Analytics and consent management
Describe the user need behind each feature. “We need a calculator” is less useful than “Visitors need to estimate which service tier fits before speaking to sales.”
Brand and design direction
Supply brand guidelines, logos, font licences and image libraries. Explain how the organisation should feel—perhaps assured, direct and human—but connect adjectives to examples.
Include websites you consider effective and explain why. Navigation, editorial restraint and mobile clarity are actionable observations; “make ours look like this competitor” is not a useful design strategy.
Also note what to avoid, especially where previous designs have created inconsistency or accessibility problems.
Technical, search and accessibility needs
Record known constraints:
- Existing content management system and hosting
- Required internal systems or APIs
- Browser or device requirements
- Accessibility standard or organisational policy
- Security and data-handling expectations
- Search visibility and migration priorities
- Analytics, tag management and reporting accounts
List the people or suppliers who control domains, hosting and third-party tools. Access delays can hold up an otherwise finished launch.
Governance, budget and timing
Name the day-to-day project owner and final approver. Explain which specialists or departments must be consulted and how feedback will be consolidated.
Provide an honest budget range if possible. This helps a partner propose the right balance of research, content, bespoke design and functionality. Hiding the budget rarely produces more inventive thinking; it often produces proposals based on incompatible assumptions.
Include the desired launch date, what drives it and whether scope can be phased. Mark review periods, holidays and board approvals that affect the schedule.
A copy-ready brief checklist
Before sending the document, make sure it includes:
- Organisation and project summary
- Reasons for change
- Up to three business objectives
- Priority audiences and actions
- Positioning and evidence
- Initial sitemap and content ownership
- Essential and later functionality
- Brand assets and design context
- Technical, SEO and accessibility requirements
- Stakeholders and approval process
- Budget range and timing constraints
- Proposal evaluation criteria
Invite suppliers to state their assumptions, exclusions and recommended changes to the brief.
Frequently asked questions
How long should a website brief be?
Long enough to remove major ambiguity, but short enough to be read. A concise document with useful appendices is better than a lengthy presentation that avoids decisions.
Should we specify the technology?
Only when there is a genuine organisational constraint. Otherwise, describe the editing, integration, security and performance needs and ask suppliers to recommend an approach.
Can an agency help write the brief?
Yes. A discovery engagement can turn unclear requirements into a brief, sitemap and delivery roadmap before the full build is commissioned.
Turn the brief into a decision tool
The brief should align your own team as much as it informs a supplier. If it exposes disagreement, that is useful progress made before expensive production begins. Yieldberg Studios can help you shape an initial idea into a strategic, build-ready website brief.