Write a Sharper Brief
Turn a vague creative brief into something you can actually design from. Get Claude to act as a skeptical product manager (PM) and help you push back like a collaborator, not a critic.
The situation
A brief arrived. It uses the words "modern," "intuitive," and "user-friendly." There is no data, no user description, and no success metric. You have a design review in two weeks and nothing concrete to design from.
You'll flag every undefined term, send a professional pushback message, and walk away with a brief specific enough to open Figma.
What you walk away with
Every vague word in the brief flagged and named, with what each one is hiding
A professional pushback message ready to send, framed as collaboration not criticism
A specific, designable brief built from client answers, not your assumptions
Flag every vague or missing piece
Paste the brief you received and ask Claude to mark every phrase that is unmeasurable, undefined, or contradictory. Do not fix anything yet. Separating flagging from fixing keeps the analysis honest. If you fix as you go, you stop seeing problems.
# Prompt to use:
"Read this brief. Mark every word or phrase that is vague, unmeasurable,
or could mean different things to different people. Don't suggest fixes yet. Just flag."Generate the pushback message
Now ask Claude to write the message you will send back. Frame it as "I want to get this right," not "your brief is wrong." The goal is to sound like a thoughtful collaborator. Framing as collaboration rather than a list of questions reduces the chance the stakeholder gets defensive and stops responding.
# Prompt to use:
"Write a short, professional message I can send to the client.
Raise the key gaps in the brief, but frame each question as needing
clarity so I can design something that actually works.
Tone: collaborative, not combative. Max 150 words."Rewrite the brief with the answers
Once the client responds, paste their answers and ask Claude to write a tight, specific brief you can actually design from. This becomes your design north star. Rewriting after you have answers prevents you from designing around assumptions: the revised brief is only as strong as the information it is built from.
# Paste the client answers, then use this prompt:
"Here are the answers to my questions: [paste answers]
Rewrite the original brief into a specific, actionable design brief.
Include: the real problem, users and their constraints, what 'done'
looks like in measurable terms, visual direction, and out of scope."Common mistakes
Four failure modes that derail this process.
- Fixing problems as you flag them. The flagging step should produce a list of issues, not a revised brief. If you start fixing in the same pass, you stop catching problems in the parts you have already touched.
- Sending too many questions. If the list runs to 8 or 10 items, the client sees an interrogation. Cut to the 3 that would most change what you design. A shorter list gets a faster, more useful reply.
- Starting the rewrite before you have answers. The revised brief is only as good as the answers it is built from. Writing it from assumptions defeats the purpose of the whole process.
- Using vague framing in the pushback message. "I want to make sure I understand" works. "Your brief is unclear" does not. Claude can generate the message, but you should read it before sending to confirm the tone matches your relationship with the client.
What's next?
Evaluate your own designsNew guides, when they ship
One email, roughly weekly. CLAUDE.md templates, workflows I actually use, and the cut-for-length stuff that does not make the public guides. One-click unsubscribe.
Or follow on Substack