Design QA Checklist: Review a Build Before Sign-Off

Design QA is the review of a built website against its approved design, done before sign-off. You put the design and the live build side by side and check spacing, type, colour, states, responsive behaviour, accessibility basics, speed and content. Every difference goes on a list with a severity. You sign off when nothing important is left open. The checklist below is one you can copy and run on a small site.

It is for business owners and project leads who receive a finished site and have to say yes or no. It also works for designers and developers who want a shared standard for "done". Reviewing the design before the build is a different job: for that, read how to hand designs to developers.

Key takeaways

• Run design QA after the build is complete and content is in, and before you sign off. Not after launch.
• Review against the design file and the written styles, not against memory or taste.
• Check in this order: layout and spacing, type, colour, images, content, states, responsive, accessibility, speed.
• Log each issue with a screenshot, the screen size, expected versus actual, and a severity. Fix blockers first.
• Sign-off means the blockers and majors are closed, and the minors are either closed or accepted in writing.

What is design QA and when do you run it?

Design QA compares what was built with what was designed, and it happens once the build exists and before the client approves it. It is not the same as testing that the code works. A contact form can send perfectly and still sit 24 pixels too close to the footer, use the wrong font weight and have no visible focus state.

Run it at two moments. First, a quick check of each section as it is built: if the spacing scale is wrong on the first page, you fix it once instead of on every page. Second, a full pass on the finished site, with real content, before sign-off. A check after launch is a repair, not a review.

What do you need before you start?

Gather four things, so that the review compares the build with a reference and not with opinions.

• The approved design file, with the page and screen-size versions you agreed. If the design has only a desktop view, say so now: mobile is then the developer's interpretation and needs your eyes.
• The styles written down: font sizes, colours, spacing steps, button styles. If they live only in the design file, use its inspect panel to read exact values. A written set of tokens is the best source of truth, which is the point of a design system.
• Final content: real text, images and links. Lorem ipsum hides line-break and length problems.
• A device list: one recent phone, a laptop, and the browsers your visitors use. Chrome, Safari and Firefox cover most cases. Test on a real phone, not only a narrow desktop window.

Open the design and the build next to each other at the same width. Do not flick between tabs and trust your memory.

The checklist

Copy this into a document and tick it page by page.

Layout and spacing

• Page width, margins and column grid match the design at desktop width
• Space between sections is the same as in the design, and consistent across pages
• Space between a heading, its text and its button follows the same steps everywhere
• Elements that should line up (left edges, card tops, button baselines) do line up

Typography

• Font family and weight match for headings, body, buttons and labels
• Sizes and line heights match the design for each heading level and for body text
• Line length is comfortable: roughly 45 to 80 characters in body copy
• Headings wrap sensibly, with no single word alone on the last line where the design avoids it

Colour and contrast

• Background, text, button and border colours match the styles, not "close enough"
• Normal text has a contrast ratio of at least 4.5:1 against its background
• Large text has at least 3:1
• Text over images stays readable on every image that can appear there

The 4.5:1 and 3:1 figures are the level AA contrast requirements in WCAG 2.2. Use a contrast checker on any colour pair you doubt.

Images and icons

• Images are sharp at their displayed size, including on a high-density phone screen
• Crops keep the subject in view at every screen size
• Icons share one size, stroke weight and style
• The logo is the correct version, with room around it, and links home
• Every meaningful image has a short, accurate alt text; decorative images have an empty one

Copy and links

• No placeholder text, no typos, no old brand names or dates
• Every link goes where it says, and external links open as designed
• Phone numbers and email addresses are clickable and correct
• Page titles and descriptions are set for each page
• Headings follow a sensible order, with one main heading per page

What states and interactions should you check?

A design file shows each element in one state. A real site has several, and this is where builds most often drift from the design. Check each of these on every interactive element:

For forms, also submit them wrong on purpose: an empty form, an invalid email, a very long name, and a message with accents or emoji.

How do you check responsive layouts and browsers?

Resize the browser slowly from wide to narrow and watch for the moment something breaks, not only at the three sizes in the design. The breakage between breakpoints is where most layout bugs live.

• Check at roughly 1440, 1024, 768 and 390 pixels wide, and every width in between by dragging
• The menu works on mobile, opens and closes, and does not trap the page
• No horizontal scrolling on any page
• Long words, long names and long headlines do not break the layout. Try German or Italian text if the site is multilingual: it is often longer than English.
• Text zoomed to 200 percent is still readable and usable
• Buttons and links are easy to tap with a thumb, with space between them
• Chrome, Safari and Firefox look the same. Safari on iPhone is the one that most often differs.
• Forms, video and animation work on a real phone, on mobile data, not only on office Wi-Fi

What accessibility basics belong in a design review?

A full accessibility audit is a separate job. A design review should still catch the visible basics.

• Everything works with the keyboard alone, and focus is always visible
• Text contrast passes, as above
• Tap and click targets are large enough. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels at level AA, with exceptions for well-spaced targets. Aim bigger on mobile.
• Links say where they go. "Read more" repeated six times does not.
• Form fields have visible labels, not only placeholder text that disappears
• Meaning is not carried by colour alone: errors have text or an icon too

How do you check speed?

Speed is part of how a design feels, so check it at review. Google's Core Web Vitals give three targets, measured at the 75th percentile of real page loads: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less.

Do this:

• Run each key page through PageSpeed Insights or Lighthouse on mobile and note any red scores
• Watch the page load on a phone: does the main image appear quickly, and does anything jump while loading?
• Check that images are compressed and not larger than the space they fill

A new site has no real-visitor data yet, so lab tests are a guide, not a verdict. Check the field data again a few weeks after launch.

How do you log findings so developers can fix them?

A good issue can be fixed without a call. Use one ticket or one row per issue, with these parts:

Use three severities and agree on them before you start:

• Blocker: a visitor cannot complete something, or the page is broken or unreadable. Fix before launch.
• Major: clearly different from the design or hard to use, on a main page. Fix before sign-off.
• Minor: small difference most visitors would not notice. Fix if cheap, otherwise accept in writing and schedule.

Be specific with numbers: "heading is 32 px, design says 40 px" can be fixed in a minute, while "heading looks small" starts a conversation.

Who signs off, and what does done mean?

The person who approved the design signs off the build. On a client project that is the client, with the designer's review done first so that the client is not finding spacing bugs. The developer does not sign off their own work.

Write down what done means before the review starts. A workable definition:

1. All blockers and majors are fixed and re-checked by the reviewer, not only marked fixed by the developer.
2. Remaining minors are listed, accepted and given an owner and a date.
3. Content is final, and forms, tracking and redirects are tested on the live address.
4. The client has reviewed the site on their own phone and laptop.

Use it on your next project

Print the checklist, run it page by page with the design open beside the build, and keep the log. The second pass, to confirm the fixes, is part of the job, not an extra. If you are planning another review step before launch, the same idea applies to other builds: test before you go live.

Lobos Design is a two-person studio in Las Palmas de Gran Canaria that designs and builds websites with the same people, so the review is a conversation and not a handover. See our design and development service if you want that.