A website brief is a shared description of what you want to achieve. It does not need to be a technical specification or a lengthy presentation. A clear page of notes is often more useful than a detailed document that leaves the main customer journey unexplained.
If you are approaching a website developer in Cheltenham, use this checklist to prepare the information you already know and identify the questions you want help answering. An honest "not sure yet" is a useful part of a brief.
Describe the business and the people you want to reach
Start with a plain description of what you offer. Explain who usually buys, what brings them to you and what they ask before becoming a customer.
Be specific about your service area and practical limits. A business serving Cheltenham by appointment has different information to explain from a specialist working remotely across the UK.
Include:
- The main services or products you want the site to present.
- The people or businesses each offer is intended for.
- The geographical areas you genuinely serve.
- Typical questions, objections or misunderstandings.
- Anything that makes a project unsuitable for your business.
This helps the developer shape useful content rather than filling a standard template with broad claims.
Choose the main action
Name the most useful next step for a visitor. It might be sending an enquiry, booking a conversation, calling, buying an item or reading enough detail to decide whether your service fits.
Explain what happens after that action. Who receives an enquiry? What information do they need? How will the customer know the request arrived?
If you have several audiences, identify which action belongs to each. A recruitment enquiry and a customer quotation request may need different information even if both eventually reach the same inbox.
Avoid treating every feature as equally important. Agree what would make the first version of the website successful in practical terms, such as allowing a prospective customer to select the right service and send a useful brief.
Explain the current situation
If you already have a site, include its address and what you want to keep or change. Distinguish observations from guesses.
"Several customers have asked whether we offer repairs" is a concrete observation. "Nobody likes the website" needs more investigation. Screenshots, examples of confusing pages and actual customer questions can be more useful than broad criticism.
List any tools the website relies on, such as a booking service, mailing list, payment provider or customer system. Describe what each connection does without sending passwords or sensitive customer data.
Make a content inventory
A new website needs approved material. Identify what exists, where it is stored and who can approve it.
- Brand name, logo and any existing visual guidelines.
- Current service descriptions and price information you want to publish.
- Photographs you are entitled to use.
- Genuine project examples and approved customer feedback.
- Team or founder information.
- Contact details, opening arrangements and service area.
- Existing notices or policies that need carrying across.
Flag material that needs writing or replacing. A copywriting assumption discovered near launch can affect the whole schedule.
Describe features as tasks
Instead of asking for "a portal", describe what someone should be able to do. For example: "A customer should upload a document, receive confirmation and see whether we have reviewed it."
That description exposes questions about access, information handling, notifications and administration. It also allows a developer to suggest a simpler approach if a full portal is unnecessary.
Separate features into launch essentials, useful additions and possible future work. The website project timeline guide explains why unresolved dependencies often matter more than the number of pages.
Set commercial and practical boundaries
Include a rough budget range if you have one and explain any fixed deadline. A date connected to an event, lease opening or campaign is more informative than "as soon as possible".
Name the person who will approve content and design. If several people need to review work, explain how you will combine their feedback.
State whether you want to edit the site yourself and how often. Include any existing domain, hosting or platform accounts, but share access through an agreed secure process later.
An illustrative one-page brief
Imagine a local repair business preparing its first professional site. This is a hypothetical planning example.
"Our customers are householders in Cheltenham and the nearby areas we already serve. They need to know which repairs we accept before calling. The first site should explain three service categories, show genuine examples and collect the item type and problem in an enquiry. We have a logo and photographs but need help organising the text. One owner will approve the work. Online payment can wait."
That paragraph makes several decisions visible without prescribing the technology. The next conversation can resolve missing details instead of starting from a blank page.
Use the brief as a working document
A brief should become clearer as you discuss the project. Ask the developer to identify assumptions and exclusions before agreeing a price. Use our guide to choosing a developer to compare how different people approach those questions.
For website design and development in Cheltenham, send James your notes, even if some answers are still open. The purpose of the brief is to make a useful conversation easier.