When you begin working with a visual studio, nailing down the brief should be a straightforward, collaborative, and somewhat enjoyable process. And yet, for reasons known only to the universe, it’s often either wildly overcomplicated or the final brief winds up being so vague that it may as well just say “make it good?”
The good news is this: you do not need a 40-page manifesto, a degree in cinematography, or psychic abilities to get a strong result. You just need the right information, in the right places, at the right time.
What a good brief includes
At its core, a good brief should answer a few very basic questions:
What are you making?
Who is it for?
What should your audience understand or do afterwards?
Where will it be used?
That’s pretty much it. Everything else is detail, and will be ironed out later.
With that said, if you still feel like your brief is a bit bare bones, then some useful additions include:
The problem you’re trying to solve
Any absolute constraints (brand rules, funder requirements, accessibility needs)
Examples of work you like and why
Notice I said “and why”? Well, there’s a good reason for that. Saying “I like this style”, for example, can be helpful to a creative team, but it doesn’t tell them much. Instead, saying “I like this because it’s calm, clear, and not trying to impress anyone” gives them a great deal more insight, and ultimately makes any creative suggestions much more valuable.
What you do not need to over-prepare
Yes, there is such a thing as overpreparing a brief, and if you get too much into the detail at this early stage, thing can end up becoming much more complex than they need to be.
You do not need to:
Write a script
Make every visual choice upfront
Provide fully formed solutions
Write the brief as if it’s legally binding
A good studio doesn’t want you to design the thing for them, they want to understand the intent behind it. Remember the reason why you’ve hired a studio in the first place – because they’re the communication experts. It can be daunting letting go of the reins – especially if you already have an idea of how you think the final product should look – but you need to have trust in your chosen collaborator.
Think direction, not dictation.
How to choose the right first project for a studio
Working with a new studio is a bit like dating. You wouldn’t get married and start renovating a 19th century property on your first date, would you? No, you’d do something simple like go for a meal, see a movie, or in the case of my husband and I, go to a bar, drink beer, and play Trivial Pursuit.
All of this is to say that if this is your first time working with a visual studio, keep the project simple, and please don’t start with:
Your most high-stakes grant deliverable
Something with a million-and-one stakeholders
A project where things are likely to change
Something you need by close of play tomorrow
Instead, pick something:
Contained
Low-to-medium risk
Clearly defined
With a reasonable timeline
A first project is as much about learning how to work together as it is about the final output. You need space to ask questions, tweak approaches, and figure out what “good” looks like for both sides.
Timelines, scope, and sign-off
This is the unglamorous bit, but it matters, and defining your timelines, scope, and points of sign-off at project kick-off will save you all manner of headaches further down the line.
Be clear about:
Deadlines – It’s very important to be realistic here – Rome wasn’t built in a day, and all that – and whilst you may have your own internal deadlines to meet, it’s important to be cognizant of how long visual media takes to produce.
What’s in scope and what isn’t
How many rounds of feedback are expected
Who has final sign-off and at what points it needs to be given
If feedback needs to come from six different people, say so early. If sign-off takes two weeks because someone is on leave, say that too.
Setting clear expectations up front will prevent disappointment, last-minute chaos, and mildly passive-aggressive email chains.
A quick checklist (for future you)
Nothing makes me happier than a nice, concise checklist, so here’s one for you to run through before you send your brief:
Have I clearly stated the goal?
Do they know who the audience is?
Is the context clear without being overwhelming?
Have I flagged any non-negotiables?
Is the timeline realistic?
Do they know who’s approving the final version?
If you can tick those boxes, you’re pretty much good to go!
Final reassurance
Briefing well is all about clarity, not detail.
When everyone understands the purpose, the constraints, and the process, good work happens faster, feedback improves, and nobody feels like their time has been quietly set on fire.
And really, that’s the dream.