A product design studio can use AI to turn one review round into a revision brief by collecting comments with their screen, version and author; asking AI to group duplicates and identify decisions, questions and possible scope changes; then checking every proposed action against the original brief before the design lead issues a numbered list.
The important boundary is the approved brief. A client saying “make the account page simpler” may mean three small edits, a new navigation concept or an unagreed feature. AI can propose interpretations, but the studio should ask for a decision before estimating or building the ambiguous part.
Freeze the round before you ask AI to sort it
Choose a clear review window: the prototype version sent, the date feedback closes, the people authorised to comment and the deliverables they are reviewing. Keep the source comments in the design tool or an exported record. A chat transcript pasted without timestamps or screen references is poor evidence when somebody later asks why a change was made.
For a digital product, assign screen identifiers such as ONB-01 for onboarding and PAY-03 for the payment confirmation. Add the link to the exact prototype or file version to the round header. Figma's version-history guidance describes naming a saved version and adding a description of the changes, and its prototype help says comments added in a prototype also appear in the underlying design file. Those are useful anchors, but the studio's round log remains the record of what it promised to do.
In an illustrative five-screen account flow, two client reviewers leave 23 comments over four working days. The producer closes round two at noon, saves the review link and names the current version “Round 2 received”. A later comment is logged as round-three input unless the client and producer agree to reopen round two. That simple cut-off prevents a revision list from changing while a designer is implementing it.
Give each comment a source ID, even if the design tool already has a thread link. A useful record is R2-014, PAY-03, reviewer role, comment text, thread link, date, current status and original brief requirement. If the client sent feedback by email, record the message date and a short quote rather than pretending it was a pinned comment. Keep screenshots only when their rights and storage terms permit it.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowMake the log preserve disagreement and context
Do not feed AI a flat list headed “client feedback”. Put each item into a small structured record. Include whether the comment refers to an image, interaction, copy, accessibility issue or unresolved business rule. Capture the screen state too: the same “button is hard to find” comment has different meanings on a mobile menu and a desktop checkout.
| Field | Illustrative entry | Why it matters |
|---|---|---|
| Source | R2-014; PAY-03; prototype thread | Allows the design lead to return to the original wording. |
| Client wording | “Can we show the price earlier?” | Preserves the request without inventing an interpretation. |
| Current design | Price appears after option selection | Shows what would actually change. |
| Brief reference | Requirement 4.2: price after configuration | Exposes a possible change to an agreed rule. |
| Decision owner | Client product lead | Prevents an individual preference becoming an approval. |
A second example: one reviewer writes “add guest checkout”; another writes “require account creation so we can recognise returning customers”. A summariser may flatten both into “improve checkout”. Keep both source IDs and mark the pair as conflicting. The output should request a client decision on the purchase rule; it should not quietly select the path that seems easier.
If the comments contain customer names, unreleased product plans or proprietary design files, check the contract and the AI provider's data terms before uploading. Redact unnecessary identifiers and use a workspace approved for client material. A confidentiality clause may prohibit an external processor even when a tool advertises private workspaces. Document who approved the tool and what material was sent.
Design studios with loose intake can borrow the briefing questions from a design studio brief and revision workflow. For this task, the brief is already agreed: the challenge is keeping every proposed revision tied to it rather than reopening discovery in every review round.
Ask for candidate actions, not an automatic promise
Use AI after the intake is complete. Give it the approved requirement excerpts and the numbered comment log, not a vague instruction to “fix the design”. Tell it to cite source IDs, separate repeated comments, label unclear language and avoid inventing implementation details. A prompt can be short if its output schema is exact.
Role: assist a product design producer with round-two triage.
Inputs: approved brief excerpt and numbered client comments.
For each candidate action return:
source IDs | screen | requested outcome | proposed design action |
status: in scope / clarify / potential scope change / no action |
reason linked to the brief | client decision needed.
Merge duplicates only if the underlying outcome is the same.
Retain contradictory requests as separate rows.
Do not claim the client has approved a proposed solution.
An illustrative output might read: “R2-014 and R2-019 | PAY-03 | make price visible before final confirmation | test a persistent total beside option selection | clarify | requirement 4.2 places final price after configuration | confirm whether an estimated total is acceptable”. That is usable because it names the uncertainty. A bad output would say “move price to the first screen, approved”; neither the comment nor the brief supports that approval.
Read the source threads next to the AI table. A client may attach a screenshot whose arrow points at the wrong element, or write a reply that reverses an earlier request. The latest agreed thread position matters more than a summary of the first message. Figma's comment guidance distinguishes open and resolved comments; resolution in the tool should follow the human decision, not serve as proof that the design work is complete.
For a separate example, a client says “the save action feels risky” on a settings screen. AI suggests changing the button colour. The producer checks the recording of the review and finds the concern was that saving immediately emails customers. The actual revision is a confirmation step and clearer consequence copy. The AI suggestion becomes a discarded hypothesis, while the source comment stays visible in the log.
Decide whether each request belongs in this round
Use four statuses that a client can understand. “Included” means it fits the signed brief and the agreed revision allowance. “Clarify” means the outcome or decision owner is uncertain. “Change request” means it may add a deliverable, business rule, flow or material rework outside the agreed scope. “Declined or parked” means the client has explicitly decided not to act in this round. These are project decisions, not labels for AI to finalise alone.
The scope test is practical: compare the request with agreed screens, interactions, content responsibilities and acceptance criteria. Also check whether the new request changes a previously approved choice. “Make the error copy clearer” may fit. “Add an account recovery journey” may require new screens, content and testing. A small-looking button can conceal a new workflow. The producer should document why the request is tagged and invite an approval or estimate where appropriate.
Imagine an illustrative contract allowing two revision rounds for six core screens. Round one establishes the selected concept; round two refines copy and states. The client asks for a seventh screen showing subscription history. AI flags a probable change request. The studio does not tell the client it costs a particular amount from the prompt. It notes the dependency, asks for the necessary data and rules, and prices the extra work through its normal approval process.
Another example concerns an accessibility issue. A tester notes that a status is shown only by colour. Even if that omission is discovered late, the design lead should prioritise a correction and check what the agreed accessibility standard requires. Scope and responsibility still need a human discussion; AI should not use “out of scope” as a way to dismiss a defect in the studio's own deliverable.
For wider decisions about how AI fits concept, review and delivery, the design studio workflow tutorial provides context. Here the narrow decision is whether a specific comment becomes an action in a specific round. Keep that distinction visible in the log.
Turn accepted items into a buildable revision brief
Once a producer or design lead confirms status, turn only accepted items into tasks. Each task needs a before state, intended after state, affected screens or components, acceptance check, source IDs, owner and expected review evidence. A list that merely repeats client adjectives is not a revision brief. “Modernise the dashboard” gives a designer no bounded change to implement or verify.
For example, convert “the action is too hidden” into: “On ONB-01, move the primary continue action into the visible form footer at both supported widths; preserve the disabled state until required fields are complete; check keyboard focus order; show before-and-after captures.” The brief should still name R2-006 and link the comment. If no one has approved the specific placement, phrase it as a proposed solution for internal review.
A useful task list is ordered by dependency, not by the order in which comments arrived. First resolve a business rule, then change the flow, then revise copy and visual treatment, then test responsive and assistive states. AI can suggest that sequence, but the design lead checks it against the team's actual file structure and delivery dates. A shared component may make one change affect six screens even though only one comment mentioned it.
Illustratively, 23 comments produce 12 distinct issues: four duplicates, three clarifications, two potential scope changes and three straightforward fixes. Those counts are a hypothetical triage result, not a benchmark. Suppose the three fixes take an estimated 1.5, 2 and 3 hours, while the clarifications have no estimate yet. The studio's committed workload is 6.5 estimated hours for those fixes, not 6.5 hours for all 23 comments. Treat the estimates as planning inputs that the people doing the work can revise.
One more example: R2-009 asks for smaller cards, while R2-017 asks for more detail on each card. AI merges them because both mention cards. The design lead separates them: one is density, the other is information hierarchy. The revision brief proposes an expandable detail pattern and tests whether the compact state still surfaces the required facts. Source IDs remain on both subtasks so neither intent disappears.
Check the work against the source and version
Before returning the design, compare every accepted task with its source comment and the approved brief. Check the affected states at the sizes and interaction points the client reviewed. A static screenshot is insufficient if the request concerns validation, navigation or focus. Review the prototype as a user, then record the version to which each completed task applies.
Keep a simple evidence column: “done in version R2.1”, “checked by design lead”, “prototype link”, “client response pending”. Do not resolve all source threads at once. Reply to a thread with the specific change and link, or explain why it is pending a decision. The source tool may preserve old comments across versions; Figma's version-history page explicitly notes that restoring an older version does not remove later comments. That is another reason the round log needs its own status and version notes.
An illustrative quality check finds that the team moved the total earlier on PAY-03, but the total does not update when a user changes quantity. The comment was technically “addressed” in a screenshot, yet the interaction fails the agreed outcome. Reopen the task and test the underlying state change. AI is good at highlighting a missing acceptance criterion after the fact, but the design lead must observe the actual behaviour.
When comparing versions, describe changed screens and decisions in plain language: “R2.1: revised price placement after client confirmation; retained final confirmation wording; guest checkout remains undecided.” Avoid claiming a pixel difference proves why a change happened. For adjacent advice on turning loose feedback into a plan, the designer feedback planning tutorial is useful, but the log here is the accountable record for a product-design round.
Give the review a second pass by someone who did not perform the edits. That person should open the old and new versions, select two or three source comments at random, and follow each one through the log, task, design and response. If the trail breaks, fix the record before handoff. Sampling is especially useful when there are many small comments that look complete in a task board. It catches a common error: marking a task complete because a layer changed, while the user-facing consequence remains unresolved.
Track a few process measures without turning them into a promise of speed. Record the number of comments received, unique issues, decisions outstanding, scope questions, tasks accepted and tasks reopened after review. For the illustrative 23-comment round, a producer might notice that six comments lack screen references. The response is to improve the next review invitation: ask clients to pin comments to a screen and describe the outcome they want. Do not use that number as a score for the client's quality. It is a signal that the intake process needs clearer instructions.
When several people comment on one flow, schedule a short decision review before designers start the disputed work. Send a two-column choice: “Show an estimated total during configuration” and “Show only a final total after selection”, with the brief requirement and affected screens beneath it. Ask the authorised decision owner to choose or request a third option. An AI assistant can draft that choice note from the log. The producer must remove any invented claim about conversion, accessibility or technical feasibility before it goes to the client.
Keep a separate “no action” reason rather than silently deleting weak suggestions. For example, a reviewer asks to replace a clearly labelled icon with another licensed icon that the studio cannot use under the supplied asset terms. Record the constraint and offer an available alternative. If the client later asks why the icon stayed, the explanation is traceable. An AI summary that drops declined suggestions makes the next round look as though the studio ignored feedback.
Send a client note that closes decisions cleanly
Give the client a short cover note with the reviewed version, completed items, open decisions and proposed scope changes. Do not send an AI-generated task table without a human explanation. Clients need to know what they can approve now and what remains contingent. State a response deadline only if the project has one; do not invent urgency.
A sample note, with illustrative wording: “We have updated ONB-01 and PAY-03 in round-two version R2.1. Items R2-004, R2-006 and R2-014 are ready for review. Please confirm whether the price should appear before configuration is complete (R2-019). Guest checkout and the subscription-history screen would change the agreed flow; we can scope them separately after you confirm the desired behaviour.” This keeps acceptance and new work apart.
Ask for feedback on the changed items against agreed acceptance criteria. If the client replies “looks good except the old issue”, link that reply back to the open source ID rather than creating a new free-floating task. Record the authorised approver's decision and date. A positive comment from a stakeholder who cannot approve scope is feedback, not a contract variation or final sign-off.
There is also an ownership check. A studio may have the right to use client-supplied assets for this engagement but not to upload them into every AI service or use generated variants in a public portfolio. Product designs can contain third-party icons, licensed fonts, confidential product strategy and user research. Confirm the contract's IP, confidentiality and AI-use terms, and ask a qualified adviser if ownership or licence wording is unclear. Do not ask a model to decide who owns a design.
After the round closes, archive the input log, final brief, approved decisions, delivery link and version notes together. Keep only the data needed under the studio's retention agreement. The next round can start from a clean baseline: which items are genuinely new, which were declined and which remain open. That makes the next AI summary more accurate because it receives decisions, not a pile of old comments presented as fresh requests.
Further reads
- How Can AI Help Graphic Designers? Briefs, Mock-Ups, Revisions — Adapt the review method to graphic deliverables.
- Interior Design Client Questionnaire: Build and Summarise It With AI — Tighten the initial client brief.
- How to Use AI for Graphic Design: Brand Kits and Templates for Clients — Keep approved brand assets consistent.
- How Can AI Help Videographers Consolidate Client Revision Feedback? — Compare another timed revision workflow.
- AI Software for Construction Drawings: Catch Changes Between Revisions — See a stricter document comparison example.
- AI for UX Designers: Research Synthesis and Test Summaries — A studio workflow for turning interview notes and usability sessions into client-ready findings, with evidence checks at every step.
- AI Design Software for Clothing: Mood Board to Sample Brief — Move from inspiration to an annotated sample brief, with a practical check on generated flats, colours and ownership.
- AI Furniture Visualisation for Makers: Show a Piece in the Room — A maker-side workflow for a room-photo preview that supports decisions without pretending to be a measured installation drawing.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Figma help articles Add comments to files, Comment on prototypes, View and manage comments, and View a file's version history (checked 4 November 2026).