Critique Loops with Agents

Open by naming the gap this whole course addresses: most teams say critique matters and then run it as an occasional meeting that depends on whoever has spare time and seniority that week. The output is a handful of comments on the screens that happened to be presented, with no record of what was checked or why.

This module is about the structure of a critique loop where an agent does the inspection and the designer makes the calls. The agent is not the critic in the sense of taste; it is the first reviewer in the sense of coverage — every state, every breakpoint, every screen, against criteria the team wrote down. The designer's role shifts from generating all the observations to triaging findings and owning judgment.

Set expectations on scope. This module covers the loop itself: dimensions, evidence, severity, the triage gate, and cadence. Modules 2 to 5 take the same loop into heuristic evaluations at scale, visual regression evidence, accessibility and content review, and per-PR design review. Everything later in the course assumes the vocabulary established here.

Walk through the bullets as failure modes the audience will recognise. Time is the obvious one: inspecting one flow properly — every state, every breakpoint, the copy, the focus order — takes hours, and design calendars do not have those hours. Seniority is the quieter one: the people whose critique is most valuable are the leads, and leads are the most over-booked people on the team, so their review attention gets rationed to whatever is politically loudest.

Recency bias is structural. Critique sessions cover what someone chose to present, which means the work that gets reviewed is the work someone is proud of or worried about. The screens that ship through small PRs without ever appearing in a review deck never get critiqued at all. Coverage compounds this: even when a screen is reviewed, it is usually reviewed in its happy state on a designer's large monitor, not in its error state at 390 pixels.

The last bullet — no record — is what makes the rest unfixable. Without a written account of what was checked against which criteria, every review starts from zero, repeats the same observations, and cannot be improved. The loop in this module exists to make the criteria, the evidence, and the decisions explicit and reusable.

This is the most important slide in the module: critique only works when what good means is written down before the inspection starts. Ask an agent to review this design and you get the visual greatest common denominator of its training data — clean, modern, could be more consistent. Ask it to inspect six named dimensions against a stated user job and you get findings you can act on.

The six dimensions on the slide are a strong default set, drawn from the school's critique-loop article, but stress that they are a starting point, not a universal checklist. Different artifacts need different dimensions: a checkout flow needs trust, recovery, and price clarity; a dashboard needs density, filters, and table behaviour; a marketing page needs promise clarity, proof, and conversion path. The act of choosing dimensions for the artifact is itself design work, and it is human work.

It is worth noting that published critique skills do the same thing with different labels. Huashu Design's expert critique, for example, scores five dimensions — philosophy coherence, visual hierarchy, execution craft, functionality, and innovation — and outputs a keep/fix/quick-wins list in about three minutes (as of mid-2026). The labels matter less than the principle: named dimensions, declared up front, applied consistently.

Position the agent precisely, because both over-claiming and dismissing it cause problems. The agent's strengths are coverage and consistency: it will inspect the error state at 390 pixels with the same care as the hero screen on desktop, it will apply the same six dimensions to the fortieth screen as to the first, and it will do it again next sprint without fatigue or politics. No human reviewer can offer that, and no team can staff it.

Its weaknesses are the mirror image. It is literal — if a dimension is vaguely written it will check it vaguely or invent an interpretation. It has no taste: it cannot tell you which of five competent layouts is right for this brand, and if you ask it to, it will answer confidently anyway. That is why the critique pass must be read-only and findings-only: the moment the agent starts fixing what it found, you have lost the chance to decide which findings were actually right.

The closing framing from the article is worth quoting in your own words: the agent should not behave like a judge handing down taste; it should behave like a reviewer helping the designer make the next decision. Inspection scales. Judgment does not, and should not.

Walk the diagram in order and name the owner of each step. Step one is the artifact plus its evidence packet: the screen or flow itself, screenshots covering states and breakpoints, the route and component files, the copy, and the brief with its review criteria. The quality of the critique tracks the quality of this packet — an agent that can only see one happy-path screenshot can only critique one happy-path screenshot. Step two is the critique pass: agent-run, read-only, against the named dimensions. Step three is the findings list, one record per issue, each with severity, evidence, user impact, and the smallest recommended fix.

Step four is the human triage gate, and it is the hinge of the whole loop. The designer accepts, rejects, or defers each finding, and marks the ones that are genuinely judgment calls. Nothing is fixed before this gate. Step five is the revision pass, scoped strictly to the approved list — no new direction, no opportunistic improvements. Step six is the re-critique: same dimensions, fresh screenshots, confirming fixes and checking for regressions. Step seven is the ship decision, which is human, full stop — a clean findings list is evidence for the decision, not the decision itself.

