Blog Post

Website QA Checklist for Design Teams

Q: When should you run a website QA checklist?

Run a website QA checklist after the feature is deployed to staging and before the pull request is merged to production. This timing gives you enough context to compare against the design spec and enough time to fix issues before they reach users. Running QA after the release branch is cut is too late.

Q: Who should run the website QA checklist?

The designer who owns the spec is the ideal person to run a visual QA checklist, since they know what the implementation should look like. For teams without a dedicated QA role, assign design QA ownership explicitly to prevent the checklist from being skipped. QA engineers with access to the Figma file can also run it.

Q: What is the difference between functional QA and visual QA?

Functional QA checks whether features work correctly — form submissions, navigation, API calls, error handling. Visual QA checks whether the implementation matches the design spec — correct spacing, typography, colors, and interactive states. A page can pass every functional test while still having wrong font sizes, inconsistent spacing, and missing hover states.

A 15-point website QA checklist covering layout, typography, color, interactive states, responsive behavior, and accessibility. Built for the gap between functional testing and visual quality — so design bugs get caught before users see them.

Why Most QA Checklists Miss Visual Bugs

Functional QA has decades of tooling: unit tests, Cypress, Playwright. Visual QA has almost none. Teams ship features that work but do not look right because there is no structured process, no side-by-side comparison against the design spec, and no clear ownership of visual quality.

The 15-Point Website QA Checklist

Layout & Spacing (Checks 1-3)

Margins and padding match the design spec — especially vertical rhythm between sections
Content alignment is consistent — headings, body text, and images share the same grid
No content overflow or clipping at any viewport width

Typography (Checks 4-6)

Font families and weights match the spec — check fallback rendering
Font sizes follow the design system type scale from h1 through labels
Line-height and letter-spacing are correct — Figma and CSS calculate these differently

Color & Visual Consistency (Checks 7-9)

Brand colors match design tokens — inspect hover and focus states, not just defaults
Backgrounds, borders, and shadows are consistent across similar components
Images and icons render correctly — check SVG fills, image aspect ratios, and alt text

Interactive States (Checks 10-11)

Hover, focus, active, and disabled states all exist and match the spec
Form states show correct visual feedback — error, success, empty, and loading

Responsive Behavior (Checks 12-13)

Layout matches the design at each breakpoint — desktop, tablet, and mobile
No horizontal scroll at any viewport width from 320px to 1920px

Accessibility (Checks 14-15)

Color contrast meets WCAG AA — 4.5:1 for body text, 3:1 for large text
All interactive elements are keyboard-accessible with visible focus indicators

How to Run This Checklist

Run the checklist after a feature is deployed to staging and before merging to production. The designer who owns the spec should compare the staging URL against the Figma file, working through each category. For every failed check, file an issue with a screenshot, expected value from the design, and actual value from the browser.

Common Mistakes That Break Website QA

Reviewing without the design spec open — comparing from memory misses spacing and color differences
Only checking at one viewport — pages that look correct at 1440px can break at 768px
Skipping interactive states — hover, focus, and disabled states account for many visual bugs
Filing vague issues — include what is wrong, where, what it should be, and a screenshot
Running QA too late — run the checklist while the feature is still in an open pull request

Automating Your Website QA Checklist

OverlayQA handles multiple checklist categories in a single workflow: capture a screenshot of your staging page, compare it against the Figma design, and export any issues with CSS values, element metadata, and screenshots directly to Jira or Linear. The accessibility audit workflow runs automated WCAG checks on the same page.

Frequently Asked Questions

What should a website QA checklist include?

A comprehensive website QA checklist should cover six categories: layout and spacing, typography, color and visual consistency, interactive states, responsive behavior, and accessibility. This goes beyond functional testing to catch visual bugs that break the user experience.

When should you run a website QA checklist?

Run it after the feature is deployed to staging and before the pull request is merged to production. This gives enough context to compare against the design spec and enough time to fix issues before they reach users.

Who should run the website QA checklist?

The designer who owns the spec is ideal, since they know what the implementation should look like. For teams without dedicated QA, assign design QA ownership explicitly to prevent the checklist from being skipped.

What is the difference between functional QA and visual QA?

Functional QA checks whether features work correctly. Visual QA checks whether the implementation matches the design spec — correct spacing, typography, colors, and interactive states. A page can pass every functional test while still having visual bugs.