Resources

Frontend Code Quality Checklist - Ensuring the Build Matches the Design

A design QA checklist for verifying pixel accuracy, responsiveness, font rendering, spacing, interaction fidelity, accessibility, performance, and browser coverage.

Checklist (Interactive) Free Developer Handoff Resources

Resource fit

Built for practical use

Included

Pixel QA

Included

Interaction fidelity

Included

Accessibility checks

Included

Launch-readiness review

By Desisle — SaaS UI/UX Design Agency Version: 2.0 | Last Updated: April 2026 License: Free to use and share with attribution to Desisle (desisle.com)

About This Checklist

After handoff, designs often drift during implementation — fonts render slightly differently, spacing gets approximated, states are simplified, and accessibility gaps appear. This checklist catches those issues before launch.

Who this is for: Designers doing Design QA on built products, developers verifying their work, QA testers running pre-launch reviews, and product managers signing off on feature completeness.

How to use:

  1. Open the live build alongside the Figma design
  2. Walk through each section of this checklist
  3. Flag any discrepancies as tickets
  4. Fix before launch

When to use this checklist:

  • Before merging a feature PR
  • Before shipping a major release
  • After any significant visual update
  • Monthly design QA audits

Interactive audit

Review The Build

Score the frontend implementation and capture the fixes needed before the design can be considered launch-ready.

Typography 1 checks

Font family matches design

— actual font loaded (not a fallback)

Layout & Spacing 1 checks

Padding matches design

— inside cards, buttons, form fields

Part 2: Color Accuracy 1 checks

Color tokens match

— colors reference the exact token values from the design system

Breakpoints 1 checks

Desktop (1440px+)

— layout matches desktop design

Behavior 1 checks

No horizontal scroll

at any standard breakpoint (except for tables/code blocks where expected)

Buttons 1 checks

Default

matches design

Form Inputs 1 checks

Default

state correct

Links 1 checks

Default

— link color matches design

Cards / Containers 1 checks

Default

— background, border, shadow match

Keyboard Navigation 1 checks

Tab order is logical

— follows visual order

Screen Reader 1 checks

Landmarks present

— <header>, <main>, <nav>, <footer> semantic elements

Visual Accessibility 1 checks

Color contrast passes WCAG AA

— verify with browser DevTools or WebAIM

Motion 1 checks

prefers-reduced-motion respected

— animations disabled when set

Core Web Vitals (Google's thresholds) 1 checks

LCP (Largest Contentful Paint) < 2.5 seconds

— measured via Lighthouse or PageSpeed Insights

Lighthouse Scores (Target: 90+) 1 checks

Performance: 90+

— measures load time and responsiveness

Specific Optimizations 1 checks

Images are optimized

— WebP format, appropriate sizes, lazy-loaded below the fold

Desktop Browsers 1 checks

Chrome

(latest) — the baseline

Mobile Browsers 1 checks

Safari iOS

(iPhone) — most common mobile browser; critical for testing

Features to verify per browser 1 checks

Layout renders correctly

— no broken grids or flexbox issues

Part 8: Content & Copy 1 checks

No Lorem Ipsum

anywhere in production

Text Overflow Handling 1 checks

Long names/titles

handled (truncate with ellipsis or wrap)

Part 9: Data & Edge Cases 1 checks

Empty data states work

— new user, filtered-to-zero-results, no history

Part 10: SEO & Metadata 1 checks

Page titles are unique and descriptive

Part 11: Analytics & Tracking 1 checks

Analytics installed and firing

— Google Analytics, Mixpanel, or similar

Part 12: Security Basics 1 checks

HTTPS everywhere

— no mixed content warnings

Launch-Ready Criteria 1 checks

All Blocker issues resolvedAll Major issues resolved or explicitly deferred with ticketsCore Web Vitals passAccessibility audit passedCross-browser testing completeDesigner has signed offEngineer has signed offQA has signed offAnalytics verified firingError tracking verifiedPost-launch monitoring plan in place

Common Implementation Drift Issues

Issue 1: Approximated spacing

Developer uses padding: 15px when design specified padding: 16px. Over dozens of elements, this breaks the spacing system.

Fix: Developers must reference tokens/variables, not hardcoded values.

Issue 2: Missing focus states

Developer removes focus rings "because they look ugly" without providing alternatives.

Fix: Custom focus styles matching design must be implemented. Never outline: none without a replacement.

Issue 3: Fake hover on mobile

Hover styles designed for desktop accidentally appear on mobile touch, causing "stuck" hover states.

Fix: Use @media (hover: hover) to apply hover styles only on devices that support real hover.

Issue 4: Simplified animations

Developer implements "fade" instead of the specified "fade + slide with cubic-bezier easing."

Fix: Animation specs must be implemented exactly, or designer-approved alternatives documented.

Issue 5: Missing empty states

Developer ships with No data as a text string instead of the designed empty state.

Fix: Empty states must be part of the implementation scope, not an afterthought.

Issue 6: Inconsistent component usage

Developer builds a custom button instead of using the design system component.

Fix: Code review catches this — buttons should always use the shared Button component.

Issue 7: Mobile designed desktop-first

Mobile layout is "squished desktop" rather than a genuinely mobile-designed experience.

Fix: Every breakpoint should feel native, not compressed.

Issue 8: Form validation doesn't match design

Error messages appear in different positions, with different styling, or with different copy than designed.

Fix: Validation UX is a distinct design concern — treat it as such.

Design QA Workflow

Step 1: Designer reviews build

Before launch, designer(s) walk through the built product screen by screen, flagging discrepancies.

Step 2: Issues logged

Each discrepancy is logged as a ticket:

  • Screenshot of the design
  • Screenshot of the build
  • Description of the difference
  • Severity: Blocker / Major / Minor

Step 3: Engineer fixes

Engineer fixes flagged issues.

Step 4: Re-review

Designer re-reviews fixed issues.

Step 5: Sign-off

Once all blocker and major issues are resolved, designer signs off.

Severity Classification

Blocker (must fix before launch):

  • Broken functionality
  • Major visual drift that affects usability
  • Accessibility violations (keyboard, contrast, missing alt text)
  • Performance issues (failing Core Web Vitals)
  • Content errors (wrong copy, broken links)

Major (fix before launch if possible):

  • Wrong colors or fonts
  • Missing states (hover, focus, error)
  • Responsive issues at key breakpoints
  • Animation missing or wrong

Minor (can ship, fix in follow-up):

  • Slight spacing differences (2-4px off)
  • Subtle color variations
  • Polish-level animation differences
  • Copy wording (if close but not exact)

Sources and References

  • Google Core Web Vitals — official thresholds (developers.google.com)
  • WCAG 2.1 AA — accessibility standards
  • Nielsen Norman Group — interaction design research
  • MDN Web Docs — browser compatibility reference
  • web.dev (Google) — performance and best practices

Created by Desisle — SaaS UI/UX Design Agency desisle.com | hello@desisle.com Free to use and share with attribution.

For design QA services or audit support, contact us at hello@desisle.com.

More resources

The SaaS UX Audit Checklist - 100 Points to Check Today

The same 100-point UX audit checklist our team uses when reviewing SaaS products across onboarding, navigation, dashboards, forms, accessib…

SaaS Onboarding UX Playbook - The First 60 Seconds That Matter Most

A longer playbook for designing onboarding that activates users instead of only welcoming them. It covers first-time psychology, aha moment…

UX Heuristic Evaluation Template - Nielsen's 10 Heuristics Applied to SaaS

A ready-to-use spreadsheet for heuristic evaluation with Nielsen's heuristics, severity levels, a findings log, and a priority matrix built…
Chat with founder