Most creative briefs do not brief anything. They summarize. They restate the request in nicer words, list a few deliverables, and end up filed away. Never opened again, never argued with. A real creative brief does something harder: it makes a team agree on the problem before anyone touches the work.
That gap is where projects quietly go wrong. The deck looks fine, the timeline holds, and three weeks in someone asks the question that should have been answered on day one: what are we actually trying to do here? This post is about writing the brief that answers it.
What a creative brief is for
A creative brief is an alignment document. Its only job is to get everyone (strategist, designer, writer, engineer, client) pointed at the same outcome before the expensive work starts. It is not a contract, not a scope of work, not a mood board, and not a place to hide every stakeholder opinion so no one feels left out.
The test is simple. If two people read the brief and start building two different things, the brief failed. If they read it and could each defend the same single objective without you in the room, it worked.
A brief is not a summary of the request. It’s the decision about what the request really is.
The good news: a strong brief is short. One page, sometimes two. Length is not the enemy of a vague brief. Vagueness is. A tight brief forces the hard conversations early, when they are cheap, instead of late, when they cost a redesign.
The anatomy of a brief that aligns a team
Every brief worth writing answers six questions. Skip one and you have left a hole the team will fill with guesses. These map closely to how we run early-stage strategy and positioning work, because a brief is really strategy compressed to a page.
1. The problem
Start with the problem, not the deliverable. “We need a new homepage” is a deliverable. “Qualified visitors land on our site, can’t tell within ten seconds what we do, and bounce” is a problem. The first sends people straight to layout. The second tells them what success has to fix.
Write the problem as a tension in the world: something is true, something else should be true, and the gap is what the work closes. If you can’t state the problem without naming the solution, you haven’t found it yet.
2. The audience
Name one primary audience and describe them like a person, not a segment. Not “decision-makers aged 30–55.” Instead: the operations lead who inherited a tool they didn’t choose, is quietly evaluating replacements, and has to justify the switch to a skeptical CFO.
The more specific the audience, the easier every downstream decision becomes: tone, density, proof, what to lead with. A brief that tries to speak to everyone gives the team permission to design for no one.
3. The single objective
This is the spine. One objective. If a brief lists five goals, it has zero, because the team will silently rank them differently and you won’t find out until review. Force the choice: what is the one thing this work must do for us to call it a success?
Secondary goals are fine. List them as secondary, clearly subordinate. The single objective is what you optimize for when two good options conflict, and they always do.
4. The success metric
Attach a way to know. The metric makes the objective falsifiable, which is the whole point. It turns “make it feel more premium” into something a team can actually aim at and a stakeholder can’t quietly redefine after launch.
- Quantitative where you can: demo requests, activation rate, time-to-comprehension, qualified-lead share.
- Qualitative where you must: “a target buyer can describe what we do in one sentence after thirty seconds on the page.”
Either way, write down how you’ll check. A metric you can’t measure is a wish wearing a number.
5. The constraints
Constraints are gifts. They shrink the solution space, which speeds the work and sharpens it. List the real ones: timeline, budget, fixed platform, regulatory limits, existing brand system, technical debt you have to live with. A constraint named on day one is a guardrail; a constraint discovered in week three is a rework.
6. The mandatories
Mandatories are the non-negotiables: the things that must appear or must not change. A legal disclaimer that has to stay. A primary CTA that can’t move. A brand color the board will not relitigate. Keep this list honest and short. When everything is mandatory, nothing is, and the team loses the freedom that makes the work good.
The brief as a hypothesis
Here is the shift that changes how good your briefs get: treat the brief as a hypothesis, not a verdict.
A hypothesis says, we believe that solving this problem for this audience, optimized for this objective, will move this metric, and here’s our reasoning. That framing does two useful things. It makes the brief testable, and it makes it disprovable. Both are features.
When the brief is a hypothesis, the creative work becomes an experiment that can succeed or fail on its own terms. You stop arguing about taste (“I don’t love the blue”) and start arguing about the bet (“does this serve the objective?”). That is a far more productive room to be in.
It also gives you permission to be wrong early and cheaply. If the audience research contradicts the brief, you revise the brief, before the build, not after. A brief held as a verdict resists evidence. A brief held as a hypothesis welcomes it. This is the same mindset that should govern a whole website redesign process: decide what you believe, then build the thing that tests it.
Write the brief as a bet you can lose. That’s the only kind worth making.
The smells of a bad brief
You can usually diagnose a weak brief without reading the whole project. A few reliable smells:
- It opens with a deliverable. “We need a brand refresh” tells you nothing about why. The brief should make you understand the problem before you ever hear the format. (If you’re not sure which you need, rebrand vs. refresh is the right argument to have first.)
- The audience is “everyone.” A brief that can’t exclude anyone hasn’t chosen anyone. Universal audiences produce generic work.
- Every goal is equally important. Five top priorities is a brief that has outsourced the hardest decision to whoever happens to be in the review.
- There’s no way to tell if it worked. No metric, no definition of done, just adjectives. “Modern,” “clean,” “premium,” “bold” are reactions, not targets.
- It reads like a committee. When you can feel six stakeholders’ fingerprints, each protecting their piece, the brief has become a peace treaty instead of a direction.
- It explains the solution in detail and the problem in a sentence. Inverted briefs prescribe the answer and skip the question. They feel decisive and are usually wrong, because nobody validated what they were solving.
The throughline: a bad brief avoids decisions and a good brief concentrates them. If reading your brief feels comfortable for everyone, it probably hasn’t decided anything yet.
How to actually write one
A workable process, start to finish:
- Interview, don’t transcribe. Talk to the people who own the problem. Ask why three times. The first answer is the request; the third is usually the brief.
- Draft the problem and objective first. Everything else is downstream. If those two are soft, fix them before you write another line.
- Cut it in half. Your first draft is too long and too hedged. Remove every sentence that doesn’t change a decision someone will make.
- Read it aloud to a skeptic. If they can restate the single objective and the success metric back to you, ship it. If they hesitate, you found the gap.
- Get one sign-off that counts. Not consensus from twelve people, but agreement from the one or two who can actually say yes. Consensus dilutes; a real decision-maker sharpens.
A brief that survives that process tends to survive the project. Related craft sits alongside it: clear messaging architecture gives the brief language to align on, and sharp brand positioning gives it a reason to exist.
How Strynal approaches the brief
At Strynal, every engagement starts on a blank page. No templates, no recycled briefs. The brief is where the thinking is supposed to happen, not a form to backfill. We write briefs as hypotheses, name one objective, and attach a way to know if we hit it. And because the team that scopes the work is the team that builds it, we have to live inside the brief we write; that keeps it honest. A brief we can’t design and ship against isn’t a brief. It’s a wish.
If a project keeps drifting and nobody can say exactly what it’s for, the brief is usually the culprit, and it’s a fixable one. Tell us what you’re trying to move and for whom over on the contact page. We’ll help you turn it into a brief a team can actually build from.