For Designers
Write a Sharper Brief
Turn a vague creative brief into one you can design from. Have Claude play a skeptical PM and help you push back like a collaborator, not a critic.
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.
Follow along:
You need: The Claude desktop app for Mac or Windows. It can read a folder of your files.
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.
what you should see
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.
what you should see
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.
Click a violet field and type your own details, then copy.
what you should see
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 read Product Field Notes, the Substack