How to brief a designer: a 4-part template for founders

The most expensive design hour I've ever billed was the first hour of an engagement that lacked a real brief.

The founder said "let's see where you can plug in" — which sounded easy and friendly and turned out to mean six weeks of misalignment, two scope changes, and an output neither of us was happy with. Both of our faults. Neither of us had a brief precise enough to detect we disagreed.

After thirty-something engagements, here's how I think about briefs now — both as the person writing them (when I'm hiring help) and the person reading them (when founders are hiring me).

What a bad brief looks like

A bad brief sounds like one of these:

• "We need to redesign the dashboard."
• "Make the onboarding feel less heavy."
• "Could you take a look at the product and let me know what you'd improve?"
• "We're trying to be more visually polished."

Each of these gives the designer enough rope to produce something. None of them give them enough constraint to produce the right something.

The signal is that you can't tell, from the brief alone, what would count as success. If "success" is undefined, the designer optimizes for whatever they can defend in the review meeting — which is usually visual quality. You get pretty work that doesn't move your business.

The four parts of a brief that actually works

A working brief has exactly four sections. More than that and you're writing a spec; less than that and you're missing something the designer needs.

1. The problem (in one sentence)

This is the thing that's broken right now, in business terms. Not a solution. Not a request. The problem.

Examples:

• "Activation rate has been at 28% for two quarters and we don't know why."
• "Three of our top customers in the last call cited that our reporting feature is harder to use than the competitor's."
• "We're presenting at our Series A in 8 weeks and the product visually doesn't match the polish of our deck."

If you can't compress the problem into one sentence, you don't yet understand it well enough to brief someone on it. The compression itself is the work.

2. The constraints (the unsexy section)

This is the section that gets skipped, and it's the one that determines whether the engagement works.

Constraints include:

• Timeline: When does the work need to ship? Hard deadline or flexible?
• Budget: What's the dollar range you're prepared for? Don't hide this — it scopes the work.
• Team: Who else will be involved? Who has approval power? Whose feedback can the designer mostly ignore?
• Stack: What's the engineering team using? What can / can't be changed in the build?
• Existing assets: What's already designed, half-designed, or out-of-date?

The most common founder failure mode here is hiding constraints because you think they make the engagement less attractive. The opposite is true. A senior designer reads the constraints and gets excited — they reveal where the actual leverage is.

3. What success looks like

A measurable definition of "we did it." Three flavors that work:

• Quantitative: "Activation rate from 28% to 35%."
• Decision-based: "Team aligned on whether the dashboard needs a full redesign or surgical fixes."
• Artifact-based: "Hi-fi prototype of the v2 onboarding, plus a written summary of the three options we considered and the rationale for the chosen direction."

The quantitative version is hardest to write but easiest to evaluate. The decision-based version is best for early-stage strategic work. The artifact-based version works for narrow, well-scoped tactical jobs.

What doesn't work as a success criterion: "we'll know it when we see it." This isn't honest skepticism, it's a recipe for endless iteration. If you genuinely don't know what success looks like, the engagement should start with a one-week scoping phase to define it.

4. The non-goals

Underrated. Listing what's out of scope explicitly makes the brief 2x sharper.

• "We're not redesigning the navigation in this engagement."
• "We're not addressing mobile in v1."
• "We're not testing pricing — that's a separate project."

This protects both sides. The designer can confidently push back when scope creeps. The founder can confidently say "save that for next quarter" when a tempting tangent appears.

A template you can copy

Here's the actual structure I send to founders writing briefs for me:

---

Project: [Two-word project name]

Problem: [One sentence describing the business problem.]

Why now: [One sentence on what changed recently that makes this urgent.]

Constraints:

• Timeline: [hard date or range]
• Budget: [dollar range]
• Team: [who's involved, who decides]
• Stack: [tech stack, key things that can't change]
• Existing: [what's already in place]

Success looks like:

• [Primary success metric or outcome]
• [Secondary metric or signal]

Non-goals:

• [Thing 1 that's explicitly out of scope]
• [Thing 2 that's explicitly out of scope]

Open questions (optional, max 3):

• [Things you genuinely don't know the answer to]

---

A brief like this fits on one Notion page or one email body. If yours runs longer, the brief is doing the wrong work — it's becoming a spec.

The conversation that should follow

After you send the brief, the designer's response tells you a lot. A senior designer will:

1. Confirm the problem, often by reframing it slightly. ("So you said activation, but it sounds like the issue is third-session retention. Want me to look at both?")
2. Pressure-test one or two of the constraints. ("Is the 8-week deadline negotiable if we deliver the priority work in 4 weeks?")
3. Ask clarifying questions about non-goals. ("If we're not redesigning navigation but the new onboarding flow needs new nav patterns to work, should that be in scope?")

If the designer just says "great, let's start" — they're a vendor, not a partner. I covered why that distinction matters elsewhere. Lean toward the partner.

What changes when the brief is good

The whole engagement compresses. Less reframing time at the start. Less drift in the middle. Cleaner evaluation at the end. A 12-week engagement on a tight brief usually delivers more than a 16-week engagement on a fuzzy one.

The brief is also where the ROI conversation starts. The success criteria from section 3 are the metrics you'll measure against — there's no separate analytics setup needed.

The brief is the leverage. It's also the cheapest part of the project — usually three to four hours of writing, maybe two rounds of feedback. Worth investing in.

If you're about to brief a designer and want a second pair of eyes on the brief itself, drop me a note. I read briefs for free for early-stage founders when I have time — it's the cheapest way to save you from a misaligned engagement.

If the project ends up being something I could help with, we can talk about that on the same call. If not, I'll point you at the right kind of person to look for. The shape of the help you need is usually obvious from the brief.