Visual Design Quality Review (Design Review)

Core Concepts

"AI Slop" Patterns

UI code generated by AI repeatedly produces patterns that are technically functional but look awkward to a designer's eye. Representative examples include:

• rounded-lg everywhere — buttons, inputs, cards, even tables all have the same border radius
• Inconsistent spacing — mixing p-3, p-4, p-5 throughout
• Inconsistent text colors — text-gray-500, text-gray-600, text-neutral-500 all mixed in
• Excessive shadow usage — shadow-sm through shadow-2xl mixed without reason
• Lack of information hierarchy — title and body text are nearly the same size, leaving no clear visual flow

When to Use

• When receiving requests like "review the design", "find visually awkward parts", or "polish the design"
• In the "polish" phase after development is complete
• When you want to elevate AI-generated UI code to human designer standards
• When a teammate says "why does this look weird?" but you don't know what the problem is
• When a final visual quality review is needed just before deployment

If you need a design review before implementation (planning stage), use /plan-design-review. Design Review is QA for a site that is already implemented.

Iterative Fix Loop

Design Review does not simply list problems — it repeats the cycle of discover → fix → re-take screenshot → verify.

1. Capture current state screenshots via Browse daemon
2. Create a list of visual issues (by priority)
3. Fix the most impactful issue first in source code
4. Re-take screenshot after fix, compare Before/After
5. Save each fix as an atomic commit
6. Repeat until all issues are resolved

Before/After Screenshot Comparison

By taking screenshots before and after each fix and displaying them side by side, it confirms whether the fix actually brought visual improvement. Without this process, you cannot know if a fix created new problems instead.

One-Line Summary

A repetitive QA skill that audits a live site through a designer's eye, discovers visual inconsistencies, spacing issues, information hierarchy errors, AI slop patterns, and sluggish interactions, directly fixes the source code, and performs commits — all in an iterative loop.

Getting Started

/design-review

SKILL.md file location: ~/.claude/skills/design-review/SKILL.md

To customize, copy the SKILL.md content and modify it.

Practical Example

Situation: Claude Code implemented the MVP for a "Student Club Notice Board", but feedback came in that it overall "looks somehow awkward". Use Design Review to systematically discover and fix the issues.

Step 1 — Run Design Review

> Use the design-review skill to audit the visual quality of http://localhost:3000

Step 2 — Audit Report Example

[Design Review] Audit complete — 12 issues found

Priority HIGH
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. [No information hierarchy] /notices — title (text-base) and body (text-sm) size
   difference too small, visual flow is unclear.
   Title needs emphasis with text-lg + font-semibold.

2. [Spacing inconsistency] Card internal padding mixes p-3, p-4, p-5.
   Per DESIGN.md standard, unify to md (16px = p-4).

3. [AI slop] rounded-lg applied identically to buttons/inputs/cards/badges.
   Differentiate: buttons to rounded-full, cards to rounded-xl, inputs to rounded-lg.

Priority MEDIUM
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. [Slow interaction] Hover transition at duration-300 is too slow. 150ms recommended.

5. [Shadow mixing] shadow-sm, shadow-md, shadow-lg mixed without rules.
   Unify to: card default: shadow-none, hover: shadow-md.

Priority LOW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6-12. [Color consistency] text-gray-* and text-neutral-* mixed (8 locations)

Step 3 — Atomic Fix Commits

Claude fixes issues one by one and commits each separately.

# fix 1: information hierarchy fix
# Before
<h2 className="text-base">Notice Title</h2>
# After
<h2 className="text-lg font-semibold">Notice Title</h2>
# → git commit "fix: fix notice card title information hierarchy (text-base → text-lg)"

# fix 2: unify card padding
# Before: p-3, p-4, p-5 mixed
# After: all unified to p-4
# → git commit "fix: unify notice card internal padding to p-4"

Step 4 — Before/After Verification

[Design Review] fix 1 verification — Before/After screenshot comparison
Before: title and body nearly the same size, scattered visual attention
After:  title clearly larger and bolder, naturally guides visual flow ✓

[Design Review] fix 3 verification — rounded differentiation
Before: all elements monotonously rounded-lg
After:  button (pill), card (xl), badge (full) each adjusted to their characteristics ✓

Before/After Code Comparison Example

// NoticeCard.tsx — Before Design Review
<article className="rounded-lg bg-white p-3 shadow-md hover:shadow-lg transition-all duration-300">
  <h2 className="text-base text-gray-700">Notice Title</h2>
  <p className="text-sm text-gray-500">Preview...</p>
</article>

// NoticeCard.tsx — After Design Review
<article className="
  rounded-xl                          // card uses xl
  bg-white dark:bg-neutral-800
  p-4                                 // unified md spacing
  border border-neutral-100 dark:border-neutral-700
  shadow-none hover:shadow-md         // flat by default, shadow only on hover
  transition-shadow duration-150      // fast transition (150ms)
  cursor-pointer
">
  <h2 className="text-lg font-semibold text-neutral-900 dark:text-white">
    Notice Title
  </h2>
  <p className="text-sm text-neutral-500 dark:text-neutral-400">
    Preview...
  </p>
</article>

Learning Points / Common Pitfalls

• "It works != it looks good": After implementing features, "it works" and "it's pleasant to use" are entirely different levels of quality. Design Review bridges that gap.
• Common mistake — Leaving AI slop untouched: Using UI code generated by Claude or GitHub Copilot as-is will always leave the AI slop patterns described above. Auto-generated code should always be reviewed once more with Design Review.
• Importance of atomic commits: Changing everything at once makes it impossible to track which fix brought which improvement. Following the principle of one issue = one commit makes the fix history clear.
• Next.js 15 Tip — Dark mode review: Design Review must include not only light mode but also dark mode (dark: classes) as a mandatory audit target. Even if something looks good in light mode, color contrast is often insufficient in dark mode.
• Distinction from /plan-design-review: Design Review "fixes a UI that is already complete". /plan-design-review "reviews design plans before implementation". The two skills are complementary and their combined use maximizes effectiveness.

Related Resources

• design-consultation — Establishing a design system (creating DESIGN.md)
• design-html — Design implementation (the stage before Design Review)
• browse — Screenshots and layout verification (used internally by Design Review)

---

Field	Value
Source URL	https://docs.anthropic.com/en/docs/claude-code/skills
Author/Source	Anthropic
License	Commentary MIT, original for reference only
Translation Date	2026-04-13