Point at the dashed feedback line. When the same finding keeps recurring across artifacts — the same spacing drift, the same missing empty state — that is a signal it belongs in the harness as a named dimension or an executable check, so future critique passes catch it automatically. That feedback line is how the loop gets cheaper over time.

Spend time on the anatomy of the example, because the format is what makes the loop work at scale. The severity is stated first, so triage can happen by scanning. The evidence names a concrete, checkable fact: at 390 pixels the form precedes the plan summary, and the desktop layout does not. Anyone can verify it in thirty seconds, which means the triage gate is fast. The user impact translates the observation into consequence — a buyer pays without seeing the price — which is what lets a designer or product owner weigh it against everything else competing for the sprint.

The recommended fix is deliberately the smallest useful change. Agents are prone to turning one observation into a redesign proposal; the format constrains them to a single, scoped suggestion the designer can accept, modify, or reject. The owner field matters in team settings: an agent can recommend that a payment summary move higher on mobile, but whether that fits product, legal, and revenue constraints is not its call.

The contrast to draw is with the feedback most critique sessions actually produce: the payment step feels a bit cramped, can we make the summary more prominent. That comment might be pointing at the same problem, but it cannot be triaged, verified, or assigned. Evidence is what separates a finding from a vibe.

Four levels is deliberate. Teams that invent seven-point severity scales spend their triage time arguing about whether something is a 3 or a 4 instead of deciding whether to fix it. Blocker and important carry the real weight: blockers stop the user or expose them to a serious mistake, important findings let the user continue but cost comprehension, trust, or speed. Polish exists so that consistency issues get recorded without competing with user-facing problems for attention.

The question level is the one most teams forget and the one most specific to working with agents. A literal reviewer will regularly hit genuine ambiguity — the brief says emphasise the annual plan, but the legal copy requires the monthly price to appear first; which wins? A good critique setup tells the agent to surface that as a question rather than guessing, because a guess presented as a finding pollutes the triage gate with invented certainty.

Severity is assigned by the agent in the first pass and corrected by the human at the triage gate. Expect to downgrade some findings and occasionally upgrade one — the agent does not know that the cramped summary is on the screen your biggest customer complained about last quarter. That correction is itself useful signal: if you keep downgrading the same class of finding, the dimension it comes from is written too aggressively.

This distinction is the third learning objective of the module and the one that determines whether the loop helps or quietly erodes design ownership. Actionable findings share a shape: a stated criterion was violated, the evidence is in the files or the screenshots, and the fix is mechanical — add the focus state, replace the hardcoded colour with the token, write the missing error state. These are exactly the findings the revision pass should consume, and routing them to a human reviewer wastes the loop's whole advantage.

Judgment calls share a different shape: more than one competent answer exists, and choosing between them requires context the agent does not have — what the brand stands for, what failed last time, which stakeholder is already nervous about this flow, what the roadmap needs this screen to become. The danger is not that the agent refuses these; it is that it answers them fluently. An agent asked whether the dashboard should lead with the chart or the table will pick one and argue for it. If that answer slides through triage unexamined, taste has been outsourced one plausible-sounding finding at a time.

The practical habit: at the triage gate, explicitly tag each accepted finding as fix or decision. Fixes go into the scoped revision prompt. Decisions go to a person, a conversation, or a follow-up exploration. Findings tagged question by the agent are almost always decisions.

The contract is where everything from the previous slides becomes a reusable prompt. It states the user job, lists the evidence the agent must inspect, names the dimensions, fixes the output format, and — just as important — states what the agent must not do. The prohibitions are not decoration. Left to its defaults, an agent asked to review a screen will frequently propose a new direction, rewrite copy in a voice it invented, or produce a wall of polite commentary in which the two findings that matter are paragraphs five and eleven.

The contract also separates critique from revision structurally, not just by request. The critique prompt ends at findings; the revision prompt is a different prompt that takes only the approved findings as input and carries its own constraints — do not address rejected findings, do not introduce a new visual direction, keep changes scoped to the affected files, report what changed. Keeping them as two prompts rather than one is what makes the triage gate real rather than ceremonial.

For teams running this regularly, the contract belongs in the repository — as a skill, a saved prompt, or a section of the design harness file — so every critique pass starts from the same standard rather than from whatever the requester remembered to type that day. That is also where the dashed feedback line from the loop diagram lands: recurring findings get added to the contract's dimensions.

