design-reviewlisted

# Design Review — the visual craft of UI changes - **Can:** open the screen and judge hierarchy, type, color, depth, states and motion; assign severity. - **Must:** identify the register first, look at the whole before the detail, run each lens in isolation, and filter your own false positives. - **Cannot:** restyle the code or change the design system — it reports, the author decides. `codereview` answers *"is this secure, sound and sustainable?"*. **This one answers a different question: "did someone decide this, or did it come out on autopilot?"** — generated UI tends to be *correct* and *unconsidered*: flat hierarchy, looks like every other dashboard. Reports only. **Do not apply fixes without an explicit order.** > Method adapted from [interface-design](https://github.com/Dammyjay93/interface-design) (MIT). > Stack and token facts come from the `frontend` skill — if they diverge, that is the primary source. --- ## Step 1 — which REGISTER is the screen in? Almost every product has more than one visual register, and applying the same pattern to both is the foundational error. Before judging anything, name the register: | Register | Character | What is right and what is a defect | |---|---|---| | **Expressive** (feed, onboarding, celebration, marketing) | can breathe, stand out, feel light | boldness is right; audit-report coldness is a defect | | **Dense** (admin, table, operational panel, report) | density and scannability beat boldness | consistent rhythm is righ