A brief is not a long document. It is the shortest version of the project that lets two people agree on what “done” means before the work begins.
Name the outcome
Describe what will be different when the project is finished. “A new homepage” is a deliverable; “a homepage that helps a first-time visitor choose a service” is an outcome.
List the constraints
Write the deadline, budget, brand rules, technical limits and anything the client does not want. Constraints are part of the brief, not a surprise at review.
Define success
Choose two or three observable signs that the work is ready. A success criterion can be a content requirement, a review approval or a technical check.
Name the reviewer
Say who can approve the work and whether feedback will be consolidated. A brief without a decision-maker creates a review by committee.
Brief fields
| Item | Example |
|---|---|
| Field | Example |
| Outcome | A clear service page |
| Audience | First-time visitors |
| Reviewer | One named owner |
| Done | Approved copy + mobile check |
What to watch for
- Writing a list of deliverables without an outcome.
- Leaving the reviewer unnamed.
- Treating constraints as optional.
- Using the brief only at kickoff and never at review.
A useful next step
Use the brief as the reference at the first review. If a request is outside it, log the change rather than silently expanding the work. If the client cannot name one reviewer, pause the kickoff and ask for one decision owner. A brief with three approvers is not a brief; it is an invitation to contradictory feedback. Put the decision owner’s name and the review date in the brief itself. Ask the client to approve the brief in the same thread where it was sent.