Writing a creative brief your team can actually start from

Most creative briefs fail in the first hour of the work. A designer opens the brief, reads three paragraphs about the brand's history, and still has to ask what they are making, for whom, and by when.

A brief is only useful if someone can start from it without a meeting. This article gives you a creative brief template built around the questions a team actually asks, shows what to leave out, and walks through turning a finished brief into jobs and tasks on a board.

Why briefs stall the work#

Briefs tend to be written for the wrong reader. They are often assembled from a client's pitch deck, so they explain why the project matters and say little about what has to be made. The background is all there. The deliverables, the deadline and the person who says yes are missing.

The other common problem is where the brief lives. It sits in an email attachment or a shared document, away from the work. By the second week, the brief says one thing, the board says another, and a decision made on a call is in neither.

A good brief fixes both. It answers the questions the team will ask, and it lives on the job the work happens on.

The eight questions a brief must answer#

Here is the template I'd use. Each heading is a question, and each answer should fit in a few lines. If an answer runs to a page, the project probably needs splitting.

1. What are we making? The deliverables, listed and counted. "A homepage hero, three social formats and an email header" is a brief. "A refreshed launch look" is a wish.
2. Why now? One or two sentences on what the work is for: a launch, a campaign, a change of positioning.
3. Who is it for? The audience the work has to reach, in plain words. Skip personas nobody reads.
4. What should they think or do? The single response you want. If there are three, pick one.
5. What must it include? The mandatories: logo rules, legal lines, product names, sizes and formats.
6. What should we look at? References, existing assets and past work, as links or files.
7. When is it due, and when is it reviewed? The final date, and the date the client sees the first round.
8. Who signs it off? One named person on the client side, and who stands in if they are away.

That is the whole template. Copy it, paste it into your next brief and delete nothing until each question has an answer.

What to leave out#

A shorter brief gets read. Leave these out, or link to them instead:

• The company's history. Link to it if the team needs it.
• Every stakeholder's opinion. Summarise what was agreed, not who said what.
• The schedule for the whole programme. Give the dates for this piece of work.
• Design direction dressed as a requirement. "Use a navy palette" is a requirement only if the brand demands it. Otherwise it is a reference, and it goes under question 6.

Put the brief where the work happens#

Once the brief is written, it should stop being a separate document. In Skybase, the natural home is the job itself. A job's description holds the brief, its files hold the references, and its comments hold the decisions made after the brief was written.

The new job form walks through it in order. Job details asks for a title, a priority, the dates and a job type. Description holds the brief. Assign & collaborate picks who is responsible and who should follow along. Then you add Tasks, and optionally give each one an assignee and a due date.

Keep the client-facing date on the job and the internal steps on its tasks. The job's due date is the day the client needs the work, and each task can carry its own date, such as a first draft three days before. The job's Tasks tab shows how many are done, so anyone can read progress at a glance.

Make the brief a form, not a blank page#

Templates get skipped when they live in a document nobody opens. The way round that is to build the questions into the job itself, using job types and custom fields.

Job types are set per project, under Job Types in the project's settings, by administrators and team members on the project. Choose Create Job Type, name it, for example Design or Copy, then Add Field for each part of the brief you want asked every time. A field can be a short line of text, a longer text, a link or a file.

Three settings on each field do most of the work:

• Required field makes the new job form ask for it before the job is created. Use it sparingly: the deliverables and the approver, perhaps, but not everything.
• Placeholder shows example text in the empty field, such as "Homepage hero, 3 social formats, email header".
• Help Text sits below the field and says what a good answer looks like.

A Design job type with fields for deliverables, mandatories, a reference link and the approver turns the template above into something the form asks for. The background, audience and response can go in the description, where there is room to write.

From one brief to a board#

A brief for anything bigger than one deliverable shouldn't be one job. Split it by who does the work and what gets approved separately. A useful test: if the client could approve one part and reject another, they are two jobs.

1. Create one job per deliverable that is reviewed on its own, using the job type that matches the work.
2. Put the shared parts of the brief (why now, audience, response) in each job's description, so nobody has to go looking.
3. Turn the steps inside each deliverable into tasks with their own owners and dates.
4. Give each job the client's review date, not the final launch date, so the calendar shows when work must be ready to show.
5. Invite the client's approver to the project as a guest, so their comments land on the job they are about.

Sharing work with clients covers what a guest can see and do, and how to set up a kanban board for agencies covers the columns the jobs move through.

A worked example: Harbour Studio briefs a launch#

Take a small agency, say Harbour Studio, rebranding its client Northwind. This is a made-up example. The board runs Brief, In progress, Client review and Done, and the job types are Design, Copy, Strategy and Dev.

Northwind's brief arrives as a long email from Tom Becker. Sam Okafor, the strategist, rewrites it against the eight questions. It comes out as one page. What they are making: a launch kit with a homepage hero, three social formats and an email header. Who signs it off: Tom.

Maya Chen, the studio lead, has already set up the Design job type with a few fields: deliverables, mandatories, a reference link and the approver, with the first two marked Required field. Help text under the mandatories field says "Logo rules, legal lines, sizes".

Sam creates "Social launch kit" in the Brief column as a Design job. The form asks for the deliverables and mandatories before it will create the job. The audience and the response go in the description. The tasks are "Moodboard", "First round of formats" and "Final artwork", each with an owner and a date, and the job's own date is Tom's review day.

The homepage hero becomes its own job, "Homepage hero", because Tom will review it separately. Priya Shah takes it, and her first direction goes up as hero-direction-b.png.

When Tom later asks for a darker navy, he does it in a comment on the job, not in a new email. Leo Ortiz adds "Deep Harbour (#0B2545)" to the brand palette, and the decision sits on the job, next to the brief it changes.

A checklist before the work starts#

• Every deliverable is listed and counted.
• The audience and the response fit in two sentences.
• Mandatories and references are on the job, not in an inbox.
• The review date and the final date are both set.
• One named person signs it off.
• Each separately approved deliverable is its own job, with tasks for the steps.

The board, table and calendar guide covers how the jobs you create show up in each view, and the features page lists everything else a job can hold.

A brief your team can start from is short, specific and in the same place as the work. Write it against eight questions, build the important ones into the job form, and the first hour of every project goes on the work instead of on questions.