Guide
Frontend design review
Your pull requests get code review. This is the review they don't get, what it checks, and how to run one.
Every pull request on your team gets a code review. Someone reads the diff, checks the logic, asks for a test. Then the PR merges, and the interface it shipped has a button built from a div, a focus outline that was removed and never replaced, and a fourth shade of gray that exists nowhere in your design system. The code was reviewed. The design wasn't.
This isn't carelessness. Design decisions live in exactly the lines code reviewers are trained to skim: a hex value, a padding number, an aria attribute, an easing curve. The reviewer confirms the function works. Nobody is asked whether the interface is good.
Why design review doesn't happen in code review
- ·Designers don't read diffs. The people with design judgment work in Figma. By the time the implementation reaches a pull request, they're on the next feature, and a
.tsxdiff isn't a surface they review anyway. - ·Code review optimizes for correctness. A reviewer approving
padding: 13pxhas no reason to know the spacing scale is 4/8/16. The value compiles. It ships. - ·The mockup isn't the merge. What ships diverges from the design in a hundred small decisions the implementer made alone: the empty state, the loading state, the error text, what happens at 320px wide. None of those were in the Figma file.
What a design review of UI code checks
A design review reads the same files a code review does — the .tsx, .vue, .svelte, and CSS that produce the rendered interface — but asks different questions. Done thoroughly, it covers eight areas:
Accessibility
Can everyone use it: semantics, keyboard paths, focus, contrast, what a screen reader announces.
Color
Whether values come from the design system or bypass it, and whether hover and focus states exist at all.
Typography
Heading hierarchy, adherence to the type scale, line height, truncation.
Spacing
Whether layout values come from a scale or are one-off numbers. Alignment, radii.
Components
Reuse of primitives, prop design, tokens leaking into inline styles.
UX
Loading states, empty states, error handling, destructive-action confirmations, forms.
Motion
Duration and easing, prefers-reduced-motion support, layout shift caused by animation.
Craft
The templated patterns generated code defaults to: stock gradients, glow shadows, magic numbers, filler copy.
What it finds in practice
Held to all eight areas at once, most codebases score lower than their teams expect. shadcn/ui scored 54/100 under this review — and it's one of the most copied component libraries in React. Not because it's bad. Because almost no UI code has ever had a design review at the pull-request level, and the findings accumulate for years.
The common ones: interactive elements that aren't reachable by keyboard, contrast that fails WCAG on secondary text, hardcoded colors sitting next to a perfectly good token file, and spacing values that are each plausible and collectively arbitrary.
How to get a design review on every PR
- ·Have a designer read UI pull requests. The highest-judgment option. It rarely survives contact with a sprint: designers review renders better than diffs, and there are always more PRs than designers.
- ·Put a design checklist in the PR template. Cheap to add. In practice it decays into a row of unread checkboxes within a month.
- ·Automate it. Rams is a design reviewer that runs as a GitHub App. It reviews the UI files in every pull request against 118 rules across the eight categories above, posts each finding as an inline comment with a one-click fix suggestion, and finishes in about a minute. No CI config. How the score is calculated is public: the methodology.
See the review your last PR didn't get.
Free on public repos. Score first, decide after.
Review my public repoFree