What is a Brief?
Brief
A brief is a short document, written before work starts, that states the goal, audience, and constraints for one piece of work.
A brief is a short document written before work begins. It states what the work needs to accomplish, who it's for, and what constraints shape it, brand guidelines, a deadline, a budget ceiling, a technical limitation. A brief is faster and narrower than a project charter: it covers one piece of work, not a whole project's authorization and team structure.
Briefs show up across creative and technical work under different names. A design brief tells a designer what problem a layout needs to solve. A content brief tells a writer the topic, audience, and word count before a draft starts. A campaign brief sets the objective and channels for a marketing push. Each is a variation on the same idea: write down what's needed before someone starts producing it.
A brief isn't the same as the client briefing form covered elsewhere in this glossary, that's a specific structured questionnaire a CRM sends to a client at project intake. A brief is broader: it can come from a client, from an account manager translating a client conversation, or from a product owner writing for an internal team, and it gets written for individual pieces of work throughout a project, not only at kickoff.
Types of Briefs Teams Use
The word "brief" covers several document types that share a structure but differ in what they focus on.
- Creative brief: sets the concept direction and tone for a design or branding project
- Design brief: narrower than a creative brief, focused on one deliverable, a page layout, a UI screen, a print piece
- Content brief: topic, audience, word count, and messaging requirements for a piece of writing
- Technical or dev brief: functional requirements, constraints, and integration points for a build
- Campaign brief: objective, audience, channels, and budget for a marketing push
What Every Brief Needs, Regardless of Type
Different brief types emphasize different details, but five elements show up in nearly every working one.
- Objective: the specific outcome this piece of work needs to produce
- Audience: who it's for and what they care about
- Constraints: brand guidelines, technical limits, budget ceiling, deadline
- Reference points: examples of the tone or approach to aim for, and to avoid
- Success measure: how the team will know the output met the brief
Brief vs Client Briefing Form vs Charter vs Scope
These four terms get used loosely, but they answer different questions at different points in a project.
| Document | Answers | Covers | Written by |
|---|---|---|---|
| Brief | What does this piece of work need to achieve? | One deliverable or workstream | Account lead, creative director, or product owner |
| Client briefing form | What does the client want from the whole project? | The full project, collected once at intake | The client, via a structured form |
| Project charter | Is this project authorized, and under what terms? | The project's authority, budget, and boundaries | Project manager, signed by a sponsor |
| Project scope | What will and won't be delivered? | The full list of in-scope and out-of-scope work | Agency, based on the brief and charter |
Who Writes the Brief
A brief doesn't have to come from the client. On most agency projects, the account manager writes it after a client conversation, translating what the client said into a document the creative or technical team can act on directly. This translation step matters: a client says "make it feel more premium", and the brief needs to turn that into something specific enough to design against, fewer colors, more white space, a serif headline font, three reference sites.
For internal teams without a client, the brief comes from whoever owns the outcome, a product manager writing one for a feature, a marketing lead writing one for a campaign. The discipline is the same either way: write down the goal and constraints before work starts, instead of letting them surface piecemeal during production.
A Worked Example: A Brief That Saved a Revision Round
A 7-person content studio takes on a blog post for a SaaS client. The account manager sends a one-paragraph brief: "Write about our new integration feature, 800 words, for existing customers." No audience detail, no angle, no examples.
The writer delivers a draft explaining the integration in technical terms aimed at developers. The client wanted something aimed at the marketing managers deciding whether to turn the feature on for their team, a different audience entirely. The draft gets rejected. A second draft takes another 3 hours to rewrite from a different angle, on a piece originally scoped for 2.
The studio changes its brief template for the next post: objective (drive activation of the new feature), audience (marketing managers at existing customer accounts, not developers), tone (practical, not technical), and one example of a past post that hit the right register. The next three posts in the series each clear review on the first draft.
The fix cost 15 minutes of writing a fuller brief. The problem it prevented cost 3 hours of rework on a single post, and would have repeated across the rest of the series if the template hadn't changed.
Briefs in Melororium
Canvas gives every project a single shared document, built for exactly this: the brief and the decisions made from it staying visible past the kickoff call instead of living in someone's inbox. Write the brief directly in Canvas using headings, checklists, and lists, and it sits next to the project's task board where the whole team can reference it, not attached as a file nobody opens again.
Because Canvas is collaborative and live, a brief can be revised in place when a client changes direction, with the update visible to everyone working on the task immediately instead of arriving three replies deep in an email thread. Included in every plan, Starter at $29/mo for 4 users through Studio at $119/mo for 25 users.
In Melororium
Write and store project briefs in Melororium Canvas
Common mistakes with brief
What teams get wrong most often, and what to do instead.
- 1
Writing the brief after work has already started
Letting the team start producing before the goal and constraints are written down. Whatever gets built first sets a default direction that's hard to walk back.
- 2
An objective too vague to design against
Writing "make it feel more premium" or "something modern" with no specifics underneath. A brief that can't be checked against the finished work isn't a brief, it's a mood.
- 3
No named audience
Skipping who the piece is for. A design or a piece of writing built for an unspecified audience usually ends up built for whoever wrote the brief, not the people it's meant to reach.
- 4
One brief template for every project type
Using the same questions for a logo project and a landing page. A content brief and a design brief need different fields; forcing them into one template leaves gaps in both.
Frequently asked questions
How is a brief different from a client briefing form?
A client briefing form is a specific structured questionnaire sent to a client to collect project-wide information at intake. A brief is broader and comes at any point in a project: it can be written by an account manager, a product owner, or a client, and it covers one specific piece of work rather than the whole engagement.
How long should a brief be?
Most working briefs fit on one page. A brief long enough to need a table of contents is usually trying to do the job of a scope document or a charter instead of pointing someone at a specific piece of work.
Who approves a brief before work starts?
Whoever is accountable for the outcome, an account lead for client work, a creative director for a design brief, a product owner for a feature brief. The approver doesn't need to write the brief, but should confirm it before the team starts producing against it.
What happens if the brief changes mid-project?
Update the document and flag the change to everyone already working from it, the same way a scope change gets communicated. A brief that changes silently means half the team is still building against the old version.
Does every task need its own brief?
No. A brief is worth writing for work with real ambiguity, a design direction, a content angle, a campaign concept, not for a task with an obvious, well-defined output like updating a spreadsheet.
