In shortA clear website brief helps you explain your customers, services, goals, content and practical requirements before design starts.
A useful website brief explains who the site is for, what the business needs it to do and what a visitor must understand before taking action. It does not need to prescribe every colour or layout. It needs to make the important decisions visible before design begins.
Use the sections below as a working website brief template. Write in plain language, be specific where you can and mark open questions instead of pretending to know the answer. A designer can help refine the brief, but the business owner must confirm the facts.
1. Describe the business and its customers
State what the business does, where it operates and which services matter most. Describe the people you want the site to help. “Everyone” is not a useful audience. Think about the customer’s situation, what they are trying to solve and what they may need to check before contacting you.
For example, a local electrician may serve homeowners with urgent faults as well as people planning larger work. Those visitors need different information and may choose different contact routes. A therapist may need to explain qualifications, approach and how a first appointment works. The brief should capture real distinctions like these without making assumptions about what customers think.
If you have spoken to customers, note the questions they ask in their own words. The GOV.UK guide to understanding user needs recommends beginning with what people need to accomplish. That is a better foundation than starting with a list of features.
2. Set the website’s main job
Choose the primary action the site should support. It might be a phone call, quote request, appointment booking or visit to a shop. Then note useful secondary actions, such as reading a service explanation or checking credentials.
Describe what a successful visit looks like without promising a result the site cannot control. “Make it clear how to request a quote” is actionable. “Double our sales” is a business ambition, not a design specification. You can measure enquiries after launch, but demand and follow-up also influence the result.
If the current site exists, explain what is not working and how you know. Separate observed problems from guesses. For example: “The contact form does not send a confirmation” is an observation. “Customers dislike our colours” may be a hypothesis unless you have evidence.
3. List services and page requirements
List the services or products that need dedicated explanations. Identify any audience, location or process information that should be easy to find. Do not request a separate page for every possible phrase in Google. Pages should answer distinct customer needs, not repeat near-identical copy.
A simple initial list might include home, about, services, individual priority service pages, work examples, FAQs and contact. Your actual structure depends on the business. Our guide to planning the number of pages explains how to keep the structure purposeful.
For each proposed page, note the visitor’s question, the answer the page needs to provide and the next step. This makes the brief useful to both designer and copywriter. If the purpose is unclear, the page may not be needed yet.
4. Gather evidence, content and assets
List the materials you already have: logo files, photography, project examples, testimonials, qualifications, policies and service details. Note who owns each item and whether permission exists to use it. Do not use customer names, photographs or review text without the appropriate permission.
Identify information that needs checking, such as service areas, opening times, prices you choose to publish, booking rules or professional credentials. Never ask a designer to invent claims or statistics. Google's guidance on helpful, reliable content is a reminder that content should be useful and trustworthy, not merely present.
If you need new photography or copy, assign an owner and a realistic date. Missing material can delay a project or lead to generic filler. Decide whether the designer writes, edits or simply places content, and whether the final wording is approved by you.
5. Set functional and practical requirements
Describe what the site needs to do: accept enquiries, connect to a booking system, show a portfolio, support payments or provide secure client information. Name tools you already use and explain why they matter. A list of software names without a purpose can make a project harder to scope.
Include practical requirements such as mobile use, accessibility, languages, integrations, privacy and analytics. Identify constraints: existing hosting, a required launch date, a migration from another platform or limited staff time. A designer can then explain what is feasible and what needs a separate decision.
Ask who owns the domain, hosting, content management system and analytics accounts. State that the business needs appropriate access and a clear handover. The brief should not assume a supplier will remain forever.
6. Explain what good looks like
Describe the qualities that matter to your customers. Rather than “modern and premium”, say “clear enough for a first-time homeowner to compare our services and find the emergency number on a phone”. Explain what should feel familiar and what must be different from competitors.
Add reference sites only with notes about what you are pointing to. One may have a useful navigation pattern; another may communicate a service clearly. A reference is not a request to copy its design, content or identity.
Set practical review criteria: accurate content, working contact routes, clear service information, mobile usability and agreed technical checks. Agree who approves each stage and how feedback is consolidated. This avoids conflicting comments and repeated revisions.
7. Define scope, responsibilities and decisions
Write down deliverables, what is excluded, who supplies content, who approves it and what happens when requirements change. Clarify support after launch, training, maintenance and any recurring third-party services. Make sure commercial terms are written down before work starts.
Name a decision-maker and a backup contact. If several people need to contribute, decide how one set of feedback will be compiled. Small businesses can move quickly when responsibility is clear, but informal approvals can cause confusion later.
Keep a section for unanswered questions. A good brief does not hide uncertainty; it tells the designer where discovery is still needed. Some decisions can wait until the designer understands the content and customer journey.
A copy-and-fill brief
- Business and location:
- Main services:
- Priority customer groups:
- Customer questions or barriers:
- Main website action:
- Existing site and what needs attention:
- Required pages and purpose of each:
- Content and assets available:
- Integrations and functional needs:
- Domain, hosting and account ownership:
- Accessibility, privacy or technical requirements:
- Launch constraints and dependencies:
- Who supplies, reviews and approves content:
- What is out of scope:
- Open questions:
Our website design and SEO service begins with the business and its customer journey, then scopes the work. If you want help turning these answers into a project, talk to us. The figure is discussed once the scope is understood.
Website brief template: copy and complete
Copy this website brief template into your project document. Use plain language. Write “to confirm” where an answer is not known.
Business name and service area:
What the business does:
Priority services and customers:
Customer questions before contact:
Main website goal and desired action:
Current website and known problems:
Required pages, with each page's purpose:
Content, photography and proof available:
Features or integrations, and why needed:
Domain, hosting and account owner:
Accessibility, privacy and security needs:
Launch constraints and dependencies:
Who supplies content and approves decisions:
Included work and exclusions:
Open questions to resolve:
We use a brief to expose decisions before design: who the page serves, what it must explain, what action it supports, and which facts still need confirmation. We do not treat a reference website as a specification or fill gaps with invented claims. During a project, we confirm the scope with the owner, map pages to distinct customer needs and test the agreed enquiry path before handover. This makes the brief a working record, not a form that disappears after kickoff.
GOV.UK's user-needs guidance supports starting from what people need to do. Google's SEO Starter Guide is useful when considering how page structure helps people and search engines understand content.
Frequently Asked Questions
Do I need wireframes in my brief?
No. Explain the needs and priorities first. Wireframes are a design-stage tool, unless you already have a specific structural requirement to document.
Should I include competitors?
You can name relevant alternatives and explain what customers compare. Do not ask the designer to copy a competitor. Focus on the difference your business can prove.
What if I do not know my target audience?
Start with the customers you serve well today and the work you want more of. Mark assumptions clearly and gather evidence before treating them as facts.
A good brief makes the project easier to discuss, price and test. It gives the designer enough context to challenge unnecessary features and focus on what customers need. Start with the goal, not the colour palette.
