how to brief someone on creative work you usually do yourself
as our agency grew, I needed other people to help deliver work clients trusted us to do.
I started writing what I called minimum viable processes: the essential steps from undone to done. I wanted people to understand the standard without having to guess everything in my head.
I wrote about that shift here.
if you're handing over creative work you normally do yourself, a useful brief can give someone direction and leave them room to think.
choose one piece of work to hand over
start with something you can describe clearly. a presentation, a draft, a set of project images, or another defined deliverable.
“help with content” leaves a lot unresolved. which piece? for whom? where will it be used? who decides whether it's ready?
pick work the person is equipped to do. a clear brief won't make an unrealistic timeline or a missing skill disappear.
agree on the scope, timing, payment, and responsibilities before work starts. writing a process isn't a substitute for that conversation.
explain what done looks like
state the result someone needs to deliver and how you'll review it.
here's an illustrative example: you're asking a designer to prepare a client presentation from an agreed outline. they need to know which slides are required, the format, where it will be shown, and who approves it.
“make it look good” doesn't tell them what you need. “use the agreed brand files, make the charts readable in the meeting, and flag missing information” gives them something to work with.
separate requirements from preferences. an approved logo file might be fixed. the best way to lay out a slide might be open to their judgment.
give them the context and materials
include the brief, the relevant files, the source information, and any permissions they need. point to the current version when there are older drafts around.
explain who the work is for and what it should help that person understand or do. a reference is more useful when someone knows why you included it.
say what they can change and what needs approval. if they encounter a problem, where should they raise it?
check access before they start. a folder they can't open isn't a handoff, however tidy the brief looks.
write the essential steps, not every movement
describe the steps that protect the result: checking source information, making a first version, getting the right review, and delivering the agreed files.
if there's a known mistake that would cause rework, mention it and explain why it matters.
leave room for their method where the result doesn't depend on yours. you may know a familiar way to make the work. they may know a better one.
my original letter described people first understanding the process and then improving it. the standard matters; copying every click you make may not.
agree on a useful review point
choose when you'll look at the work together. an early direction check can catch a misunderstanding before someone finishes everything.
ask them to explain what they believe they're delivering. listen for any difference between the brief you wrote and the task they understood.
when reviewing, compare the work with the requirements. if you add something new, acknowledge that it's a change rather than treating it as an instruction they missed.
be available for the questions you've asked them to bring back. handing over a task doesn't mean disappearing until the deadline.
improve the brief after the handoff
when the piece is finished, ask what was unclear, which steps helped, and what they would do differently next time.
keep the improvements that make the result easier to achieve. remove instructions that didn't serve a purpose.
save a short reusable brief with:
- the deliverable, purpose, and audience
- what done looks like
- the current files and constraints
- the essential steps
- the review point and final handoff
then update it from actual use. the point is to help someone do good work with you, not build a document that only you understand.