Most bad websites start with a bad brief. The client didn’t know what to ask for. The agency didn’t push to find out. The result: a site that looks acceptable, doesn’t reflect the business, and fails to generate leads. Then six months later, the client is shopping for a new agency.
A good brief is not a document that makes you sound sophisticated. It’s a document that protects you from vague deliverables and gives the designer what they actually need to make good decisions. If you can write a clear brief, you can evaluate whether the agency’s response shows they understood it — and that is your single best signal that the engagement will go well.
This is what to put in a brief, how specific to be, and what to leave out.
What a Brief Is Not
First, clear the misconceptions.
A brief is not a mood board. Pinterest boards are fine supporting material, but “make it feel like these sites” is not a brief. Aesthetics should come after goals are established.
A brief is not a technical specification. You don’t need to specify the CMS, the hosting stack, or the deployment pipeline in a brief unless you have strong requirements. Those are decisions to make collaboratively based on what you’re trying to achieve.
A brief is not a scope document. Scope comes from the brief — the agency should respond to your brief with a scope, not the other way around.
The 8 Elements of an Effective Brief
1. Business Context
Two to three sentences about what the business does, who it serves, and how it makes money. This sounds obvious, but designers who receive a brief without business context end up designing for aesthetics rather than for your customers’ specific needs.
Include:
- What you sell (product, service, model)
- Who buys it (describe your best customer specifically)
- Why they buy it from you and not a competitor
Example: “We’re a commercial photography studio in Chicago that serves DTC e-commerce brands. Our clients are marketing directors at brands with $1M–$20M in annual revenue who need product photography turnaround in under 5 business days. We’re more expensive than freelancers but faster and more consistent.”
That’s a brief that a designer can use. “We’re a photography studio that focuses on quality and client relationships” is not.
2. Primary Goal
What is the website supposed to do? This has one right answer per project, and it should be stated explicitly.
Common goals, in order of specificity (better as you go down):
- “Have an online presence” — too vague
- “Get more leads” — closer, but still vague
- “Generate 20+ qualified inquiries per month through the contact form” — actionable
- “Convert visitors from Google Ads campaigns at a target CPL under $150” — excellent
If you have multiple goals, rank them. The design will make trade-offs. You want input on which trade-offs to make.
3. Target Audience
Describe the person you most want to reach. Not “small business owners” — that’s 30 million people in the US. Describe the specific customer type that represents your best-fit client.
What to include:
- Their role (decision-maker, researcher, operations person?)
- Their level of familiarity with your industry
- What they’re anxious about when considering this purchase
- How they find vendors like you (Google search, referral, social, trade publications?)
The anxiety question is underrated. A client brief that says “our visitors are nervous about price transparency and have been burned by agencies before” tells a designer to lead with pricing and trust signals prominently. Without that context, they might bury the pricing page.
4. Current Site Problems
If you have an existing site, document what’s wrong with it. Be specific.
Useful statements:
- “Our bounce rate from mobile is 78%. We think the mobile menu is hard to use.”
- “We get 400 visitors a month but only 2–3 contact form submissions.”
- “Our Google PageSpeed score is 41 on mobile.”
- “The visual design feels dated — we keep losing pitches to competitors with newer sites.”
Unhelpful statements:
- “It just doesn’t feel right.”
- “It doesn’t convert.”
- “We want to modernize it.”
If you can run your URL through honest.designodin.com before briefing, you’ll have actual performance data to include in the brief. That’s the kind of specific that moves a project forward.
5. Scope
List the pages and functionality you know you need. Don’t try to be comprehensive — you’ll miss things and discover them during the project. But naming the core requirements prevents agencies from scoping either too narrowly or too broadly.
Example scope list:
- Homepage
- 4 service pages (one per service)
- About page with team bios
- Case studies section (3–5 projects at launch)
- Contact page with quote request form
- Blog, with category filtering
- Integration with HubSpot CRM via form submissions
If you have functional requirements (calendar booking, e-commerce checkout, membership login, multilingual), list those explicitly. Missing a major functional requirement in the brief and discovering it halfway through the build is the primary cause of budget overruns.
6. Technical Requirements
You don’t need to specify technology, but you should specify constraints.
Relevant constraints to mention:
- Must integrate with [specific tool]: HubSpot, Salesforce, Calendly, Shopify, etc.
- Must be manageable by a non-technical in-house team (affects CMS choice)
- Must support multiple languages or currencies
- Must comply with GDPR or CCPA (affects cookie consent, data handling)
- Client owns all code (no licensing, no SaaS, no proprietary builders)
That last one is especially important if you’ve been quoted page builder builds before. Demand ownership of the code. Agencies using Elementor or Divi produce sites where the “code” is inseparable from the page builder license. If the agency ever disappears or you switch vendors, the site is trapped.
7. Design Direction
Not a mood board — direction. Describe the feeling you want visitors to have, the brands you think do design well (in any industry), and any constraints you have.
Useful direction:
- “We want to feel authoritative and expensive, not friendly and approachable. Think McKinsey, not Mailchimp.”
- “We’re not traditional. We want something modern and slightly editorial — fewer stock photos, more typography.”
- “We need to stay within our existing brand colors (blue: #1A3A5C, white: #FFFFFF, gold: #C9A84C) but are open to everything else.”
- “Our competitors all use big hero images and generic stock photography. We want to differentiate.”
What not to include: “make it pop,” “modern but timeless,” “clean and professional.” These mean different things to different designers and communicate nothing useful.
8. Timeline and Budget
This is the part most clients omit. Don’t omit it.
Timeline: If you have a hard deadline (product launch, seasonal peak, planned marketing campaign), state it. Designers need to know whether to account for revision cycles, content production dependencies, or rushed delivery.
Budget: State your budget range. The most common client fear: “if I say my budget, they’ll just charge me that amount.” The reality: if you don’t state a budget, agencies either assume the wrong range and scope a project you can’t afford, or they ask for it in the first meeting and you waste everyone’s time.
A budget range protects you. “We have $15,000–$20,000 for this project” tells the agency whether to scope a custom build or a lighter package. It also tells you whether the agency is aligned — if their minimum engagement is $50,000, you find that out immediately instead of after a 2-hour discovery call.
Questions That Separate Good Agencies From Bad Ones
After you send a brief, evaluate the response. Good responses include:
- Questions about your business goals and audience (they want to understand before scoping)
- A specific proposed scope with named deliverables, not vague phases
- Clear information about who will actually build the site
- A timeline with milestones, not just an end date
- Specific pricing for specific scope
Warning signs in a response:
- A 30-page proposal with no specific deliverables or timeline
- Vague phases like “Design Phase” and “Development Phase” with no description of what those include
- No mention of who builds it (are you getting a senior developer or a junior?)
- “We’ll determine scope after a discovery phase” — which you pay for
- No mention of what happens after launch (who maintains it, who fixes bugs?)
Ask directly: “Who will be the primary developer on this project, and can I see work they’ve built?” This single question filters out agencies that sell senior relationships and deliver junior work.
At Designodin, the person who scopes the project is the person who builds it. There’s no handoff to a separate delivery team. Fixed-price packages mean the scope and price are known before any work begins. No discovery phase, no proposal theater.
What to Leave Out of Your Brief
Some things actively complicate briefs:
- Detailed wireframes or mockups (unless you’re commissioning a specific design system — let designers propose structure)
- Specific technology choices (unless you have a genuine requirement — “must be WordPress because our team knows it” is valid; “must use Tailwind CSS” from a non-developer is not)
- Long lists of competitor sites to “beat” (inspiring 3–5 reference sites is useful; a list of 20 sites signals unclear vision)
- Internal organizational debates presented as requirements (if your team hasn’t agreed on what the homepage says, tell the designer that’s a work in progress — don’t present the disagreement as a spec)
FAQ
How long should a web design brief be? One to three pages is ideal. Long enough to communicate context, goals, audience, scope, and constraints. Short enough that someone reads it carefully instead of skimming. A 20-page brief with six months of internal deliberation often signals a client who hasn’t decided what they want yet.
Do I need a brief for a small website project? Yes, but a shorter one. Even a 5-page site benefits from a clear statement of goal, audience, and scope. Without it, a designer will make assumptions — and you’ll pay for revisions to those assumptions.
Should I include examples of sites I like? Yes, 2–3 is useful. Include a sentence about specifically what you like about each one (the navigation, the typography, the photography style, the way the service pages are structured). Without that context, designers take different lessons from the same reference.
What if I don’t know my budget? Get quotes first, then decide. Say something like: “We don’t have a fixed budget yet, but we’re looking to understand what different scopes cost.” Most reputable agencies can quote a range before a detailed scope is defined. If an agency won’t give you even a ballpark without a full discovery engagement, that’s a negotiating tactic, not a process requirement.
How do I handle scope creep after the project starts? The brief is your protection. If something is clearly in the brief and the agency tries to charge extra for it, point to the brief. If something is clearly outside the brief and you want it added, that’s legitimate additional scope — agree on the cost before proceeding. Scope creep happens most in projects where the original brief was too vague to define a boundary.
What questions should I ask about the development process? Ask: Who builds it? What CMS? Will I own all the code? What does the handoff include? How are bugs handled post-launch? What’s the update/maintenance process? If the answers are vague, push for specifics before signing anything.
A clear brief is what separates a productive agency engagement from a frustrating one. If you’re planning a new site or a rebuild and want to work with a team that doesn’t hide behind vague proposals, get started with Designodin. Our custom WordPress development process starts with a defined scope and a fixed price — no discovery phase, no proposal theater.