Website Design QA Checklist: Compare the Build with the Approved Mockup

Website design QA checks whether the built website implements the agreed visual design and behavior. It happens after there is something functioning to inspect. The approved mockup is the reference, but the browser is where you evaluate the implementation.

Design QA is one part of launch preparation. It does not replace security testing, content approval, accessibility evaluation or testing the business integrations. Keeping those responsibilities distinct helps the team avoid treating an attractive screenshot as evidence that the whole site is ready.

Establish the correct reference

Find the approved revision and confirm which pages and device layouts it covers. If the public preview has been replaced since approval, use the appropriate retained revision or decision record. Comparing the build with an outdated mockup can create unnecessary changes.

Match the browser viewport to the reference where practical. A narrower window can change wrapping and column layout, making a valid responsive behavior look like a mistake. Record the viewport and browser with each issue so another person can reproduce the context.

Use realistic content and a known state. A logged-in account, empty cart or long service name may produce a different screen from the design's example. Establish what state you are testing before deciding that the layout is wrong.

Check page structure before small styling details

Review section order, content grouping and the relationship between the main offer and its call to action. Confirm that required sections are present and that important qualifications have not been dropped during implementation.

Check containers, columns and alignment. Look for a section that unexpectedly spans the entire viewport, an inconsistent content edge or a layout that overflows horizontally. Diagnose the cause before adding a one-off adjustment that might break a neighboring width.

Prioritize differences that affect comprehension or task completion. A missing service exclusion matters more than a tiny decorative spacing difference. This does not make polish unimportant; it gives the team a sensible order for resolving issues.

Review typography and real content

Confirm that the intended fonts load and that heading levels look distinct. Check long headings, navigation labels and buttons for wrapping or truncation. A font fallback can affect spacing across an entire page, so verify the font before adjusting each component separately.

Read the implemented text, including links, captions and small labels. Look for leftover placeholders and accidental changes from the approved content. Use the web copy checklist when an issue concerns meaning or factual accuracy rather than styling.

Inspect spacing around headings, lists and images. Content added through an editor can behave differently from a developer's initial sample. Test the actual content structure instead of only the idealized demonstration page.

Inspect images and layout changes

Check whether image crops preserve the subject and whether the file is appropriate for the displayed size. A sharp source can still look wrong if the implementation stretches it or uses an unintended crop. Verify aspect ratio before requesting a new export.

Review the mobile and intermediate layouts, not only the desktop width. Confirm that content order, navigation and the primary action still make sense. A fixed-width element may look correct at one screen size and create horizontal scrolling at another.

Use the responsive presentation guide to distinguish the intended device layouts from simple image scaling. The build also needs testing between the supplied reference widths.

Include the states a screenshot cannot prove

Open menus, submit invalid forms, inspect success messages and check empty states. Confirm that interactive elements have understandable hover and focus behavior where relevant. Check loading states when a page depends on a network request.

Use a keyboard to move through the page and observe whether focus remains visible and navigation makes sense. web.dev's manual accessibility guidance describes manual testing techniques that complement automated checks. A design QA pass is not a complete accessibility assessment.

Record functional failures separately from purely visual differences when assigning work. A correctly styled button that does not perform its action needs more than a spacing correction. The issue report should make that distinction clear to the person fixing it.

Write a reproducible QA issue

Include the page URL, viewport, browser, relevant state and steps to reproduce. Attach a screenshot where it helps explain the difference. State the expected result using the approved design or agreed behavior, then describe the actual result.

For example: “Service page, 390px viewport. Open the enquiry section. Expected: the submit button remains inside the form container. Actual: the button extends beyond the right edge, creating horizontal scroll. Reference: approved mobile revision 4.”

Assign an owner and priority based on impact. Do not mark every visual discrepancy as a launch blocker. Agree which issues prevent release, which need correction soon and which are acceptable differences or later improvements.

Retest the change in context

After a fix, repeat the original steps and inspect nearby widths or components that share the changed styling. A global rule can solve one page while changing another. Record what was checked rather than closing the issue solely because a commit exists.

Keep Swelik or your chosen design reference available during this process, but test the functioning website for behavior. Complete the broader handover checklist before transferring responsibility to the client.

Frequently asked questions

Must the website match every pixel of the mockup?

The team should agree on the intended design and acceptable differences. Browser rendering, content and responsive behavior can affect exact pixels. Focus on deliberate, explainable implementation rather than treating every small rendering variation as a defect.

Who should perform design QA?

Someone who understands the approved design should participate, alongside the developer and relevant content owners. Separate responsibilities help identify whether a concern is a design difference, a content error or a functional failure.

Can I finish design QA using screenshots alone?

Screenshots help document visual differences, but they cannot prove interaction behavior. Inspect the working site as well as the reference images.