How to prepare a website project: a brief you can actually use
Prepare a practical website brief covering visitors, pages, content, integrations, responsibilities and launch checks, with a small-business example.
Before requesting a price, describe the action your website should make easier. “A modern website” leaves most of the work undefined. “Help local homeowners understand our services and send a useful project enquiry” gives design, content and testing a direction.
A short, specific brief is enough to start a conversation. You do not need to choose a framework or write a complete technical specification first.
Describe the visitor and the main task
Identify who arrives, what they need to know and what they should do next. Choose a primary action for each important page: call, enquire, book, read or buy. Include practical constraints such as a service area, opening hours, language or information needed before accepting an enquiry.
For LR Studios, the public task is to discover a mobile game and reach the relevant download platform. For MAHVU, the scope also includes association members publishing content. These projects need different pages and workflows even though both are websites.
Use this one-page example as a starting point
The following is an illustrative brief for a tradesperson, not a claim about a client project:
| Topic | Example requirement |
|---|---|
| Audience | Homeowners within the business's real service area |
| Main action | Request a quote with location, work type and preferred contact details |
| Pages | Home, services, selected projects, about and contact information |
| Evidence | Authorised project photographs with a short description of the work |
| Content owner | Business supplies service details; writing and editing responsibilities are agreed |
| Integrations | Enquiry delivery to a named business address; no online payment in this first version |
| Editing | Explain who changes services, hours and photographs after launch |
| Acceptance | Mobile navigation works and a test enquiry reaches its agreed destination |
Replace each answer with your own facts. If a requirement is unknown, mark it as a decision to resolve rather than assuming it is included. The tradesperson website page gives a more focused starting structure.
Inventory the content and access
For each page, list the text, photographs, documents and links needed. Name the person providing and approving them. Confirm permission to use client logos, testimonials and images before planning them into the design.
For an existing website, record the current URLs and the pages that receive useful visits or enquiries. Include domain, hosting, analytics and content-management access in the handover checklist. Transfer access through an appropriate secure method, not by embedding passwords in the brief.
Separate the first release from later ideas
Identify what must be working on launch day and what can wait. A contact request form and a fully synchronised booking system are different deliverables. A gallery and an online shop are different scopes too.
Set a target date with its reason, a budget range and the dependencies that could affect delivery. Content approval, photography and third-party account setup can determine the schedule as much as development.
Define how you will accept the work
Use observable tasks: find a service on a phone, change a piece of content, submit a test enquiry, navigate with the keyboard and switch to the corresponding translated page. Decide who checks each task and how remaining issues are handled.
Also define what happens after launch: support contact, maintenance, renewals, content updates and access if another provider takes over. The maintenance checklist helps make that discussion concrete.
Once these decisions are recorded, compare proposals against the same brief. The quote guide explains the deliverables and exclusions to check. You can then discuss the project with a clear starting point and a list of decisions still open.