Walk Into Design Review With a Clear Ask, Not Just 'Feedback Please'
Most design reviews drift because nobody defined a useful outcome. Paste your context into Claude and get a review plan with the key decision framed.
Capture meetings without lifting a finger
Granola uses AI to transcribe and summarize your meetings automatically. Pair it with Claude Code via MCP to turn meeting notes into action items, tickets, and code.
Try Granola freehow it works
01 / 06
Design review is tomorrow. You're not sure what you're asking for.
You have screens. You have a Figma link. You don't have a clear question. 'General feedback' is not an agenda.
02 / 06
You paste your design context into Claude.
The Figma description, the design brief, what you were trying to solve, what trade-offs you made, what you're still unsure about.
03 / 06
Claude asks what decision you need from the room.
Reviews that don't end in a decision are just a show. One question about what you need changes the whole structure.
04 / 06
Claude builds a review structure with anticipated objections.
The key decision framed clearly, the trade-offs you made and why, likely questions from each stakeholder type, and your response to each.
05 / 06
You skim it and add what Claude missed.
The org context, the history, the one person who always asks about accessibility. Ten minutes, not an hour.
06 / 06
You walk in with one clear ask. You leave with a decision.
Not 'let me know what you think.' An actual outcome.
The prompt
Paste this into Claude.ai the morning before your review. The more specific you are about who's in the room and what you've already decided, the more useful the prep.
Click a violet field and type your own details, then copy.
What you get back
The decision you need from this review
You're not asking for feedback on the visual design. You're asking: do we proceed with the single-page checkout approach, or do we maintain the current multi-step flow for first-time users? That's a product and engineering decision that needs alignment before development starts. Frame it this way at the start: "I want to leave this review with a clear answer on the checkout structure before we move to prototyping."
Anticipated objections by stakeholder
Engineering lead: "Does single-page checkout work with our existing form validation?" This is a legitimate technical question, not resistance. Come prepared with: single-page is achievable with progressive disclosure; the validation logic doesn't change, just the rendering. If they push back hard, offer: "what would we need to validate technically before committing?"
Product lead: "Have we tested this with users?" Correct answer: no, this is a direction proposal, not a validated solution. What you've done: you've analyzed drop-off data that shows the address step is the biggest problem. The proposed direction addresses that. Testing comes after we align on direction. Don't let this objection delay the direction decision.
Marketing stakeholder: "Can we add the promo code field more prominently?" This is out of scope for this review. Say so directly: "promo field placement is on the list, but it's not what we're deciding today. I'll flag it for the next design pass."
What done looks like
A good outcome from this review: "We're aligned on single-page structure. Engineering will validate the form approach by Thursday. We schedule prototyping for next week." A bad outcome: "We'll think about it." Push for the first. If you're getting the second, ask directly: "What would we need to see to make this call today?"
Variations
Same shape, different review types.
Click a violet field and type your own details, then copy.
Click a violet field and type your own details, then copy.
Click a violet field and type your own details, then copy.
Tips and gotchas
The single most useful thing you can do is define the decision before you walk in. "I'd love your thoughts" leads to a 45-minute discussion that ends with no agreement. "Do we proceed with A or B?" leads to a 20-minute discussion that ends with an answer. Claude will help you find the real decision hiding inside your vague ask.
Prepare the strongest version of each objection, not the weakest. It's tempting to prepare for objections you can easily dismiss. Claude tends toward steelmanning: take its anticipation of the hard objection seriously, because that's the one that will actually come up.
Know the difference between "I don't like it" and "this won't work." Both are valid, but they require different responses. "I don't like it" is a taste conversation; get specific about what they'd prefer. "This won't work" is a constraint conversation; ask them to articulate the constraint clearly so you can design around it.
Ready to try?
Click a violet field and type your own details, then copy.
Need somewhere to deploy?
Railway gives you one-click deploys from GitHub with generous free tier. Perfect for shipping what Claude Code builds.
Deploy your first app on RailwayPick the right Claude plan for your workflow
Use our side-by-side comparison to match plan to workload so you never hit limits mid-sprint.
Open plan comparisonNew 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
