Design QA Checklist: Review a UI Before Release

Use this design QA checklist to compare an implemented interface with its intended design and behavior. Review the actual release preview, exercise the relevant states, and record every unresolved finding with enough context for another person to reproduce it.

The checklist is organized in the order we recommend using it: establish the reference, check the layout, inspect components and content, exercise responsive behavior, and make a release decision. Mark each item pass, fail, or not applicable. A missing reference is an unresolved question, not an automatic pass.

Prepare the review

Complete this short record before inspecting the page:

Use a versioned reference where possible. If a designer changes the mockup midway through the review, preserve which version informed each finding. When no mockup exists, identify the existing component or written acceptance criterion you will use.

Choose test data that can expose layout limits. An illustrative customer list might include no customers, one customer, many customers, a long company name, and an unavailable logo. These are suggested test cases, not findings from a tested application.

1. Layout and hierarchy

• The page uses the intended navigation and content container.
• The primary action is visible and reachable in each reviewed state.
• Sections follow the reference order and alignment.
• Spacing matches the approved values or component rules.
• No text, image, or control unexpectedly overlaps another element.
• Sticky and fixed elements leave the relevant content and controls accessible.
• Scrolling occurs in the intended container.
• Overlays appear above the content they are meant to cover.

Inspect structure before polishing small details. If a content container has the wrong width, resolve that question before evaluating line wrapping and section alignment inside it. Otherwise, several apparent defects may describe the same underlying issue.

2. Typography, color, and assets

• The intended font has loaded before the review screenshot is captured.
• Heading levels have the intended visual hierarchy.
• Body text, labels, and supporting text use the approved styles.
• Text remains readable in every supported theme under review.
• Meaning does not depend on color alone.
• Icons use the intended size, alignment, and visual family.
• Images preserve their intended crop and proportions.
• Missing or failed assets have an intentional fallback.

Measure a disputed value or point to its reference. “The caption uses the disabled text token” gives a developer something to inspect. “The caption feels off” does not establish the expected result.

Treat contrast as a check with a defined requirement rather than a visual guess. W3C's initial accessibility review includes contrast, keyboard access, form labels, and other useful checks, while explicitly warning that this first pass is not a comprehensive accessibility evaluation. W3C easy checks

3. Components and interaction states

• Repeated controls use the intended shared component and variant.
• Hover, focus, active, disabled, and loading appearances are intentional where applicable.
• Focus remains visible while moving through interactive controls.
• Icon-only controls expose an understandable name.
• Form labels remain understandable after a value is entered.
• Validation messages identify the relevant field and the next action.
• A pending operation communicates progress and handles repeated activation intentionally.
• Opening and closing an overlay produces the expected focus behavior.

Inspect states directly. A screenshot of a closed dropdown cannot verify its open menu. A successful form submission cannot establish the appearance of its validation error.

For pull requests with React-specific implementation concerns, use the separate React UI code review checklist alongside this release review.

4. Content and system states

• Loading content preserves an understandable page structure.
• Empty states explain what the user can do next.
• Error states identify the failed operation and available recovery.
• Permission-limited states explain the available action.
• Long titles and labels have an intentional wrapping or truncation behavior.
• Large values and dense content do not hide controls.
• Dates, units, and formatted values are appropriate for the test scenario.
• Placeholder content has been removed from the release surface.

Use a small state matrix to make coverage visible:

These are illustrative conditions. Replace them with requirements for your feature before assigning a pass or fail.

5. Responsive behavior

• The layout works at the selected narrow, medium, and wide viewports.
• Changes around each relevant breakpoint behave as intended.
• Long content does not create unexpected page-level horizontal scrolling.
• Navigation remains usable when its layout changes.
• Dialog content and actions remain reachable on shorter screens.
• Text enlargement preserves access to content and controls.
• Theme and content changes have been checked at the risky widths.

For reflow, WCAG's reference for vertically scrolling content is a width equivalent to 320 CSS pixels, subject to exceptions for content that requires a two-dimensional layout. This is one accessibility criterion, not a complete device-testing strategy. W3C reflow guidance

Use the responsive design testing checklist to build the full viewport and state matrix.

6. Findings and release decision

• Each finding identifies the revision, route, state, and viewport.
• Expected behavior is tied to a reference or acceptance criterion.
• Visual evidence shows enough surrounding context to locate the issue.
• Every confirmed issue has an owner and a release decision.
• Fixed issues were checked using the original reproduction.
• Unreviewed areas and setup failures remain visible in the review record.

Use the UI bug report template for failures. For intentional deviations, record who accepted them and why.

Design Bug Bot can contribute design findings and proposed code changes during pull-request review. Keep the checklist as the record of what your team actually verified.