How to write a website brief that keeps your project focused

You do not need a finished sitemap or a technical specification to start a website conversation. You do need enough context for a partner to understand the business, identify unanswered questions, and propose a realistic scope. A useful brief makes that context easy to find.

1. Explain the business and the reason for change

Start with a plain description of what your business offers, who buys it, and how the website fits into that relationship. Mention any change that makes the project timely: a new service, a different audience, a rebrand, or a growing need to manage content internally.

Then explain what is not working. “The site looks old” is useful feedback, but a stronger brief also describes the consequence. Do customers misunderstand the offer? Does the sales team repeatedly send the same explanation? Is a key page difficult to update?

If you have not agreed on the problem yet, work through the website redesign checklist before making a detailed list of pages. It is easier to discuss scope when the reason for the work is clear.

2. Describe the audience and the desired action

Identify the people the website needs to help. Describe what they already know, what they are uncertain about, and what they need before taking the next step. Concrete observations from sales or support conversations are especially useful here.

Pair each main audience with a task. For example: a business owner needs to compare service options; a marketing manager needs to assess relevant work; an existing customer needs to find support. These tasks are more useful than a long list of demographic labels without context.

State the business goal alongside the customer task. If the goal is better-qualified enquiries, explain what a useful enquiry contains and what currently tends to be missing. A partner can then consider the content and journey that support it.

3. List the content and capabilities you need

Provide an initial page list, even if it is provisional. Note which material already exists, which needs updating, and which has to be created. Identify who can approve service descriptions, project stories, photography, and other business information.

Describe capabilities in terms of the job they need to do. “Our team needs to publish articles without changing page layouts” gives more useful context than a platform name alone. If a system has already been chosen, explain why and identify any constraints.

• Content: services, projects, articles, team information, or other recurring records.
• Connections: booking, enquiries, customer systems, or analytics.
• Editing: who updates the website and how often.
• Migration: pages, files, or records that need to move from the current site.

4. Be clear about boundaries and approvals

Share a budget range and the reason behind any deadline. A fixed event date creates a different planning problem from a preferred launch month. If there are competing priorities, identify what can move and what cannot.

List the people involved in feedback and name the person who can approve the final direction. Explain whether legal, technical, or brand reviewers need to participate. This helps your partner plan reviews around actual decisions.

References can help, but explain what you value in each one. You might like the clarity of a service page, the restraint of its typography, or the way a project is explained. That context is more actionable than asking for a combination of several entire websites.

5. Use this brief outline to get started

A shared document with these headings is enough to begin a productive conversation:

1. Business: what we do, who we serve, and why the project matters now.
2. Current problem: what is difficult today and what evidence we have.
3. Audience: the main visitors, their questions, and their next step.
4. Scope: likely pages, recurring content, and required capabilities.
5. Content: what exists, what is missing, and who owns it.
6. Constraints: budget range, timing, systems, and dependencies.
7. Decisions: reviewers, approver, and responsibilities after launch.

Mark unknowns openly. A brief is the starting point for discovery, so it does not need to pretend every answer is settled. The purpose is to make the next discussion specific enough to produce a useful recommendation.

You can also review selected brand and website projects to see how different businesses present their offer. Use the examples to explain your priorities, then let the project requirements guide the final approach.