How to brief a designer when you don't know what you want.

The most common reason a design project goes sideways isn't the designer. It's the brief. And the most common problem with a brief isn't that it's wrong — it's that it's vague in the places it needs to be specific, and specific in the places it should be open.

This is the checklist we wish every client filled in before we wrote a proposal.

The biggest brief mistake

Most briefs lead with aspiration: "We want a website that feels premium and converts well." Aspirational language sounds confident but communicates almost nothing. "Premium" can mean five different visual languages. "Converts well" can mean any of a dozen different metrics. A designer reading this brief has to guess — and the gap between their guess and your unspoken assumption is where every revision round comes from.

A good brief replaces aspirational language with specific constraints.

The 5 things every brief must contain

We use the same five-section template for every project, regardless of size. If a brief is missing any of these, we ask the client to fill them in before we estimate.

1. The business problem in one sentence

Not the design solution. The problem. "We get 3,000 visitors a month but only 12 demos, and our hypothesis is that the homepage doesn't qualify the audience clearly." This sentence tells the designer what success looks like — measured, not vibed.

If you can't write the business problem in one sentence, the project isn't ready to start. The discovery phase exists exactly to answer this.

2. Who the work is for, specifically

Not "potential customers." A person, role, and context. "CFOs at Series B startups, evaluating financial-modeling tools, usually while drafting their board deck." The more specific the audience, the more confidently the designer can make decisions that would otherwise need approval.

3. What success looks like, measurably

Numbers. Not "more conversions" but "demo bookings up 30% within 60 days of launch." Not "stronger brand" but "the brand audit shows green on questions 1, 3, and 10 within six months." (See The 1-day brand audit checklist for what those questions are.)

If the goal can't be measured, it can't be designed for — it can only be designed around.

4. Constraints, not preferences

This is the section most briefs get wrong. They list preferences ("we like clean designs") instead of constraints ("the page must work in IE11 / must be mobile-first / must launch by April 15").

Preferences feel helpful and aren't. They constrain the designer's options without constraining the problem. Constraints — real ones — are how the brief disambiguates. "Must work without JavaScript" is a constraint. "We like minimal designs" is a preference dressed up as one.

5. References, properly framed

Three reference examples, each annotated with one sentence on what specifically you like about it. Not "this whole site is great" — "the way they handle the case-study transitions is exactly the rhythm we want."

A reference without annotation is noise. A reference with one specific note is gold.

Preferences feel helpful and aren't. Constraints are how the brief disambiguates. — Egzecute project lead

Reference images: how to use them properly

The mistake most founders make with references is using them as visual targets. "Make ours look like this Stripe page" leads to a watered-down copy of Stripe.

The right use of references is vocabulary. You and the designer don't share enough visual vocabulary to discuss subtleties. References give you a shared one. "I like this kind of editorial weight" is harder to say than "I like the typography on the Vercel blog." The reference is the dictionary, not the destination.

A useful trick: bring at least one reference that is outside your industry. If you're a SaaS company, include a reference from an editorial site or a fashion brand. Cross-industry references are how original work happens — same-industry references produce category-average work.

A simple brief template

Here is the template we hand to clients, in full:

PROJECT
  [One sentence on what we're shipping]

BUSINESS PROBLEM
  [One sentence on the problem this work solves]

AUDIENCE
  [Role, stage, context — specific]

SUCCESS METRIC
  [Measurable target, with timeframe]

HARD CONSTRAINTS
  [Must-haves and must-not-haves. Real ones.]

REFERENCES
  1. [URL] — what specifically I like: [one line]
  2. [URL] — what specifically I like: [one line]
  3. [URL] — what specifically I like: [one line]

NOT IN SCOPE
  [What this project explicitly will not address]

DECISION-MAKERS
  [Who has approval authority. Capped at 2 people.]

That last section is the one most clients underrate. Projects where more than two people have approval power take three times as long and produce work no one is happy with. Name the deciders before work starts.

There is one honest exception to all of this. If you cannot fill in the business problem or the success metric — not "haven't yet," but genuinely cannot — then the brief is not the thing that's missing.

If you can't name the problem, you're not ready to commission the solution. Positioning first, design second. — Egzecute discovery note

We sell discovery as a one-week sprint precisely because so many projects skip it and then pay for it in rounds four and five, at design rates.

What the brief is for

A brief is not a contract. It is a conversation starter that ensures both parties walk into the kickoff with the same set of expectations. The best briefs are short — one to two pages — and specific where it matters.

Spend an afternoon writing a real one. The hours you invest in the brief are the same hours you would otherwise spend in revision rounds, just paid up front, at the cheap end of the project lifecycle.