Here is how to write a project brief that gets it right the first time: state the goal, describe the audience, show examples you like, attach the files, list the must-haves and say what “done” looks like. That is six short sections. A brief like this takes a few minutes to write and saves days of back-and-forth, whether you hand the work to a freelancer, an agency or an AI-native team.
Why most briefs fail
Most briefs fail in one of three ways. They describe the task but not the goal, so the result is technically correct and still not useful. They leave out key files, so the provider guesses at brand colors, logins or copy. Or they never say when the work is finished, so revision rounds keep going.
None of these are about writing skill. They are about missing information. The fix is a short, repeatable structure.
How to write a project brief: the six parts
Work through these six parts in order. Each one answers a question the provider would otherwise have to ask you.
1. The goal
Start with the outcome, not the task. “Build a landing page” is a task. “Get sign-ups for our new course from people who click our ads” is a goal. When the provider knows the goal, they can make better small decisions without asking you.
Keep it to one or two sentences. If you have more than one goal, rank them.
2. The audience
Describe the audience in plain words: who they are, what they already know, and what they worry about. “Small restaurant owners who are not technical and do not have time for a long setup” tells a designer and a copywriter far more than “SMBs”.
3. Examples you like
Examples remove guesswork faster than any description. Share links to sites, designs, posts or reports you like, and say what you like about each one: the layout, the tone, the colors, the level of detail. One line on what you do not like helps just as much.
4. Files and access
List and attach everything the work depends on:
- Logo, brand colors and fonts
- Existing copy, product lists or data files
- Logins or access the provider needs, shared through a safe method, not in the brief itself
- Any existing design, code or document to build on
If something is not ready yet, say so and say when it will be.
5. Must-haves
Separate what is required from what would be nice. Must-haves are the items that make the work fail if they are missing: “must work on mobile”, “must connect to our booking tool”, “must use our approved product names”. Keep this list short. If everything is a must-have, nothing is.
6. What “done” means
This is the part most briefs skip. Write down how you will judge the result. For example: “Done means the page is live on our domain, the form sends to our inbox, and it loads well on a phone.” Clear acceptance criteria make revisions precise and stop scope from creeping.
A short project brief template
Copy this and fill it in. Most small tasks need only a line or two per heading.
- Goal: What should this work achieve?
- Audience: Who will use or read it, and what do they need?
- Examples: Links to things you like, and what you like about each.
- Files and access: What is attached, and what is still to come.
- Must-haves: The few things the work cannot go without.
- Done means: How you will check that the work is finished.
- Deadline and budget range: When you need it and roughly what you plan to spend.
Examples of weak and strong briefs
Weak: “We need a logo for our coffee shop. Modern and clean.”
Strong: “We need a logo for a small coffee shop that sells to students near a campus. Goal: look friendly and affordable, not premium. We like the hand-drawn feel of these two examples, but not their brown color. Must work as a small app icon and on cups. Done means a main logo, an icon version and the color codes in a brand kit.”
The second version is still short. It just answers the questions the designer would otherwise have to ask.
Common brief mistakes
- Writing a solution instead of a problem. Say what you need to happen, and leave room for a better idea.
- Mixing several tasks into one brief. Split them. Each task gets its own goal and its own “done”.
- Changing the brief midway without saying so. New requirements are fine, but flag them clearly so the price and date can be checked.
- Hiding the real deadline. If there is a launch date, share it.
- Pasting passwords into the brief. Share access through a password manager or a temporary account.
How a good brief changes the result
With AI-native work, the brief matters even more, because it guides both the AI that produces the first draft and the expert who reviews it. At Wooprex, the reviewer checks every delivery against your brief, so the “must-haves” and “done means” sections become their checklist. A clear brief also makes the 2 included revision rounds go further, because each one fixes details instead of direction. You can see where the brief fits in the process on the How It Works page.
FAQ
How long should a project brief be?
As short as it can be while still answering the six parts. For a small task, a few sentences are enough. For a larger project, a page is usually plenty.
What if I do not know exactly what I want?
Say so, and share the goal and a few examples. A good provider can suggest options. For unusual tasks, Custom Work starts from a short description and turns it into a scoped quote.
Should I include a budget in the brief?
Yes, at least a range. It tells the provider which options are realistic and avoids quotes that are far off.
Can I change the brief after work starts?
You can, but changes may affect the price and date. Small clarifications are part of revisions; new features or new deliverables are a new scope.
Ready to send your brief? Start a Task and get a fixed price and delivery date within 6 business hours.
