You do not need a long specification to start a useful conversation. A short, honest brief can help everyone understand the problem and decide what to explore next. Use the prompts below and leave anything undecided marked as an open question.
What should a website project brief include?
Include the business goal, audience, essential pages and actions, existing tools, content responsibilities, budget or timing constraints and the person approving the work. Mark unknowns as open questions. Do not include passwords, API keys or private customer data.
1. Start with the business goal
Write one sentence about what the project should help people do. For example: help visitors understand our services and send a relevant inquiry. Separate the business goal from a preferred technology.
Who will use it, what are they trying to do, and what gets in their way today? Include any language, device or accessibility needs you already know about.
2. Define the first useful version
Identify the pages and actions needed for a useful first release. Keep a separate list of ideas that can wait. This makes the tradeoffs easier to discuss.
List the tools the website may need to connect to, such as a CRM, payment service or content system. Do not include passwords, API keys or private customer data in the brief.
3. Share the practical constraints
Note which copy, images, brand assets and domain accounts already exist, who owns them, and who will maintain the content after launch.
Give a working budget range if you have one, along with any real deadline and the reason behind it. If these are undecided, say so rather than making up a number.
4. Make review and handover clear
Name the person who can consolidate feedback and approve key decisions. Explain how your team prefers to communicate.
Describe the journeys that must work before launch and what documentation or training your team will need. Bring open questions into the first conversation.