A brand brief that turns scattered ideas into decisions
Build a short document that aligns objectives, audience, message, and approval criteria.
Key takeaways
- Define the problem before asking for a visual solution.
- Separate mandatory requirements from preferences and open questions.
- Agree on who approves and by what criteria before presenting designs.
A useful brief prevents everyone from solving a different project. Its job is to explain what needs to change, for whom, and how you will recognize a suitable proposal. You can keep it short without leaving essential decisions open to interpretation. Here is a way to build it and use it throughout the project.
Describe the problem with an observable sign
“We need a more modern brand” does not explain what is failing. “People do not understand that we also take orders for teams” makes it possible to review messaging, imagery, and the customer journey. Write down the current situation and the behavior you want to support.
Add what you know and how you know it: repeated inquiries, questions in a conversation, or difficulties preparing an asset. If you only have a suspicion, label it as a hypothesis. The brief should reveal the quality of the information, not hide it.
Summarize the audience, proposition, and evidence
Include the situation in which someone needs the brand, what they want to solve, and what objection could hold back their decision. Bring together a specific value proposition and existing evidence: work samples, process details, or verifiable product information.
In a hypothetical example, a ceramics studio wants to introduce orders for small teams. The brief can prioritize set selection, packaging, and a contact option to confirm quantities. That information gives more direction than a list of adjectives such as elegant, friendly, and different.
Classify decisions to avoid contradictions
Divide the document into requirements, preferences, and unresolved matters. The approved name is a requirement. A preference for light backgrounds is a preference unless there is a functional reason. The availability of photographs can be an open question with an owner and a deadline.
When two requirements compete, record the priority. For example, if the full name does not fit in a small space, the brief should allow an alternative composition or contextual use; simultaneously asking for maximum size, all the text, and plenty of space does not resolve the conflict.
| Type | Example | How to handle it |
|---|---|---|
| Requirement | The already approved name must be retained | Check compliance |
| Preference | We like paper textures | Evaluate whether they support the objective |
| Open question | There are no photographs of the set yet | Assign an owner and resolve before completion |
Agree on deliverables and the approval process
Name the assets and their uses: a horizontal logo for the website, a compact avatar version, or an editable presentation. Specify formats, available content, and dependencies. “Everything for social media” leaves the scope too open to design or review.
Assign one person to consolidate feedback and another to approve it when these are separate roles. Reviews should arrive grouped by problem and priority. If new objectives emerge, update the brief and explain their effect on the assets instead of adding disconnected instructions at the end.
Use the brief as a criterion during the presentation
Present each proposal alongside the decisions it addresses. Point out how it organizes the message, what the audience recognizes, and its limitations. A proposal can be visually attractive yet still fail to address the agreed problem.
Close the review with written decisions: approved, adjustment needed, or question pending. Keep a version of the brief associated with the handoff. That way, when someone wants to change something months later, you can understand why the decision was made.
Complete your brief in one session
- Write one sentence each for the problem, audience, and expected outcome.
- Organize requirements, preferences, and open questions.
- List deliverables and agree on the owner, criteria, and review date.
Frequently asked questions
Who should write the brief?
Someone who knows the business can prepare it with support from the designer. What matters is that the people responsible for the objective and approval review it before production begins.
Can I change it halfway through the project?
Yes. Record what changed, why, and which deliverables it affects. An explicit change is easier to manage than keeping a document that no longer reflects the project.
Should I include visual references?
Yes, when you explain what you observe in them: hierarchy, texture, or framing. An image folder without comments leaves too much room for different interpretations.
