What blows a project's budget usually isn't development — it's revisions. And the source of those revisions is almost always the same: a scope that was never properly discussed upfront. A good brief doesn't describe your taste — it describes the criteria decisions will get made against.
What a bad brief looks like
"We want something modern, sleek, and user-friendly. Different from our competitors." That sentence says nothing. The word "modern" paints one picture in your head and a completely different one in the developer's head. Both sides walk away thinking they agreed, then split ways at the first design review.
The eight sections of a good brief
1. Business goal — what makes the site a success?
One sentence: "Get 20 qualified quote requests a month." Or: "Cut phone orders from dealers by 70%." Without this sentence, every design decision turns into a matter of taste. With it, arguments end: whichever option gets you closer to the goal wins.
2. Audience — who, on what device, in what mindset?
"Everyone" is a useless answer. A customer glancing at their phone in a hurry and a procurement person comparing quotes on a desktop don't get designed the same page.
3. Current state — what do you already have?
The current site's address, analytics access, which pages actually get visited, which search terms bring people in. With this data, design decisions stop being guesswork. When migrating to a new site, your URL redirect plan also comes out of this list.
4. Content inventory and ownership
Which pages will exist, who's writing the copy for each, who's supplying images, by what date. This one table alone is enough to get most projects finished on time. Unowned content is the single biggest reason projects stall.
5. Functional requirements — "must be able to" statements
Write every item in this pattern:
- "A visitor must be able to filter products by category."
- "A content editor must be able to preview a blog post before publishing."
- "An admin must be able to export incoming quote requests as Excel."
This pattern does two jobs at once: it's a work list for the developer, and a checklist for you at delivery. A vague sentence like "manageable from the panel" is neither priceable nor verifiable at handoff.
6. Out of scope — what this project will not do
The most skipped and most valuable section. "No e-commerce at this stage, no multilingual, no membership system." Scope left unwritten comes back a few weeks later as "can we also add this real quick?"
7. Visual direction — examples, not adjectives
Instead of "modern," send three site links and write down what you like about each one specifically: "the whitespace on this one," "the type hierarchy on that one." Add two examples you dislike too — a negative example carries more information than a positive one.
8. Budget range and timeline
Hiding the budget feels like a negotiating advantage but usually just wastes everyone's time. Give a range. Hearing a $15,000 solution pitched against a $3,000 budget burns two weeks for both sides. Give a range, and you'll get a scope proposed that fits it — much more efficient.
A skeleton you can copy
It doesn't need to be more than a page:
- Goal: the single metric that makes this site a success
- Audience: primary and secondary users, dominant device
- Current state: site address, analytics access, URLs to preserve
- Pages: list + content owner + due date for each
- Must be able to: functional statements, itemized
- Out of scope: what this project won't do
- Visual direction: 3 liked + 2 disliked examples, with reasons
- Budget / timeline: range and any fixed deadline (a trade show, a launch)
- Decision maker: who signs off — one name
That last item looks minor but is critical. On projects where sign-off runs through a five-person committee, every review opens a fresh round of opinions. Name a single decision maker; others can weigh in, but they have the final word. That one change visibly shortens delivery time.