Design Brief Prompt for Client Work

What this prompt does

A design brief prompt turns the raw notes from a kickoff call into the document that directs the design work: the problem being solved, who it's for, what can't change, and how anyone will know the result worked. It runs after the project is won, not before, and its reader is whoever has to open a blank canvas on Monday.

The distinction matters because the two documents get confused constantly. A proposal argues that you should be hired — scope, deliverables, timeline, price, aimed at a client deciding whether to sign. A brief assumes all that is settled and answers a different question: given that we're doing this, what are we actually trying to change? Same project, opposite jobs.

Most briefs fail in the same place. They describe the deliverable ("a new homepage") in loving detail and never state the problem, so three weeks later nobody can settle an argument about a hero image because there's no agreed standard to settle it against. Nielsen Norman Group's guidance on problem statements makes the case better than I can: a problem framed as a solution has already thrown away every alternative solution, including the good ones.

So the prompt below refuses to let the deliverable stand in for the problem.

The prompt

Write a design brief from the kickoff notes below. Follow every rule.

**Client and what they do:** [ONE SENTENCE — the business, not the industry]
**What they asked for:** [THEIR WORDS, verbatim, even if it's "a fresh look"]
**Why now:** [THE TRIGGER — a launch, a drop in signups, a merger, a competitor, or "unclear"]
**Who the work is for:** [THE END AUDIENCE, not the client contact. Include what they currently do instead.]
**What must not change:** [BRAND MARKS, PLATFORM, LEGAL/ACCESSIBILITY REQUIREMENTS, EXISTING SYSTEMS, BUDGET CEILING]
**What already exists:** [CURRENT SITE, APP, DECK, PACKAGING — and what specifically is wrong with it]
**Who signs off:** [NAMES AND ROLES, and who can overrule whom]
**Dates that are real:** [ANY FIXED EXTERNAL DATE — trade show, funding round, seasonal deadline]
**Notes, unedited:** [PASTE THE KICKOFF NOTES]

Return the brief in these sections, in this order:

1. **Problem** — one or two sentences, stated as a problem and not as a deliverable. No solution words.
2. **Audience** — who they are, what they're trying to do, and what they do today instead. If the notes only describe the client and not their customers, say so here rather than inventing a persona.
3. **Success criteria** — three to five, each one observable. Every criterion must name what gets measured and by when. If the notes contain no measurable outcome, write the criteria as questions addressed to the client instead of guessing at numbers.
4. **Constraints** — split into "fixed" and "assumed". Anything you inferred rather than read goes in "assumed".
5. **Scope boundary** — a short "not in this project" list, drawn only from things the notes actually raised and set aside.
6. **Decision-makers** — who approves, in what order, and what happens when two of them disagree.
7. **Open questions** — everything you needed and didn't get, phrased so the client can answer each in one line.

Rules:

- Never write a number that isn't in the notes. No invented conversion rates, traffic figures, or budgets. A missing number becomes an open question.
- The Problem section may not contain the words redesign, refresh, modern, clean, or the name of any deliverable.
- "Better", "engaging", "user-friendly" and "professional" are banned everywhere. Replace each with the observable thing that would make someone say it.
- If the stated reason for the project and the stated success criteria don't line up, flag the mismatch in one line at the top rather than smoothing it over.
- Keep the whole brief under 600 words. A brief nobody rereads isn't doing its job.

End with a single sentence: what this project is trying to change, for whom.

How to use it

Paste the kickoff notes raw. Don't tidy them first — the contradictions and the half-sentences are the useful part, and cleaning them up beforehand means you're the one deciding what mattered, which is the decision you wanted a second pass on.

"We need something that pops" is more useful to the model than your translation of it, so fill in "what they asked for" with what the client actually said, quoted. Your translation is already an interpretation, and the brief should show its work.

The section that earns the most is Open questions. Send it to the client verbatim, as a list, before you start designing. Two or three of those answers usually move the project more than the rest of the brief combined.

If the output reads like it could describe any client, the notes were thin. That's information — go get more.

What each section has to settle

Example output (partial)

Kickoff notes said: regional bakery, six locations, wants "a modern website," mentioned that online orders dropped after they switched ordering platforms in March.

Problem. Customers who used to order online are calling the shop or not ordering at all since the March platform change; the drop is concentrated in repeat customers rather than new ones.

Success criteria.

1. Online orders return to at least the February volume within eight weeks of launch — February figure needed, see Open questions.
2. A returning customer can reorder a previous order in under 30 seconds, measured on a phone.
3. Fewer than 5 order-related phone calls per location per day, down from the current volume — current volume not supplied.

Constraints — assumed. That the March platform stays. Nothing in the notes says whether replacing it is on the table, and the answer changes the entire project.

Open questions. What were February's online order numbers? Is the ordering platform replaceable, or fixed? Who at the company can approve menu photography?

The model never invented the February number. It named the gap three times and put it back in the client's court.

Variations

For an internal project with no client

Swap "client" for the requesting team and add a line for what happens if we do nothing — internal projects rarely have a hard trigger, and naming the cost of inaction is what stops them stalling in month two.

For a rebrand rather than a project

Add what must survive — the equity in the current identity that customers would miss. Ask for it as a separate section before Constraints, because a rebrand brief that only lists what's changing produces work that's unrecognisable and technically on-brief.

To pressure-test a brief you already have

Paste the existing brief in place of the notes and ask for the Open questions section only. It's the fastest use of this prompt and the one I reach for most.

For a pitch you haven't won yet

Ask for the Problem and Audience sections alone, then say what you'd need to answer the rest. Walking into a pitch with the questions is a stronger position than walking in with assumptions.

Common pitfalls

• Don't let the client's requested deliverable become the Problem section. "They want a new homepage" describes the purchase, not the trouble that caused it, and a brief built on it can't tell you when you're done.
• Don't accept success criteria without dates. "More signups" is satisfied by one extra signup in four years.
• Don't skip the assumed-constraints split. The single highest-value thing this prompt produces is a visible list of what the model — and, usually, you — filled in without being told.
• Try instead: run the brief past whoever will actually do the design work, not the account lead. The question is whether they could start Monday from this document alone. If the answer is no, the missing thing is nearly always the audience section.

Who uses this prompt

• Designers: freelance and studio, turning a kickoff call into something the whole project can be argued against later. More in prompts for designers.
• Marketers: briefing an agency or a contractor, where the brief is the only artifact that survives the handoff. See prompts for marketers.
• Small business owners: commissioning design without a creative director in-house, which is exactly when a vague brief gets expensive. See prompts for small business owners.

Both ChatGPT and Claude handle this well, and Anthropic's prompt engineering guidance explains why the banned-words rule pulls so much weight here — a model will produce "clean, modern and user-friendly" forever unless something in the instruction makes those words unavailable. Take the words away and it has to describe the actual thing instead.