--- title: "AI Design Critique Makes Human Reviews Better" description: "AI design critique is not a replacement for a human design review. Run it first, brief it with a clean Figma zone and real project context, and the human session can spend its time on the decisions that actually matter. It improves quality and speed at once: more complete..." publishDate: Tue Oct 27 2026 00:00:00 GMT+0000 (Coordinated Universal Time) author: Romain Penchenat language: en tags: ["ai design critique","design review process","figma mcp","product design","ai agents"] canonical: https://blog.romain.garden/blog/ai-design-critique-makes-human-reviews-better/ estimated-read-time-in-minutes: 7 --- AI design critique is not a replacement for a human design review. Run it first, brief it with a clean Figma zone and real project context, and the human session can spend its time on the decisions that actually matter. AI helps product designers in two ways. It accelerates steps that used to eat the calendar, and it raises the quality of the work itself. **AI design critique** is one of the few practices that does both at the same time. You get a more complete read on what you just designed. Edge cases, hard questions, and things you did not anticipate show up earlier, so prioritization gets cleaner and you spend less time cleaning up problems after the fact. Quality goes up. The project also moves faster, because there are fewer round trips later. It is not a substitute for a human design review. I run the AI pass first so the obvious notes are already on the table, thought through, and often fixed. When other designers or product managers finally see the work, the room can stay on the complex, high-impact decisions instead of tripping over basics. *** ## AI Design Critique Belongs Before Human Review > **Run the AI pass before you invite peers, so human critique can start where the interesting arguments actually are.** My design review process is now a sequence, not a single meeting. Discovery and research still come first. I design a first version of the solution. Then I launch the AI critique, read it, and decide — point by point — whether each note is right, wrong, or worth a fix. I iterate on the file. Only then do I share it with peers. The human session is still a real critique: where are the opportunities, and are we aligned on the big decisions? The difference is what that session is *for*. Without the AI pass, too much of it gets spent on small, obvious feedback. With it, those notes have already been found. I have had time to agree, disagree, or fix them. I also show up with better argumentation, because I have already had to answer more questions about my own work. That is the whole point of putting **AI design critique** upstream. It is complementary. It does not replace the people in the room. It makes the people in the room more useful. 1. Discovery and research 2. First version of the solution 3. AI design critique 4. Read, decide, and iterate 5. Human design critique 6. Iterate again *What changes when AI critique runs first* | | Human review only | AI critique first | | ----------------------- | ---------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Basic feedback | Still lands in the room — Peers spend time on small, obvious notes that could have been found earlier. | Already found, often fixed — The obvious notes are handled before anyone else opens the file. | | What the session is for | Details crowd out decisions — The critique drifts toward small, obvious notes instead of high-impact choices. | Complex, high-impact topics — Peers can stay on the arguments that actually move the project. | | How you show up | Debates start from scratch — You have not yet had to answer the extra questions the AI pass would have raised. | You already have the argument — You have asked yourself more questions, so alignment talks go further, faster. | | After the review | More late surprises — Edge cases and missed questions turn into back-and-forth once the file is already in play. | Fewer problems after the fact — You anticipated more of them during the AI pass, so the project moves with less rework. | ## Brief an AI Design Critique With Project Context > **A clean Figma link is not a brief. Quality jumps when the agent knows the KPI, the problems, and the evidence behind the file.** The method is not complicated. A few details decide whether the critique is usable. I run this in Claude, and it works with other agents too — ChatGPT, Codex, Gemini, or whatever you already use. I do not rebuild a custom skill from scratch. I reuse Anthropic's design-critique skill, which is portable across agents, and I wrap it in a prompt template that always includes the same inputs. - A **delimited Figma link**, not a dump of the whole file. Draw a clean zone around the deliverables as you would actually ship them — no drafts, no screenshots, no clutter that could pull the agent off the work. Right-click that area and share that link only. - A one-line **objective**: which KPI you are trying to move, why, and how. Short is enough. It tells the agent what “good” is for this project instead of scoring the screens against generic taste. - A **context document** that recaps the problems the initiative is trying to solve, the objectives in more detail, the KPIs you will actually track, plus the data analysis and user feedback you already have. That is the change that most improved the output: feedback starts coming from the project’s real evidence, not from the model’s general culture. - Optionally, a **target user flow** for the solution you are designing. When I have one, the agent understands the logic between screens and wastes less time on comments that ignore how the flow is supposed to work. I also lock the output. I ask for the classic design review in the format of the Anthropic skill, plus a wording pass: a closing section that lists every line that is not native US English, explains why, and proposes a replacement. And I ask for the result as a Claude Artifact — a small standalone page with a link I can archive and share — because a critique buried in a chat is hard to find again. Other agents have close equivalents. Those inputs and that output lock are one message. This is the template I paste: ```text /design-critique You're a senior product designer working for COMPANY_NAME. Run a design critic of the following design: FIGMA_LINK Project target: PROJECT_TARGET Context: CONTEXT_DOCUMENT_LINK Target userflow: USERFLOW_LINK Include in your review a wording check: everything should be Native American English. List all potential typos and non-native-feeling American english content. Take your time and produce an artifact as an output. ``` None of that works well without Figma MCP. If you only paste a Figma URL, the agent tries to open a browser and take screenshots. It is slow, it burns tokens, and the critique is worse. Connect the MCP so the agent can navigate the file you actually shared. ## Treat AI Design Critique as Questions, Not Answers > **At least half of the notes are worth dismissing. The value is deciding, calmly, which half — and knowing why.** Getting the document is not the end of the **design review process**. You still have to read it with a critical eye. Feedback is never the truth. It is a set of questions. That stays true when the author is an AI. I dismiss at least 50% of the notes I get. Some are uninteresting. Some miss the project context. Some I simply disagree with, from experience. That is not a failure of the method. Going through the list point by point, without stress, is the point: is this right or wrong, can I check it against data, do I want a fix, or do I skip it? You get two returns from that pass. You iterate on the design quickly where the note is good. And you get more confident in the choices you refused, because you already know why. If the same point comes back in a human critique, the argument is already built. The method still has limits, and they matter. Bad framing produces bad feedback — the same as with a human. If you do not present the problem, the objectives, and the data that pushed you in a direction, the critique will not be interesting. Do not skip that part. The second limit is structural. AI is weak at questioning the essence of the project and the big principles of the solution. It is strong at implementation details, solid patterns, and edge cases you forgot. It will not seriously challenge why you chose those entry points, or why the structure looks like that. Those questions still belong to you, and to a human design critique. I have not gotten convincing results from AI on that layer. **Quick check** What is AI design critique actually strong at? - Questioning why you chose those entry points and that structure - Replacing the human design critique altogether - Checking implementation details, patterns, and forgotten edge cases **(correct)** Use it to catch details, patterns, and missed edge cases. Keep the questions about the essence of the project — entry points, structure, big principles — for yourself and for a human review. *** ## Final Thoughts AI design critique earns its place when you brief it like a colleague and read it like a skeptic. Give it a clean Figma zone, the real objectives, and the evidence behind the work. Connect Figma MCP so it can actually see the file. Then keep the human review — now pointed at the decisions the model will not challenge for you. If this is not in your process yet, try it on the next project. The quality gain is real. So is the speed, for the unglamorous reason that fewer problems arrive after you thought the design was done. *** ## FAQs ### Does AI design critique replace a human design review? No. It is a complementary step you run first so basic notes are already found, thought through, and often fixed. The human session can then focus on more complex, high-impact decisions. ### What should you include in an AI design critique prompt? A delimited Figma link to a clean deliverable zone, the project objective and KPI, a context document covering problems, detailed objectives, KPIs, data analysis, and user feedback, plus an optional target user flow. Ask for the design-critique skill format, a native US English wording section, and a shareable Artifact-style output. ### Why connect Figma MCP before asking for a design critique? Without the MCP, the agent tries to open a browser and screenshot the file. That is slow, consumes many tokens, and produces weaker feedback than letting the agent navigate the Figma you shared. ### What is AI design critique bad at? It is weak at questioning the essence of the project and the big principles of the solution, including why you chose those entry points or that structure. It is much stronger on implementation details, established patterns, and forgotten edge cases.