Cadence is where teams either make this sustainable or drown themselves. The per-artifact loop is the default: any new screen, flow, or substantial revision goes through critique before it merges, using the standard contract. Because the agent does the inspection, the marginal cost is mostly the designer's triage time — typically minutes per artifact, not hours.

The per-sprint sweep covers the gap that per-artifact review leaves: drift. Individually reviewed changes can still accumulate into inconsistency — three slightly different empty states, two competing button hierarchies. A sprint-level pass critiques the touched surfaces together, looking specifically for consistency and state coverage. The per-release pass is reserved for the flows where mistakes are expensive — checkout, onboarding, billing, anything legal cares about — and goes deeper: every state, every breakpoint, accessibility, and copy.

The warning to give explicitly: the constraint is no longer agent capacity, it is human triage attention. A team that schedules every cadence at maximum depth will generate more findings than anyone reads, and unread findings are worse than no findings because they create the illusion of review. Start with per-artifact loops on new work plus a release pass on one critical flow, and only add cadence when triage is comfortably keeping up. Module 2 deals with triaging large finding sets in detail.

Walk the table as a narrative. The setup: a three-step purchase path where trial users hesitate on the payment step. The weak version of this review is asking the agent whether the page is clear. The strong version gives it the user job — a buyer should understand what they are paying for, what happens after payment, and how to recover from errors — plus screenshots of every state on desktop and mobile, the route files, and the design harness, and asks for findings only.

The findings split is typical of a first pass on a reasonable screen: one blocker (the error state offered no recovery path, only a generic message), three important (including the mobile payment step hiding the plan summary below the form), four polish, and one question (whether the renewal date must legally appear before the pay button — the agent flagged it rather than guessing). At the triage gate the designer accepted the blocker and two of the important findings, deferred one, rejected two polish comments as taste, and answered the legal question after checking with the product owner.

The revision pass touched only the approved findings, the re-critique recaptured the same viewports and confirmed the fixes without regressions, and the designer shipped. Two artefacts of the loop outlived the screen: the deferred finding went into the backlog with its evidence attached, and the recurring weakness around interaction states became an explicit dimension in the harness — which is the dashed feedback line from the diagram doing its job. Total designer attention across the loop was well under an hour; the inspection itself was agent time.

The exercise is deliberately on paper, because the hard part of the loop is not running the agent — it is the design thinking the agent cannot do for you. Most participants find the user job and the violation sentences hardest, and that is the point: a dimension like good hierarchy is unusable until you can say what a violation looks like — primary action competes with a secondary link, the price is below the fold on mobile, the table header disappears on scroll.

Steer people away from copying the six default dimensions wholesale. The exercise works when someone reviewing a data-dense admin table realises that trust and risk barely applies but density, scan path, and table behaviour are everything — that realisation is the skill the module is teaching. The evidence-packet step usually exposes a practical gap too: many teams discover they have no easy way to produce screenshots of error and loading states, which is worth knowing before the agent is ever involved.

If running this live, have two or three people read out their violation sentences. Weak ones are restatements of the dimension; strong ones are checkable facts. The fix-versus-judgment marking at the end is a rehearsal for the triage gate, and it sets up Module 2, where the same dimensions get applied across an entire product surface and the triage problem becomes the central one.

Recap the module by walking the loop one more time, but emphasise the two ideas that carry into the rest of the course. First, the division of labour: the agent owns inspection, comparison, and consistency checking; the designer owns dimensions, triage, judgment, and the ship call. Every later module — heuristic evaluation, visual regression, accessibility, per-PR review — is this same division applied to a different review surface. Second, the feedback line: recurring findings become named dimensions or executable checks in the harness, which is how the loop compounds instead of just repeating.

Preview Module 2 concretely. The critique loop in this module reviewed one artifact at a time. Module 2 applies the same structure to two classic methods most teams skip because of cost — heuristic evaluation and cognitive walkthroughs — run across an entire product surface. The new problems are scale problems: keeping criteria consistent across hundreds of screens and states, anchoring walkthroughs to defined user tasks rather than screens in isolation, and triaging finding sets large enough to drown a team if handled naively. The dimensions written in this module's exercise are the direct input.

If participants did the exercise, remind them to keep the page accessible: it gets used in Module 2's exercise, and the evidence-packet list becomes the baseline definition in Module 3's visual QA work.