Using Claude to Synthesize Stakeholder Design Feedback

How do you use Claude to synthesize stakeholder design feedback?

You paste every comment you have collected — from email, Slack, and the Figma file itself — into one place, then ask Claude to group them by theme, flag where reviewers disagree, and produce a short summary you can act on. Instead of scrolling through a dozen comment threads before a review meeting, you read one document that says what people actually think and where they do not agree. Claude does the sorting and the first pass at grouping. Your team still decides what to prioritize and how to settle the disagreements.

This matters most on projects with more than a handful of reviewers: a stakeholder committee, a client with several departments weighing in, or an internal team where product, marketing, and a founder all have opinions on the same screen. The feedback rarely arrives in one channel. It shows up as a paragraph in an email, three short comments pinned to a Figma frame, and a Slack message from someone who saw the screen once and had a reaction. Reading all of it in order is not the same as understanding what it means for the design.

The short answer

Collect the raw comments in one document, however messy that document looks. Ask Claude to sort them into themes, note who said what, and call out any comment that contradicts another. Read the summary before your next review call instead of digging through three inboxes. Then decide what to change, what to defer, and who needs to weigh in on the disagreements. Claude can describe a disagreement clearly. It cannot tell you whose opinion should win.

Where does scattered stakeholder feedback usually come from?

On most projects, feedback does not arrive as a single organized document. It arrives in pieces, from whoever happens to be looking at the design that day, in whatever tool they had open.

None of these sources is wrong on its own. The problem is reading them separately. A marketing lead's Slack comment about the hero section and a support lead's Figma comment about the same section are talking about the same problem from two angles, but nothing forces you to notice that unless you go looking.

How do you pull feedback from email, Slack, and Figma into one place?

The collection step is manual and there is no way around that — someone still has to gather the comments. What changes is what you do once they are gathered. Copy the raw text of every comment into a single document: reviewer, source, date if you have it, and the comment itself, unedited. Do not clean it up first. Half-finished thoughts and contradictory notes are exactly what you want Claude to work with, because sorting through that mess is the point.

Once you have the raw list, the prompt itself can be simple: ask Claude to read every comment, group them into themes, name which reviewers raised each theme, and separately list any comments that conflict with each other. Paste the whole raw list in, comment by comment, with the reviewer's name or role attached to each one. The more context you give about who said what and on which screen, the more useful the grouping.

What should you include when you paste the comments in?

The quality of the summary depends on the quality of the raw list, not on how clever the prompt is. A few habits make a real difference to what comes back.

• Reviewer or role, every time. A comment with no attribution can still be sorted into a theme, but it cannot be weighed against a conflicting one, because you no longer know who holds each position.
• Which screen or flow it refers to. A short comment like "this feels cluttered" means something different on a pricing page than on a settings screen, and Claude can only tell the difference if you say so.
• The exact wording, not your interpretation of it. Paraphrasing a comment before you paste it in strips out tone, and tone is often the difference between a passing thought and a strong objection.
• Version or date, when you have it. Feedback on an old version of a screen can otherwise get mixed in with feedback on the current one, and the conflict it seems to create is not a real conflict at all.

None of this takes long to gather once you know to ask for it up front, and it saves a second round of clarifying questions later, when someone asks "wait, was that about the old design or the new one?"

How does Claude sort feedback into themes?

Claude reads for repeated concerns rather than repeated words. Five reviewers phrasing "the pricing table is confusing" five different ways still counts as one theme, not five. That is the part manual review misses most often: when everyone says the same thing in different language, it is easy to log five separate notes instead of noticing one real problem with five votes behind it.

That third row is the useful part. A plain list of comments would put "don't change it" next to two requests to make the button stand out and leave you to notice the contradiction yourself, usually mid-meeting. Asking Claude to flag conflicts explicitly means that contradiction is sitting at the top of the summary before anyone opens the file.

