How to Write a Design Brief Your Agency Can Actually Use

"Make it modern and clean." If that sentence — or something close to it — is the core of your design brief, stop and read this before you send it. It's not that the request is wrong. It's that it's unusable. Every designer on earth interprets "modern and clean" differently, and the agency reading it has no choice but to guess, build something, and wait for you to say "not quite that."

A design brief is the document that tells your agency what you're trying to achieve, who you're building for, and what "done well" actually looks like. You don't need design vocabulary to write a good one. You need business clarity — and that's something you, as the founder, already have more of than anyone else in the room.

Design Brief Template — The Short Version

If you only have five minutes, fill in these six blanks. Everything below expands on each one.

1. Business goal: What outcome should this design work drive? (More sign-ups, fewer support tickets, higher checkout completion, etc.)
2. Target user: Who is this for, specifically? Not "everyone" — a named type of person with a context and a need.
3. Scope: What pages, flows, or screens are in this project, and what's explicitly out?
4. Constraints: Budget, timeline, existing brand rules, technical limitations, must-keep features.
5. References: 2-3 examples of what you like (and why), 1-2 of what you don't.
6. Success criteria: How will you know, three months after launch, that this worked?

Now let's go through why each of these matters and how to write them without a design background.

Why Vague Briefs Waste Everyone's Time

When a brief says "modern and clean," the agency has three options: guess, ask you a dozen clarifying questions before starting, or design something generic that's unlikely to be wrong but is also unlikely to be right for your business. All three cost you time and money.

Vague briefs don't just slow down the first draft — they cause revision loops. You look at round one, realize it's not what you meant, and try to explain what you actually wanted. Except now you're explaining it after paying for work that missed the mark, instead of before. A specific brief moves that clarifying conversation to before the design starts, where it's free.

There's a second, quieter cost: generic output. An agency working from "modern and clean" has nothing to differentiate your product from a competitor's. An agency working from "our checkout page loses 40% of mobile users at the payment step, and our users are non-technical parents ordering on their phones during a 10-minute break" can design something that actually solves your problem, because they understand what the problem is.

Vague vs. Specific: The Same Request, Two Ways

Vague brief (what most founders send):

"We need a new website. Make it modern and clean, similar to some of the big SaaS companies. Should feel premium. Let us know your ideas."

An agency reading this has no idea what "premium" means to you, who visits the site, what the site needs to accomplish, or how you'll judge the result. Expect three rounds of revisions and a result that's inoffensive but not necessarily effective.

Specific brief (same project, rewritten):

"We're a B2B logistics SaaS selling to warehouse operations managers, most of whom are 40-55, not deeply technical, and evaluating 3-4 vendors before booking a demo. Our current site gets traffic but converts under 1% to demo bookings. We want a homepage and pricing page redesign that makes our differentiator — real-time inventory sync — obvious in the first screen, and that gets a visitor to book a demo without needing to read the whole page. We like the clarity and pricing-table layout on [Competitor A]'s site, but not their dense homepage copy. Budget is $8-12k, timeline is 5 weeks, and the site must stay on our existing CMS."

Same underlying need — a better website — but the second version tells the agency exactly what to solve for, who they're solving it for, what "good" looks like, and what boundaries they're working within. That's the difference between a brief that produces options and a brief that produces a solution.

The Design Brief Template, Section by Section

1. Business Goals — Not Design Preferences

Start with the business problem, not the visual style. "We want more free-trial sign-ups from our pricing page" is more useful to a design team than "we want a bold hero section," because it tells them what to optimize for. If you're not sure how to phrase this, finish the sentence: "This project will have succeeded if, three months from now, ___."

2. Target User — Specific, Not "Everyone"

Describe the person who'll actually use what's being designed: their role, their tech comfort level, the device they're likely using, and the situation they're in when they land on your product (rushed, comparing options, already a customer, etc.). If you have more than one user type, name each one and note which matters most for this project.

3. Scope — What's In and What's Out

List the specific pages, screens, or flows included in this engagement. Just as important: name what's explicitly excluded. "This covers the marketing site, not the logged-in dashboard" prevents an agency from either under-delivering or quoting for work you didn't ask for.

4. Constraints — The Guardrails

Budget range, timeline, existing brand guidelines (logo, colors, fonts if you have them), technical platform (Shopify, WordPress, custom build), accessibility requirements, and any feature that must be preserved from the current version. Agencies design better within real constraints than in a vacuum — it narrows the decision space instead of widening it.

5. References — Show, Don't Just Tell

Words like "modern" mean different things to different people. Two or three links to sites, apps, or specific pages you like — with a sentence on what you like about each (the layout, the tone, the color use, the checkout flow) — do more work than a paragraph of adjectives. Include one or two examples of what you don't want, with the same specificity.

6. Success Criteria — How You'll Know It Worked

Define the metric or outcome you'll check against after launch: conversion rate, time-on-task, support ticket volume, or simply "our team can update this page without a developer." Without this, "success" becomes a matter of opinion during review, which is where projects stall.

Common Mistakes Non-Technical Founders Make in Briefs

• Describing a solution instead of a problem. "Add a chatbot" is a solution. "Users can't find pricing information fast enough" is the problem — and it might have a better answer than a chatbot.
• Skipping the target user because "it's obvious." It's rarely obvious to someone outside your company. A one-paragraph description saves days of back-and-forth.
• Leaving out the budget. Agencies design differently for $5k than for $50k. Omitting the number doesn't protect you — it just means the first proposal is a guess.
• Providing only positive references. Knowing what you dislike is just as useful as knowing what you like, and often faster to explain.
• No success criteria. Without one, "is this good?" gets decided by whoever has the loudest opinion in the room, not by whether it works.

You Don't Need All the Answers Before You Start

If you're missing a piece — you don't have a locked budget, or you're unsure who your ideal user really is — say so directly in the brief instead of leaving it blank. "Budget is flexible depending on scope, guide us" or "We think our user is X, but we haven't validated this" gives an experienced agency something to work with and signals where they should ask questions early rather than assume. A brief doesn't need to be perfect. It needs to be honest about what you know and don't know yet.

Send the Brief, Then Talk It Through

A written brief is the starting point for a conversation, not a replacement for one. The best collaborations still involve a kickoff call where the agency asks follow-up questions and pressure-tests assumptions before design work begins. What the brief does is make that conversation faster and sharper, because you've already done the thinking that would otherwise happen live, expensively, mid-project.

If you're about to brief a design or development partner and want a second pair of eyes before you send it, share it with us. We'll tell you what's missing and what will save you a revision round — no obligation.