websites
How to brief a business website project
You do not need a technical specification to start a website conversation. A useful brief explains who the site serves, what they need to do and what must be ready for launch.
Start with the visitor and the outcome
Name the people you want to reach and the action that matters: request a quote, book a conversation, buy a product or find service information. Pick one primary action for the first version.
For example, a local service company might need visitors to understand its service area, see its work and send a requirement with contact details. That is a clearer starting point than “make a modern website”.
List the pages and who supplies the content
Write a short page list and the purpose of each page. A starting set might be Home, Services, About, Work and Contact. A store or customer portal needs a different scope.
Record who will provide copy, branding, photographs, product data and permission to show client work. Mark anything that still needs to be created. Content preparation is part of the schedule, not something to discover on launch day.
Separate launch features from later ideas
Describe the task a feature supports. Instead of “add a dashboard”, explain who signs in, which records they can see and which actions they can take. Include existing tools, payment providers or booking systems that must connect.
- Needed at launch: the visitor can understand services and send an enquiry.
- Later: multilingual pages, advanced reporting or a customer portal, unless the business needs them immediately.
- To discuss: features where the right approach is still uncertain.
State the budget, timing and existing setup
Share a working budget range and explain any genuine deadline. List the current domain, hosting, content system and important URLs. Mention who controls these accounts; share actual credentials only through an agreed secure method after scope is established.
For a replacement site, identify pages and search traffic worth preserving. Agree a URL/redirect plan, backup and rollback route before switching the live site.
Agree what “ready to launch” means
Write checks that you and the developer can both review: key pages work on mobile, the enquiry reaches its destination, important links open correctly and the agreed editor can update content. If sign-in or checkout is included, test those full journeys separately.
Confirm content approvals, accessibility expectations, search titles/descriptions, analytics choices, ownership, recurring costs and support responsibilities. Search visibility takes ongoing work; a launch checklist is not a ranking guarantee.
A brief you can adapt
We run [business] for [audience]. The website should help visitors [primary action]. We need [pages] and [essential features]. Our current site is [URL]. We will supply [content]; we need help with [missing items]. Our budget range is [range] and our target date is [date and reason]. The person approving the work is [role].
Leave unknowns marked “please advise”. You can start the conversation without filling every gap.