The grouping also picks up on how strongly something was said, not just what was said. A comment phrased as "might be worth a look" and one phrased as "this needs to change before we launch" can land in the same theme, but they carry different weight, and a good summary keeps that difference visible instead of flattening every comment into the same neutral tone.

How do you handle conflicting stakeholder opinions?

This is the part no synthesis tool can do for you, and it is worth being direct about that. Claude can tell you that the sales lead and the support lead disagree about the hero section. It cannot tell you which one is right, because that depends on things Claude was never given: who owns the decision, what data exists on actual customer behavior, and what the business is trying to protect. A clean summary turns a hidden disagreement into a visible one. Turning a visible disagreement into a decision is still a conversation between people.

In practice, the most useful output is a short list of flagged conflicts, written as plainly as possible: who said what, and where the comments contradict. Bring that list to the review meeting instead of trying to resolve it over Slack one reviewer at a time. It is much faster to settle a disagreement out loud, with both people in the room, than to guess at a compromise from written notes days apart. This is a related but different problem from turning raw interview transcripts or support tickets into insight, which we cover in our guide to using Claude for user research synthesis. That piece is about understanding what users need before you design; this one is about making sense of what your reviewers think about a design you have already made.

What does a clean feedback summary look like?

A summary that is actually useful before a meeting tends to have the same handful of parts, in the same order, no matter how messy the raw comments were.

• Themes. The recurring concerns, each with the reviewers who raised it, so you can see how much weight it carries.
• Conflicts. The comments that contradict each other, named plainly, with no attempt to guess a resolution.
• Quick wins. Small changes nobody disagreed on, which can usually be made without a meeting at all.
• Open questions. Anything that needs a decision maker in the room, not another written comment.

Keeping the same structure every round means reviewers start to recognize it, and the meeting itself gets shorter, because half the agenda is already answered before anyone speaks.

What mistakes do teams make when using Claude for feedback synthesis?

• Pasting in cleaned-up notes instead of the raw comments. Summarizing your own summary loses the detail that actually matters, like tone and who felt strongly about what.
• Leaving out who said each comment. A theme raised by one junior reviewer and a theme raised by three department leads are not the same weight, and a summary without names or roles hides that difference.
• Treating the output as the final decision. The summary tells you what people think. It does not tell you what to build. Someone still has to decide.
• Skipping the conflict flag. If you only ask for themes, contradictions get folded into one vague summary line instead of surfaced as a decision that needs to be made out loud.
• Doing this once and never again. Feedback synthesis is most useful as a habit before every review round, not a one-time cleanup on a single messy project.

A quick checklist before your next stakeholder review

• Have you gathered comments from every channel (email, Slack, and Figma), not just the one that is easiest to search?
• Does every comment in your raw list have a reviewer or role attached to it?
• Did you ask Claude to flag conflicts separately, rather than only listing themes?
• Is there a short list of quick wins that can move forward without a meeting?
• Does the open-questions section name who needs to make each decision?
• Are you using the same summary structure every round, so reviewers know what to expect?

If most of these are a yes, you are ready to bring the summary into the room instead of the raw comment threads. This is also where a scattered feedback process usually shows up in a wider agency workflow. See our notes on using Claude across an agency-client workflow for how synthesis fits alongside the rest of a project.

Does this replace a proper design review meeting?

No, and it is not meant to. A synthesized summary makes the meeting shorter and more focused, because the group is not spending the first twenty minutes reading comments out loud to catch each other up. It works best paired with a clear review process to begin with — our guide on running a UX audit covers how to structure a review so the feedback you collect is easier to act on in the first place. Synthesis cleans up what people already said. It does not replace deciding what to do about it.

The takeaway

Stakeholder feedback rarely arrives organized, and it does not need to. Collect it wherever it lands, let Claude sort it into themes and flag where people disagree, and bring a short summary into the room instead of a pile of comment threads. The sorting can be automatic. Deciding what to prioritize, and whose opinion wins when two reviewers disagree, is still a job for your team. If you want a second set of eyes on how your review process is set up, tell us about your project and we will help you figure out where it is breaking down.