Design QA Checklist: 10 Categories and 60 Checks for Every Release

How to Use This Checklist

• Run it on staging, not in Figma: the checklist compares the build to the design, so open both side by side.
• Run it against the approved design: the frame the team signed off on, not the latest exploration.
• Run it before every release: a full pass takes 15 to 30 minutes for a typical page; a focused pass on changed components takes 5.
• Check at three widths: 375px, 768px and 1280px, because half the categories behave differently at each.
• Record every miss as an issue: with the URL, viewport, element and the expected value, so a developer can fix it without asking.

1. Typography

• Font family: matches the design system for every text style, including fallbacks that load before the web font.
• Font weight: 400, 500, 600 or 700 as specified; no faux bold from a missing weight.
• Font size: matches the type scale for each text style (heading, body, label, caption).
• Line height: matches the spec and stays consistent across the same style.
• Letter spacing: matches where the spec defines it (usually headings and uppercase labels).
• Text color: uses the text color token, not a hard-coded value.
• Truncation and overflow: long strings wrap or truncate the way the design shows, with no clipped descenders.

2. Color

• Background colors: match the design tokens exactly, not a near match.
• Text colors: match the spec in every state (default, hover, disabled, error).
• Border colors: match the tokens on inputs, cards and dividers.
• No hard-coded hex values: colors reference tokens so a theme change propagates.
• Contrast: at least 4.5:1 for normal text and 3:1 for large text, per WCAG 2.2 success criterion 1.4.3.
• Dark mode and themes: every variant renders correctly if the product ships them.

3. Spacing and Layout

• Padding: matches the spec on all four sides of each component.
• Margins: between elements match the spacing scale, with special attention to cards, form fields and section boundaries.
• Gap: values in flex and grid layouts match the spec.
• Widths and heights: fixed-size elements match; fluid elements match at each breakpoint.
• No overflow: content stays inside its container at every width.
• Section rhythm: vertical spacing between sections follows the scale, not an eyeballed value.

4. Alignment

• Grid alignment: elements sit on the layout grid the design uses.
• Vertical alignment: adjacent elements (icon and label, avatar and name) share a baseline or center line.
• Horizontal centering: centered blocks are centered in their container, not offset by a scrollbar or padding.
• Icon-to-text baseline: inline icons align with the text they sit next to.
• Equal gutters: left and right page gutters match at each breakpoint.

5. Component States

• Default: matches the spec.
• Hover: implemented and matches the spec on every interactive element.
• Focus: visible for keyboard users and matches the design, with no focus ring removed.
• Active or pressed: implemented where the design shows one.
• Disabled: matches visually and does not respond to input.
• Loading: implemented where specified, including skeletons and spinners.
• Error: displays with the designed color, icon and message position.
• Empty: designed and implemented, not a blank area.

6. Responsive Behavior

• Desktop: layout is correct at 1280px and wider.
• Tablet: layout is correct at 768px.
• Mobile: layout is correct at 375px.
• Readable text: no text below the minimum size at any breakpoint, and no clipped headings.
• Target size: interactive targets are at least 24 by 24 CSS pixels, per WCAG 2.2 success criterion 2.5.8, or 44 by 44 if your design system sets the stricter rule.
• Images: scale correctly and keep their aspect ratio.
• No horizontal scroll: at any viewport width.

7. Icons and Images

• Icon size: matches the spec (16, 20 or 24px as designed).
• Icon color: uses the token, including in hover and disabled states.
• Crop and aspect ratio: images match the designed crop.
• Alt text: present and descriptive on content images; empty on decorative ones.
• Resolution: no blurry images on 2x displays.

8. Borders and Shadows

• Border radius: matches the radius token for each component.
• Border width: matches the spec (1px vs 1.5px shows at 2x).
• Shadow values: match the elevation token, including color and blur.
• Dividers: consistent color and thickness across the page.
• Focus ring offset: matches the design, so the ring does not overlap the border.

9. Animation and Transitions

• Duration and easing: match the interaction spec.
• State transitions: hover, focus and open/close changes animate where the design says so, and do not where it says not to.
• Loading animations: implemented where designed.
• No jank: no layout shift or flicker on state changes.
• Reduced motion: animations respect the prefers-reduced-motion setting.

10. Content Accuracy

• Copy: matches the approved content, including capitalization and punctuation.
• Labels and placeholders: match the design for every field and button.
• No placeholder text: no lorem ipsum, no "TBD", no sample names in production.
• Numbers and dates: formatted the way the design shows (currency, separators, time zones).
• Empty-state copy: matches the design, not a default string from the framework.
• Links: link text and destinations match the spec.

A Design QA Checklist for Startup Teams

A startup without a QA team does not need all 60 checks on every release. It needs a 15-minute pass that catches the misses users notice first. Run these fifteen, in this order, on the pages that changed:

• Component states (4): hover, focus, disabled and error on every button and input that changed.
• Responsive (3): 375px, 768px and 1280px, looking for overflow, clipped text and horizontal scroll.
• Color (3): backgrounds and text against the tokens, and contrast on any new text color.
• Spacing (2): padding inside the changed components and margins between them.
• Content (3): copy matches, no placeholder text, empty states say something.

Give the pass one owner. On most small teams that is the designer who made the frame, because they know what the design is supposed to look like, and the developer who built it, because they can fix it in the same sitting. The tools, prices and workflow that fit a team of this size are in design QA software for startups.

What You Can Automate

Half the checklist is a judgment call that needs a human looking at the design. The other half is a comparison a scanner can run on the live page. OverlayQA runs the second half from the Workflows tab in the Chrome extension, or from Team Review in the dashboard on any public URL:

Whatever the scan finds becomes an issue with the selector, computed CSS, screenshot, URL, viewport and browser attached, which is the same record the manual checks should produce. What stays manual: alignment judgment, animation feel, crop decisions and whether the copy reads right.

Checklist Summary

Frequently Asked Questions

What is a design QA checklist?

A design QA checklist is the list of visual checks a team runs on a staging build against the approved design before release. It covers typography, color, spacing, alignment, component states, responsive behavior, icons, borders, animation and content, and turns design review from an ad hoc Slack thread into a repeatable pass.

What should a design QA checklist include?

Ten categories: typography, color, spacing and layout, alignment, component states (default, hover, focus, active, disabled, loading, error, empty), responsive behavior at 375, 768 and 1280 pixels, icons and images, borders and shadows, animation and transitions, and content accuracy. Each item should name the expected value so a miss can be filed as an issue.

How long should a design QA pass take?

A full pass over one page with all 60 checks takes 15 to 30 minutes at three breakpoints. A focused pass on the components that changed in a release takes about five. Running the token, contrast and consistency checks with a scanner removes most of the element-by-element inspection time.

Who owns the design QA checklist?

Usually the designer who made the frame runs it, because they know what the build is supposed to look like, with the developer who built the page fixing misses in the same sitting. On teams with QA engineers, QA runs the pass as part of regression testing and the designer reviews the findings.