‘We need a new website’ describes a deliverable, but it leaves almost every important decision open. Who is the site for? What must those people be able to do? Who supplies the content? What is outside the engagement? A team that starts without those answers will discover the brief while producing the work.
A useful agency project brief is a shared decision record. It combines the client’s intent with the boundaries the team needs to deliver. This structure works for design, development, marketing and consulting projects without turning every engagement into the same service.
The useful idea
A brief should help the team make the next decision. If it only describes the topic, it has not defined the work.
Start with the change the client wants
Describe the situation today, the intended change and the people affected. ‘Make it modern’ is an aesthetic preference. ‘Help a first-time visitor understand our three services and choose the right enquiry path’ gives the team a concrete design problem.
Ask what evidence the client will use to judge the result. That might be a successful review against agreed requirements, feedback from representative users or a defined business measure. Do not promise an improvement in a metric that depends on activity outside your scope.
Make deliverables specific enough to review
Separate the output from the acceptance condition. ‘Brand presentation’ says what you will hand over. ‘A presentation covering the agreed identity directions, with one client feedback round recorded by the named approver’ explains how the next stage is reached.
Specify the format and the boundary when they matter. A website brief should distinguish design from development, content preparation from content entry, and initial delivery from ongoing maintenance. Ambiguity often sits between two services that sound similar.
| Vague | More useful |
|---|---|
| Website design | Design of the agreed page types for desktop and phone, supplied as reviewable design files |
| Client feedback | One consolidated response from the named approver for each scheduled review |
| Final files | The agreed formats, linked from the handover record with usage notes |
Write down the work that is outside the engagement
An out-of-scope section creates a place to discuss a new request without treating it as a personal disagreement. Keep it neutral and specific: additional page types, a second audience, translation or an unplanned integration may need a separate decision.
This is a working project record, not a substitute for your agreement. If the brief contradicts the signed scope, resolve that conflict before production begins. Do not silently use the brief to expand or narrow contractual commitments.
Connect dates to the inputs they depend on
List the assets, access, client decisions and external work needed for each milestone. Give each dependency an owner. A date without its dependencies can look certain while relying on information nobody has requested.
For example, an illustrative website project may require approved copy before final page assembly. Record the copy owner and the agreed handoff date, then explain which milestone needs it. When an input moves, revisit the affected milestone instead of allowing the team to absorb the delay invisibly.
- What input is needed, and in which format?
- Who can supply or approve it?
- Which milestone depends on it?
- What happens if it arrives later than planned?
Set the review and decision process
Choose a client approver, the people contributing feedback and a place to consolidate it. Ask the approver to resolve contradictory comments before the team begins a revision. A folder full of comments is not a decision.
At kickoff, read the brief as a series of questions: do we agree on the outcome, the outputs, the boundaries and the next review? Update the document with the answers and keep a dated record of later changes. The current version should always be easy to find.
Test the brief before the team starts
Give the brief to someone who did not attend the sales calls. Ask them to describe the first task, the condition for completing it and the question they would need answered. If they cannot do this, add the missing decision rather than another page of background.
A brief is ready when it enables action and exposes uncertainty. It does not need to pretend every decision has already been made. Label unresolved items, assign an owner and state when the team needs the answer.
One-page project brief
Use this as a working brief alongside the agreed scope.
PROJECT BRIEF Client and project: [names] Current situation: [what is happening] Intended outcome: [what should change] Audience: [who the work serves] Deliverables: [output / format / acceptance condition] Outside this engagement: [boundaries] Dependencies: [input / owner / needed by] Milestones: [review / owner / date] Client approver: [name] Open decisions: [question / owner / decision date] Current scope: [link] Version and date: [record]
Bring the context into your workspace.
Explore how Tamaam connects the relationship and the work around it. Tamaam is in development; product pages show previews and illustrative workflows. Joining early access does not start a subscription.
Found something we should clarify? Send a correction or question.
