1. The decision this project supports
A creative brief should help everyone make the same decision, not bury it in a long document. Answer the prompts, including what must be true, before choosing a visual direction.
Project name: Give the work a clear, searchable name.
Business problem: What is happening now that needs to change? Describe the observable issue, not just a requested deliverable. “Visitors cannot tell which service fits” is more useful than “we need a new page.”
Desired visitor action: What should someone be able to understand or do after seeing the work? Pick one primary action and note any necessary earlier steps.
2. The people and their context
Primary audience: Who is making the decision? Describe their role, situation, and familiarity with the offer. Avoid a demographic label when the decision context matters more.
Question they bring: What are they trying to find out? What uncertainty would stop them from acting?
Where they encounter the work: Search result, website page, email, ad, sales conversation, event, or another specific place. The same message may need a different form in each setting.
3. The message and evidence
Core message: In one sentence, what should the audience understand?
Supporting facts: List the accurate service details, product attributes, process information, or approved proof that support the message. Add a source and owner for each important claim.
Things not to imply: Note exclusions, conditions, regulated language, or common misunderstandings. A useful brief protects against a polished design that says the wrong thing.
4. The work and its boundaries
Deliverables: Name the formats and placements: for example, a service page, email sequence, landing page, or printed piece. Include dimensions or platform constraints only when they are known.
Existing assets: Identify copy, brand guidance, imagery, data, templates, and technical components that should be reused. Mark anything whose rights or accuracy are uncertain.
Constraints: Include accessibility, legal or policy review, technical dependencies, required languages, launch dates, and budget boundaries that actually affect the work. Do not invent a deadline to create urgency.
5. Ownership and the test
Decision maker: Who can approve the message, design, and factual claims? A single named owner for each decision prevents late contradictory feedback.
Review moments: When will the team check the brief, direction, and final output? State what can still change at each point.
Success check: What evidence will tell you whether the work improved the original problem? It may be a usability test, a clearer inquiry, fewer repeated questions, or a measured change after launch. Choose a check you can actually run.
A short example
Suppose a business receives inquiries from people who misunderstand its service area. The problem is not “the page looks old.” The decision is whether the company serves a particular location. The primary audience is a prospective customer checking fit on a phone. The message is the actual coverage and the next step. Evidence comes from the current service policy. The deliverable may be a revised service-area section and contact form. The test is whether a visitor can find the answer and whether the team receives fewer out-of-area requests.
The brief has done its job when a designer, writer, and business owner can all describe the same problem and approval path. If they cannot, clarify the brief before producing more assets.
What to do next
Use the answers to shape the information architecture, website copy, or visual work. If the project crosses several disciplines, bring the completed brief into a scope conversation.
For a website build, follow the message brief with website scope boundaries so migration, content ownership, integrations, acceptance, and change requests have explicit owners.
