When should the design review happen in the development process?

The design review has three touchpoints: before development (spec walkthrough), during development (developer self-check), and after implementation reaches staging (formal structured review). The formal review should happen before the pull request is merged, not after deploy. Catching issues on staging is 4 to 5 times cheaper than catching them in production.

Blog Post

The Design Review Process That Actually Catches UI Bugs

Q: How do you do a design review?

Start with a pre-development spec walkthrough where the designer explains responsive behavior, states, and edge cases. During implementation, the developer self-checks against the design file. After the feature reaches staging, a reviewer works through a structured checklist covering layout, typography, color, responsiveness, states, and accessibility. Every discrepancy becomes a trackable issue with a screenshot and CSS context.

Q: What should a design review checklist include?

A design review checklist should cover seven categories: layout and spacing (margins, padding, alignment), typography (font family, size, weight, line-height), color (backgrounds, text, borders, states), responsive behavior (test at 375px, 768px, 1024px, 1440px), interactive states (hover, focus, disabled, loading, error, empty), accessibility (contrast, headings, alt text, focus indicators), and content (real data, truncation, long strings, empty states).

Q: Who should be responsible for design review?

The most effective model is developer self-check with designer spot-check. The developer runs the checklist first. The designer reviews flagged issues and does a final pass on high-visibility features. This distributes ownership, prevents bottlenecks, and scales across multiple squads.

Q: How do you measure design review effectiveness?

Track two metrics: the number of visual bugs reported after sprint close (these are bugs the review missed), and the number of revision cycles per feature. Both should trend down over 3 to 4 sprints. If they plateau, review your checklist coverage and the timing of your reviews.

Updated May 13, 2026

Quick answer: A design review process is a structured workflow where designers, developers, and QA reviewers systematically verify that a built UI matches its design specifications. It covers spacing, typography, color, responsiveness, accessibility, and interaction states.

"It looks fine to me" is the most expensive sentence in product development. It means nobody checked. No one compared the live build against the Figma file. No one tested the hover states. No one resized the browser below 768px. The result: visual bugs ship to production, and the team spends the next sprint filing tickets for issues a 15-minute review would have caught.

Why Most Design Reviews Fail

Reviews Happen Too Late

The most common failure: the design review happens after the code is written, styled, and committed. Feedback feels like rework, not refinement. Moving the review earlier changes the dynamic entirely.

Reviews Happen Informally

A designer glances at the staging URL. "Looks good." No checklist. No comparison against the spec. No responsive testing. Informal reviews create the illusion of quality assurance without the substance.

Nobody Owns the Review

Designers assume developers checked. Developers assume designers approved. QA engineers test functionality, not visual fidelity. Explicit ownership at the story level is the prerequisite for a working design review process.

The Design Review Process, Step by Step

A working design review workflow has four phases, each with a clear owner, defined output, and time limit.

Phase 1: Pre-Development Spec Review

Before development, the designer walks through the spec. The developer asks about responsive breakpoints, hover states, loading states, and edge cases. Five minutes prevents two-hour rework cycles.

Phase 2: In-Progress Self-Check

During implementation, the developer compares their work against the design file at natural breakpoints: after building layout, typography, and interaction states.

Phase 3: Structured Design Review

The formal review happens on staging. The reviewer works through a checklist, comparing live implementation against the spec. Every discrepancy is logged as a trackable issue with screenshot, CSS values, element selector, and viewport size. Issues export to Jira, Linear, or Notion.

Phase 4: Verification and Close

After fixes, the reviewer verifies each issue. The story closes only when all visual issues are resolved or explicitly accepted as trade-offs.

What to Check: The Design Review Checklist

A design review checklist turns "does this look right?" into objective verification. Categories: layout and spacing, typography, color, responsive behavior (375px, 768px, 1024px, 1440px), interactive states, accessibility, and content. Total time: approximately 15 minutes per feature. For the full checklist, see the website QA checklist for design teams.

Who Owns the Design Review

Designer-led review: The designer who created the spec reviews implementation. Risk: designer becomes a bottleneck.
Developer self-check with designer spot-check: Developer runs checklist first. Designer reviews flagged issues. Scales better.
QA engineer with visual training: QA engineer runs the checklist. Best for teams with dedicated QA function.
Cross-functional rotation: Team members take turns reviewing. Builds design awareness across the team.

Design Review Before Development vs. After

Design review before development critiques the design itself. Design review after implementation (this guide's focus) verifies the built UI matches the approved design. Both are necessary but require different skills, timing, and checklists.

How Visual Bugs Compound Across a Codebase

One 4px padding error in a card component affects 50 cards across 12 pages. Code Climate research found teams spend an average of 26% of development time on avoidable rework, costing medium-sized companies upwards of $4.7 million annually. Visual rework follows the same pattern. NIST research (2002) showed defects caught after release cost 4 to 5 times more to fix. McKinsey's analysis of 300 companies (2018) found top-quartile design performers grew revenue 32 percentage points faster than peers.

AI-Assisted Design Review: What It Changes

Human reviewers excel at subjective judgment. AI handles mechanical verification: comparing computed CSS values against design tokens, flagging accessibility violations, and identifying responsive breakpoint issues. The combination produces a more thorough design review in less time. OverlayQA combines Visual Comparison, AI Design Review, and Accessibility Audit into a single Chrome extension workflow.

How to Structure Design Reviews in Agile Sprints

Design reviews fit into existing sprint ceremonies: planning (review spec, assign reviewer), standup (surface visual QA blockers), sprint review (show spec alongside implementation), and retrospective (track visual bugs found after close). For more, see how to add design QA to your sprint.

Common Design Review Workflow Mistakes

Reviewing everything at the end of the sprint instead of per story.
Using screenshots and Slack threads instead of structured, exportable feedback.
Making the designer the sole gatekeeper, creating bottlenecks.
Checking every pixel on every screen instead of focusing on shared components and high-traffic pages.
Skipping responsive checks. Responsive bugs are the most common visual defects.
Not documenting acceptable tolerances for spacing and color.

Frequently Asked Questions About Design Reviews

How do you do a design review?

Start with a pre-development spec walkthrough, self-check during implementation, then a formal structured review on staging using a checklist covering layout, typography, color, responsiveness, states, and accessibility.

What should a design review checklist include?

Seven categories: layout/spacing, typography, color, responsive behavior, interactive states, accessibility, and content.

When should the design review happen?

Three touchpoints: before development (spec walkthrough), during implementation (self-check), and after staging (formal review before PR merge).

Who should be responsible for design review?

Developer self-check with designer spot-check is the most effective model. See who should own design QA.

How do you measure design review effectiveness?

Track visual bugs reported after sprint close and revision cycles per feature. Both should trend down over 3 to 4 sprints.

Related Resources

How to Add Design QA to Your Sprint Without Slowing Down — Embed visual quality checks in your sprint definition of done.
What Is Design QA? — Complete guide to design quality assurance for product teams.
Design QA Fundamentals — Core concepts and workflows for visual quality assurance.
Who Should Own Design QA? — How to assign design QA ownership across roles.
The Visual QA Feedback Loop — Build a feedback loop that closes the gap between design and implementation.