Template for design QA

Catch layout drift, missing states, and tracking gaps before release.

Use this design QA checklist when a page, dashboard, onboarding step, or product flow is ready for implementation review. It turns handoff notes into a release decision instead of a scattered comment thread.

Start design QAUX review checklist
6 gatesSource, layout, states, assets, analytics, release QA.
18 checksConcrete review items for implementation-ready surfaces.
1 ownerA single QA owner keeps the release decision clear.
Checklist

Review the exact release surface

Design QA is finished when each discrepancy is either fixed, assigned, or explicitly accepted as an intentional deviation. Anything else becomes release risk.

Lock the source of truth

1
  • Confirm the final design file, component version, breakpoint notes, and delivery owner.
  • Mark any intentionally deferred state before engineering starts.
  • Remove stale screenshots, prototype notes, or comments that conflict with the approved spec.

Check layout and responsive rules

2
  • Verify spacing, grid behavior, and max widths for desktop, tablet, and mobile.
  • Name fixed-format elements that must not resize when labels, icons, or state changes appear.
  • Document what wraps, stacks, hides, or stays visible at each breakpoint.

Audit content and states

3
  • List empty, loading, error, success, disabled, hover, focus, and selected states.
  • Check that every visible label, CTA, price, legal note, and validation message is final.
  • Confirm long words, translated strings, and dynamic data cannot overflow the container.

Verify assets and icons

4
  • Export images at the required aspect ratio and density, not as oversized design leftovers.
  • Match icon metaphor, stroke weight, size, alignment, and selected state.
  • Confirm image crops do not hide the actual product, proof, or user decision detail.

Instrument the handoff

5
  • Attach tracking names for primary CTA, secondary CTA, form start, completion, and source click.
  • Record which events prove that the design change improved the target workflow.
  • Flag anything that cannot be measured in the first release.

Run release QA

6
  • Compare implementation screenshots against the approved design at desktop and mobile sizes.
  • Check keyboard focus, touch targets, contrast, and scroll behavior.
  • Ship only when every issue is assigned as blocker, follow-up, or intentional deviation.
Release output

Leave behind a decision log

A design QA session should create a short release log that explains what changed, what remains risky, and what needs measurement after launch.

Fix now

Visible layout, state, copy, accessibility, or tracking gaps that block release.

Ship with note

Known deviations that are acceptable for this release and owned for follow-up.

Measure next

Events, funnel checks, or session evidence needed after production traffic arrives.

FAQ

Questions before release QA

What is a design QA checklist?

A design QA checklist is the final review list used before implementation or release. It catches layout drift, missing states, asset mistakes, overflow, tracking gaps, and unresolved handoff decisions.

Who should own design QA in a small team?

One owner should run the checklist, but design, engineering, and growth each own part of the outcome. The checklist only works when every issue has an owner and a release decision.

How is this different from a UX review checklist?

UX review asks whether users understand and complete the task. Design QA asks whether the approved design was implemented accurately and safely across states, breakpoints, assets, and analytics.