How to write a project brief

A brief gives the project a useful starting point

A project brief is a shared explanation of what you want to improve, who it is for and what the first useful version must enable. It does not need technical language or a screen-by-screen specification. Its job is to expose the decisions that affect the shape of the work, so a developer can ask better questions and propose an appropriate scope.

Write plainly and include what is still uncertain. ‘We need customers to request a quote without calling’ is more informative than ‘we need a modern website.’ If several people will approve the project, agree on one owner who can gather feedback and make day-to-day decisions.

Project brief checklist

Use these checkboxes as a drafting aid while you gather notes. They stay in your browser and are not submitted or copied anywhere. The email button opens a separate template in your mail application for you to complete. The template includes this guide’s title, link and prompts; your checkbox selections are not copied.

• Audience: who will use the product, what context are they in and what matters to them?
• Problem and outcome: what should become easier, clearer or possible when the work succeeds?
• Core journeys: what are the essential steps a person must complete from start to finish?
• Essential features: which capabilities are required for the first useful release, and which are later ideas?
• Platforms: responsive web, iOS, Android or a specific combination—and why?
• User roles: will visitors, customers, staff, editors or administrators need different access?
• Integrations: which payment, identity, CRM, booking, analytics or internal systems must connect?
• Materials: which brand files, copy, translations, images, research and existing data are ready?
• Preferred timeline: is there a meaningful event or dependency behind the date?
• Budget: is there an optional working range that can guide priorities or phasing?
• Ongoing support: who will own content, operations, maintenance and future improvements after launch?
• Decision process: who gives final approval, and which stakeholders need to review the work?

Describe people and journeys before features

Start with the audience in concrete terms. What brings them to the product? What do they already know? Are they usually at a desk, on a phone, in a hurry or returning regularly? Useful context guides navigation, content density, accessibility and platform choices without relying on vague demographic labels.

Then write the core journeys as short sequences: discover a service, compare options, request a quote; create an account, submit information, track its status; find a recipe, save it, return while shopping. Journeys reveal the interfaces, data and decisions behind a feature name. Mark the journeys that define the first useful release and keep secondary ideas visible as later options.

Make constraints and available materials visible

State the required platforms and known integrations, including the exact provider when one has already been chosen. Mention accessibility, language, legal, privacy or compatibility needs that affect the product. If you prefer a date, explain what makes it relevant; the reason helps a developer suggest sequencing or a smaller first phase when necessary.

List what already exists: brand guidelines, copy, photography, designs, analytics, user research, product data, APIs or an older system. Add who owns each item and whether it is approved. Missing materials are normal, but knowing who will create them prevents content and design work from becoming invisible assumptions.

Treat budget, timing and support as planning inputs

A budget range is optional, but it can help the proposal choose between a focused first release and a broader scope. Share it as a planning boundary, along with priorities that must survive if trade-offs are needed. A preferred timeline should identify fixed events, external approvals and content dependencies rather than imply a delivery promise before the work is understood.

Also describe what happens after launch. A marketing site may need occasional content updates; a product with accounts and integrations may need monitoring, maintenance and an improvement rhythm. Decide whether your team will operate it, whether you want ongoing technical support or whether you need help defining that responsibility.

Send enough to begin, then refine it together

Review the checklist, gather the information you have and open the email template below. Add your answers in your own words and remove prompts that do not apply. Nothing is sent until you choose to send it from your mail application, so you can edit, save or share the draft internally first.

I can use that context to ask focused questions, identify dependencies and recommend a practical scope. If the project is still early, send the problem and essential journey rather than waiting for a perfect document. A short honest brief is more useful than a long specification built on untested assumptions.