How to write a brand brief a designer can use

A useful brand brief gives a designer enough context to make choices and enough boundaries to judge them. It does not need to prescribe the final look. The most helpful version describes the business situation, the people the work must reach, and the materials that need to change. You should be able to read it together at the start of a project and use it again when reviewing a direction.

Start with a page, even if the project eventually needs more documentation. A short brief forces decisions about what matters now. Put supporting research, old files, and competitor examples in an appendix or shared folder. The brief itself should tell the designer what those materials mean for this assignment. A large folder with no explanation transfers the task of prioritizing your business to someone who has just met it.

Describe the change that prompted the project

Write two or three sentences about why the work is happening. “The identity is dated” expresses a reaction but gives little direction. A more useful statement is: “The company has added a maintenance service, but the website and sales materials still describe installation only. The new identity needs to help customers understand both offers under one business.” That statement identifies a business change and a communication task.

Include what already works. Customers may recognize a color, a familiar product name, or a visual mark used on equipment. Ask which elements have a practical reason to remain and which are simply familiar to the internal team. Put genuine constraints in the brief, with their reasons. A designer can work with a requirement to retain a sign shape because replacing physical installations is outside the project budget.

Name the audience in a buying situation

An audience description should help someone choose words and images. “Small businesses” is too broad for many projects. Describe the person encountering the work, the task they are trying to complete, and what they need to know. For a maintenance company, the audience might be an operations manager comparing service providers after a recurring equipment problem. That context suggests different priorities from a homeowner browsing an inspiration gallery.

Separate the primary audience from people who also need to use the materials. The buyer may need clarity about coverage and response arrangements. A procurement colleague may need company details. Staff may need templates that are quick to edit. All three matter, but they do not have to receive equal prominence on the homepage. Rank them so the designer can resolve competing requests.

State the communication problem plainly

Write down what the audience currently misunderstands or struggles to find. Use evidence you actually have: questions in sales conversations, feedback from customer interviews, or examples of confusing materials. Label assumptions as assumptions. If the team suspects that its identity looks too informal for a new customer group, that is a hypothesis to explore rather than an established fact about lost business.

The Design Council's Double Diamond describes a process of discovering and defining a challenge before developing and delivering responses. For a brief, the useful lesson is to give the designer room to understand the problem before settling on its visual answer. A small conversation with intended users can be more useful at this stage than another internal mood board.

Choose a message hierarchy

List the three things a viewer should understand, in order. In the maintenance example, the first might be the type of equipment supported, the second the service area, and the third how to request an assessment. Resist including every company virtue in this list. A page that treats experience, friendliness, technology, sustainability, speed, and price as equal priorities leaves the designer with no hierarchy.

Try the list against a real application. If a prospective customer sees only the first screen of the website, what should be clear? If they receive a proposal, what should distinguish the opening page from a generic introduction? The answers can differ by material, but they should connect to the same business story. Note those differences so one layout is not expected to solve every communication problem.

Use references to explain a choice

Visual references are useful when accompanied by a reason. Instead of “make it like this,” write “the service categories are easy to scan” or “the photography shows the work at a believable scale.” Identify the feature that matters and the context in which it might help. A website can have an excellent information hierarchy and a visual style that would be wrong for your audience.

Include a few references and explain what should not carry across. For instance, the team may like a publication's typography but need a less dense page for mobile readers. That note prevents a preference from becoming an accidental instruction. Avoid collecting dozens of examples that point in different directions. If the decision team disagrees about a reference, settle the underlying requirement rather than hiding the disagreement in the folder.

Specify the applications and practical limits

Name the actual deliverables. “A complete brand” is hard to estimate or approve. “Logo system, color and type guidance, six-slide introduction deck, proposal cover and two website page templates” gives everyone a starting point. Add the software your team uses and who will edit each item. An editable document is only useful if the people responsible for it can open and change it.

Include timing, available budget information, production requirements, and dependencies. If new photography will arrive late, the designer needs to know. If a print item must fit existing envelopes, record the size. Identify who supplies final copy and who checks technical details. These are ordinary project facts, but leaving them out can create expensive redesign work after a direction has already been approved.

Agree on how decisions will be made

Name one person who consolidates feedback and one person who gives final approval. They may be the same person. Ask other stakeholders for requirements before the design review, especially when their work will be affected. A late discovery that the sales team cannot use the chosen software is a planning issue, not a matter of visual taste.

Set review questions in advance. Does the direction make the service structure clearer? Can the primary audience find the next step? Does the system work in the smallest required application? Those questions give comments a purpose. “I prefer blue” may still be worth discussing, but the brief helps the group connect that preference to a requirement rather than treat every reaction as an instruction.

Assemble the one-page version

A workable page can use seven short sections: project trigger, primary audience, communication problem, message priorities, required applications, constraints, and approval owner. Add a link to supporting material. Read it aloud with the person commissioning the work and remove statements that could describe almost any company. Replace “professional and modern” with the behavior or impression you actually need in a particular situation.

Before sending the brief, ask a colleague unfamiliar with the project to explain what is being made and why. If they cannot, clarify the missing connection. Then invite the designer to question the brief at kickoff. A useful brief can change when new information appears; keep a dated version and record any agreed change to scope. The next step is simple: write the project trigger and the primary audience today, then build the remaining sections around those two decisions.