A website brief does not need to be a polished presentation. It needs to make the project understandable to someone who does not yet know your business.
That means explaining why the website needs to change, who it must serve and what has to happen for the project to be useful. You do not need to arrive with every page designed or every technical decision made.
A short, honest document with clear priorities is a better starting point than a long list of features copied from other websites. Use the structure below to prepare a brief you can share with potential web partners. If the priorities are still unsettled, first use our guide to choosing a B2B redesign scope to decide what should stay, change or wait.
1. What a website brief is actually for
The brief creates a shared starting point. It helps a designer understand the work, identify missing information and explain what their proposal includes. Sending the same brief to each supplier also makes their responses easier to compare.
It is not a finished specification or a substitute for a conversation. Mark uncertain points as questions. “We need a better way to handle booking enquiries” is useful even if you do not know whether the answer is a short form, a booking tool or a clearer explanation of the process.
2. Start with the business objective
Explain what has prompted the project. Perhaps the business now serves larger clients, a new service is difficult to explain, or the current site sends too many unsuitable enquiries to the team.
Be specific about the change you want. “Help prospective clients understand our ongoing support service before contacting us” gives the project more direction than “make the website modern”. Choose the main objective and name any secondary priorities so every request does not become equally urgent.
3. Define the audiences that matter
Describe the people making the buying decision, what they need and what might make them hesitate. Job roles, buying situations and levels of familiarity with your service are usually more useful here than a fictional customer biography.
For example, a facilities manager comparing maintenance providers may need coverage, response arrangements and evidence of relevant experience. A finance director approving the same purchase may need a clearer account of scope and responsibility. Identify the priority audience without pretending everyone arrives with the same questions.
4. Explain what is wrong with the current website
Include the current address and separate what you know from what you suspect. “Customers regularly ask whether we offer this service” is evidence. “The navigation may be hiding it” is a possible explanation to investigate.
Note what should stay as well: useful service content, established page addresses, a reliable enquiry form or project examples that customers mention. Our website redesign approach starts with understanding the existing site and the business it needs to represent.
5. List the services and content the new site needs to support
Make an inventory of what visitors need to understand: services, sectors, projects, people, technical information and routes to contact. Mark material that exists, needs updating or must be created from scratch.
A provisional page list helps establish scope, but leave room to improve the structure. Different services may need separate pages when they answer genuinely different customer needs. Repeating similar copy across pages just to target more keywords is not a useful requirement.
For a focused professional practice, a concise explanation of expertise and how an engagement works may matter more than a large site. Our websites for professional businesses reflect that need for clarity and credible detail.
6. Identify required functionality
Describe what people must be able to do. Separate launch essentials from ideas that could wait, and name any existing systems the website must use.
- Enquiry forms: what information is needed, and who receives it?
- Bookings: a request for an appointment or a confirmed slot in a calendar?
- Payments: what is being sold, and which payment service is already used?
- Integrations: which CRM, mailing platform or product database is involved?
- Editing: who needs to update which parts of the website after launch?
“A booking form” can describe very different amounts of work. Explaining the steps and the people involved is more useful than naming a feature alone.
7. Clarify who will provide the content
State who is responsible for copy, photography, branding, project information and final approval. Say whether supplied copy will be a finished draft or rough notes that need shaping.
List existing assets and any gaps. Check that images and testimonials can be used, and flag confidential work early. Content preparation needs time in the schedule; it should not become an unspoken task for whoever notices it last.
8. Include existing SEO and migration considerations
If you are replacing a live website, identify valuable pages, useful downloads and any planned domain or URL changes. Note whether Search Console and analytics are available and who controls the relevant accounts. Share access securely when needed; do not put passwords in a brief sent to several bidders.
Google’s site-migration guidance recommends mapping changed URLs, setting up permanent redirects and updating internal links and sitemaps. Ask who will plan and test that work rather than assuming a new design includes it automatically.
9. State the timeline and approval constraints
Distinguish a firm deadline from a preferred launch date. If a trade event, contract or campaign sets the deadline, explain what must be ready for it. Include dependencies such as photography, technical information and access to the current hosting account.
Name one person who can gather feedback and say who gives final approval. A project with three directors reviewing every page needs that decision time reflected in the programme. Agree how feedback will be consolidated before contradictory instructions reach the designer.
10. Explain budget expectations honestly
A realistic range helps a supplier propose a proportionate scope. Explain whether it covers the initial build alone or also content, photography, hosting and ongoing support, and clarify whether VAT is included in the figure you are discussing.
If the budget is not yet agreed, say so. Ask for a recommended scope with optional items priced separately. That gives you something concrete to evaluate without suggesting that every possible feature must fit an undisclosed limit.
11. Say what success should look like
Connect success to the objective. It might mean more relevant enquiries, fewer repetitive service questions or a team that can publish project updates without outside help. These are goals to assess, not outcomes a designer can guarantee.
Separate launch acceptance from longer-term business measures. Working forms, usable mobile pages and agreed content can be checked before launch. Enquiry quality needs a baseline, a review period and someone responsible for recording it. Decide what information you actually need to collect.
12. What not to put in a website brief
Avoid prescribing every layout, animation or technical choice before the problem has been explored. State genuine requirements, such as an existing brand system or a necessary integration, and distinguish them from preferences.
References are useful when you explain why you chose them. “This service page makes a complicated offer easy to understand” is actionable. “Make ours look like this” leaves out the reason. You can use our Selected Work to discuss clarity, navigation and the way different businesses present their information.
Leave out unsupported promises, unnecessary jargon and a long wish list with no priorities. The brief should help someone make decisions, not make a small project look more complicated than it is.
13. A simple website brief template you can copy
Copy these headings into a document and add a few useful sentences under each. Where an answer is unknown, write down the question you need help resolving.
- Business overview: What do we do, where do we operate and what makes our offer relevant?
- Project objective: What business problem should the website help address?
- Target audiences: Who needs the site, and what must they understand or do?
- Current website and problem: What is the address, what is not working and what should be kept?
- Required pages or content: Which services, evidence and information must be covered?
- Required functionality: What must users and staff be able to do at launch?
- Existing assets: What copy, branding, photography and project material can we supply?
- SEO and migration: Which pages matter, will URLs change and what needs protecting?
- Responsibilities: Who supplies content, reviews work, approves it and looks after the site?
- Timeline: What is the target date, why does it matter and what are the dependencies?
- Budget range: What is available, what must it cover and which extras can wait?
- Success measures: What will we check at launch and review once people use the site?
Once the brief is useful enough to discuss, share it. You do not have to solve the whole project before asking for help. Our guide to comparing web design partners explains the questions to ask when the proposals come back.