Design Critique

Design Critique — WrongStack

Overview

A design critique that says "it looks a bit generic, maybe add more spacing" is worthless. This skill produces a scored, evidenced, ranked audit: each finding names the file and line, the rule it breaks, and the concrete replacement — the same standard a code review is held to.

Two independent failure classes, always reported separately:

• Adherence — does the code use the kit's tokens? Machine-checkable.
• Craft — does the result look designed? Needs judgment, guided by a rubric.

A UI at 100% adherence with a failing craft score is the common case, and saying so plainly is the whole value of this skill.

Workflow

1. Establish ground truth   → active kit + brief
2. Machine pass             → design {action:"verify"}
3. Craft pass               → rubric, six axes, evidence per finding
4. Score + rank             → what to fix first, what to ignore
5. Report                   → findings, not adjectives

1 — Ground truth

design {action:"list"}        # what is pinned

Read .design/brief.md with read if it exists — a critique that contradicts a decision the team already made is noise, unless the decision itself is the problem (say so explicitly, once). Read .design/rules.md for project overrides, and grep the UI source for token usage to ground the adherence findings.

Adherence means different things in three cases. Establish which one you are in before reporting any percentage.

The middle case is the common one in a mature codebase, and mis-reporting it as the third is how a critique loses the room: the team already built a system, and being told they have none is simply wrong. Say instead which axis of their system is missing — a kit carries radius, spacing, type, motion and elevation, and a hand-rolled system is usually missing one of them.

2 — Machine pass

design {action:"verify"}

Check what the machine pass could actually see. It reads utility classes and CSS; a native-stack screen (react-native, flutter, swiftui, compose) has neither, so it returns a clean result on a file it never checked. If verify reports files with no class/utility signal, say so in the report — Tokens: not machine-checkable (native stack) — and carry the entire adherence judgement by reading the theme constants and spacing scale yourself. Never let a vacuous clean pass stand in as evidence.

Run design with {action:"verify"} and report the breakdown by axis. Treat composition findings as craft evidence, not token drift — they are patterns that are token-clean and still generic.

3 — Craft pass

Inspect a rendered screen or supplied image before making visual claims. Record the route/artifact, viewport, theme and state. Source alone supports implementation findings, not claims that a screen looks balanced, passes contrast or behaves correctly. Mark missing evidence unverified, not n/a; omit the overall score when an applicable axis lacks evidence. Do not invent screenshot observations.

Judge against the primary task and brief. Repeated rows, equal cards, symmetry, a single font or a gradient can be appropriate. A scanner match is a question to investigate, not a verdict; confirm the visible problem before requesting a change. Check whether a logo swap leaves an unrelated but equally plausible product, and whether the interface uses the actual domain's content and workflow.

Classify the surface first. Two axes are scored differently depending on it, and some are not scorable at all:

Kiosk is not a small page. Its constraints are physical, and a rubric that only asks design questions will hand a kiosk a flattering score for the wrong reasons. Ask these as well, and treat a failure as blocking rather than craft:

• Readable at distance. Can the primary state and the total/answer be read from two metres, in glare? If the answer depends on leaning in, it fails.
• One cold finger. Targets well above the 44px floor (64px+), spaced so a mis-tap cannot select the neighbour. No hover, no drag, no long-press, no dropdown.
• Recoverable. Every destructive or committing step has a visible way back. A stranded user cannot refresh, log in again, or email support.
• No session. Nothing personal persists on screen, and the screen returns to its start state on its own after inactivity.
• Standing, not sitting. Content sits in the upper-middle band; nothing essential lives at the very bottom of a tall panel.

Score the six craft axes as usual, then report the physical checks as a separate pass/fail list. A kiosk that scores 4/5 on craft and fails "readable at distance" is a failing screen.

Never score an axis that does not apply to the surface. Write n/a (app screen) and move on — a fabricated 3/5 drags the overall score, which is the lowest axis, and makes the whole report meaningless.

Score each remaining axis 0–5 against the rubric, loaded with the skill tool:

skill({ name: "design-critique", resource: "references/rubric.md" })

Never score from feel — each score cites at least one concrete observation.

Run the three cheap tests and report the result of each:

• Greyscale — remove color. Hierarchy intact?
• Squint — blur it. Is there one focal point per screenful?
• Swap — replace the product name throughout. Does the copy still make sense for a different product? If yes, the copy is filler.