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.
Built for practical use
Pixel QA
A design QA checklist for verifying pixel accuracy, responsiveness, font rendering, spacing, interaction fidelity, accessibility, performance, and browser coverage.
Interaction fidelity
A design QA checklist for verifying pixel accuracy, responsiveness, font rendering, spacing, interaction fidelity, accessibility, performance, and browser coverage.
Accessibility checks
A design QA checklist for verifying pixel accuracy, responsiveness, font rendering, spacing, interaction fidelity, accessibility, performance, and browser coverage.
Launch-readiness review
A design QA checklist for verifying pixel accuracy, responsiveness, font rendering, spacing, interaction fidelity, accessibility, performance, and browser coverage.
Review The Build
Score the frontend implementation and capture the fixes needed before the design can be considered launch-ready.
Typography
Font family matches design
— actual font loaded (not a fallback)
Font sizes match Figma exactly
— 14px is 14px, not 13.8px or 15px
Font weights match
— Regular (400), Medium (500), Semibold (600), Bold (700) as specified
Line heights match
— 1.5x body text, tighter for headings
Letter spacing matches
— especially for all-caps text or display headlines
Layout & Spacing
Padding matches design
— inside cards, buttons, form fields
Margins match design
— between elements, sections, groups
Element widths and heights match
— button heights, input heights, card widths
Part 2: Color Accuracy (5 Points)
Color tokens match
— colors reference the exact token values from the design system
Brand colors exact
— primary blue is #3B82F6, not #3C82F5
Gradients match
— if used, angles and color stops are correct
Opacity/alpha values correct
— 50% opacity is rendered as 50%, not 40% or 60%
Dark mode colors correct
(if supporting dark mode)
Breakpoints
Desktop (1440px+)
— layout matches desktop design
Laptop (1024-1439px)
— layout adapts as designed
Tablet (768-1023px)
— layout shifts appropriately
Mobile Large (414px)
— mobile layout correct
Mobile Small (375px)
— doesn't break at standard iPhone size
Mobile XS (320px)
— still usable at minimum supported width
Behavior
No horizontal scroll
at any standard breakpoint (except for tables/code blocks where expected)
Content reflows smoothly
between breakpoints (no awkward "broken" states)
Images scale responsively
— don't overflow or distort
Typography scales appropriately
— headings smaller on mobile
Buttons
Default
matches design
Hover
— color/background change as designed
Focus
— visible focus ring matches design
Active/Pressed
— brief state during click
Disabled
— reduced opacity or different style; cursor: not-allowed
Loading
— spinner or skeleton inside button
Form Inputs
Default
state correct
Hover
— border color change
Focus
— focus ring or border emphasis
Filled
(has content) — often same as default
Disabled
— reduced opacity
Error
— red border + error message
Success
(if designed) — green border + checkmark
With helper text
— helper text positioned correctly
Links
Default
— link color matches design
Hover
— underline or color change
Visited
(if styled differently)
Focus
— visible focus indicator
Cards / Containers
Default
— background, border, shadow match
Hover
(if interactive) — elevation or background change
Selected
(if applicable) — visual indication of selection
Keyboard Navigation
Tab order is logical
— follows visual order
All interactive elements are reachable
via keyboard
Focus indicators visible
on every focusable element
Escape key closes modals/dropdowns
Enter/Space activates buttons
Arrow keys work in menus/dropdowns
Screen Reader
Landmarks present
— `<header>`, `<main>`, `<nav>`, `<footer>` semantic elements
Heading hierarchy logical
— H1, H2, H3 in order, no skipped levels
Form labels associated
with their inputs
Error messages programmatically associated
— aria-describedby or aria-errormessage
Icon-only buttons have aria-label
Images have alt text
— meaningful alt, or empty alt="" for decorative
Dynamic content changes announced
— aria-live regions for toasts, alerts
Modal focus trap works
— focus stays within modal while open
Visual Accessibility
Color contrast passes WCAG AA
— verify with browser DevTools or WebAIM
Touch targets are 44×44px minimum
on mobile
Text can resize to 200%
without loss of functionality
Content reflows at 320px width
Motion
prefers-reduced-motion respected
— animations disabled when set
Core Web Vitals (Google's thresholds)
LCP (Largest Contentful Paint) < 2.5 seconds
— measured via Lighthouse or PageSpeed Insights
INP (Interaction to Next Paint) < 200 milliseconds
— measured via field data (Chrome UX Report)
CLS (Cumulative Layout Shift) < 0.1
— no unexpected layout jumps
Lighthouse Scores (Target: 90+)
Performance: 90+
— measures load time and responsiveness
Accessibility: 95+
— automated accessibility checks
Best Practices: 95+
— security and modern web standards
SEO: 90+
— meta tags and indexability basics
Specific Optimizations
Images are optimized
— WebP format, appropriate sizes, lazy-loaded below the fold
JavaScript is code-split
— no massive single bundle
CSS is minified and tree-shaken
— no unused styles in production
Fonts are optimized
— font-display: swap, subsets used
Third-party scripts are deferred
— analytics, chat widgets don't block rendering
Caching headers set
— static assets cached appropriately
Desktop Browsers
Chrome
(latest) — the baseline
Firefox
(latest) — notable differences in form styling, scrollbars
Safari
(latest) — known issues: different font rendering, older CSS spec support
Edge
(latest) — usually same as Chrome (Chromium-based)
Mobile Browsers
Safari iOS
(iPhone) — most common mobile browser; critical for testing
Chrome Android
— most common Android browser
Samsung Internet
— popular on Samsung devices in some markets
Features to verify per browser
Layout renders correctly
— no broken grids or flexbox issues
Animations play smoothly
— no janky transitions
Forms work
— validation, submission, keyboard behavior
Media playback
— videos, audio (if used)
Touch interactions work
on mobile browsers
Part 8: Content & Copy (5 Points)
No Lorem Ipsum
anywhere in production
Real product copy is in place
— headlines, CTAs, labels all use final copy
Error messages are the final version
— not placeholder text
Empty states have final copy
Typos checked
— run through a proofreading tool
Text Overflow Handling
Long names/titles
handled (truncate with ellipsis or wrap)
Long URLs
don't break layout
Large numbers
format correctly (1,000,000 not 1000000)
Part 9: Data & Edge Cases (7 Points)
Empty data states work
— new user, filtered-to-zero-results, no history
Single item states work
— lists with only 1 item
Many items states work
— lists with 1000+ items; pagination or virtualization
Long text handled
— very long names, titles, descriptions
Numeric edge cases
— 0, negative, very large (1,000,000+), decimal precision
Date edge cases
— past dates, far future, edge timezones
Null/undefined handled
— missing fields don't crash the UI
Part 10: SEO & Metadata (5 Points)
Page titles are unique and descriptive
Meta descriptions set for public pages
Open Graph tags present
— og:title, og:description, og:image
Favicon loads correctly
Structured data (JSON-LD)
implemented for relevant page types
Part 11: Analytics & Tracking (5 Points)
Analytics installed and firing
— Google Analytics, Mixpanel, or similar
Key events tracked
— signups, conversions, feature adoption
Error tracking setup
— Sentry or similar
Performance monitoring
— real-user metrics collected
Privacy compliance
— cookie banners, consent management (GDPR/CCPA if applicable)
Part 12: Security Basics (5 Points)
HTTPS everywhere
— no mixed content warnings
Forms use POST for sensitive data
— not GET
Passwords never shown in URLs or logs
CSRF protection
on mutating forms
Content Security Policy
set appropriately
Launch-Ready Criteria
All Blocker issues resolved
All Major issues resolved or explicitly deferred with tickets
Core Web Vitals pass
Accessibility audit passed
Cross-browser testing complete
Designer has signed off
Engineer has signed off
QA has signed off
Analytics verified firing
Error tracking verified
Post-launch monitoring plan in place
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:
- Open the live build alongside the Figma design
- Walk through each section of this checklist
- Flag any discrepancies as tickets
- 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
Part 1: Pixel-Level Accuracy (10 Points)
Typography
- Font family matches design — actual font loaded (not a fallback)
- Font sizes match Figma exactly — 14px is 14px, not 13.8px or 15px
- Font weights match — Regular (400), Medium (500), Semibold (600), Bold (700) as specified
- Line heights match — 1.5x body text, tighter for headings
- Letter spacing matches — especially for all-caps text or display headlines
Layout & Spacing
- Padding matches design — inside cards, buttons, form fields
- Margins match design — between elements, sections, groups
- Element widths and heights match — button heights, input heights, card widths
Tools for verification:
- Use Figma's Dev Mode to see exact spec values
- Use browser DevTools to inspect computed styles
- Overlay Figma screens on built page (PerfectPixel Chrome extension)
Part 2: Color Accuracy (5 Points)
- Color tokens match — colors reference the exact token values from the design system
- Brand colors exact — primary blue is #3B82F6, not #3C82F5
- Gradients match — if used, angles and color stops are correct
- Opacity/alpha values correct — 50% opacity is rendered as 50%, not 40% or 60%
- Dark mode colors correct (if supporting dark mode)
Common issues:
- Rendering differences across browsers (Safari sometimes shows slightly different hues)
- Compressed screenshots in Figma can look different from actual CSS colors
- Color profile differences (sRGB vs. Display P3) can cause subtle shifts
Part 3: Responsive Behavior (10 Points)
Breakpoints
Test at each breakpoint and verify the layout matches the design:
- Desktop (1440px+) — layout matches desktop design
- Laptop (1024-1439px) — layout adapts as designed
- Tablet (768-1023px) — layout shifts appropriately
- Mobile Large (414px) — mobile layout correct
- Mobile Small (375px) — doesn't break at standard iPhone size
- Mobile XS (320px) — still usable at minimum supported width
Behavior
- No horizontal scroll at any standard breakpoint (except for tables/code blocks where expected)
- Content reflows smoothly between breakpoints (no awkward "broken" states)
- Images scale responsively — don't overflow or distort
- Typography scales appropriately — headings smaller on mobile
Tools:
- Chrome DevTools responsive mode
- BrowserStack or LambdaTest for real device testing
- Manual resize of browser window
Part 4: Interactive States (10 Points)
Every interactive element should have all states implemented correctly:
Buttons
- Default matches design
- Hover — color/background change as designed
- Focus — visible focus ring matches design
- Active/Pressed — brief state during click
- Disabled — reduced opacity or different style; cursor: not-allowed
- Loading — spinner or skeleton inside button
Form Inputs
- Default state correct
- Hover — border color change
- Focus — focus ring or border emphasis
- Filled (has content) — often same as default
- Disabled — reduced opacity
- Error — red border + error message
- Success (if designed) — green border + checkmark
- With helper text — helper text positioned correctly
Links
- Default — link color matches design
- Hover — underline or color change
- Visited (if styled differently)
- Focus — visible focus indicator
Cards / Containers
- Default — background, border, shadow match
- Hover (if interactive) — elevation or background change
- Selected (if applicable) — visual indication of selection
Part 5: Accessibility (10 Points)
Keyboard Navigation
- Tab order is logical — follows visual order
- All interactive elements are reachable via keyboard
- Focus indicators visible on every focusable element
- Escape key closes modals/dropdowns
- Enter/Space activates buttons
- Arrow keys work in menus/dropdowns
Screen Reader
- Landmarks present —
<header>,<main>,<nav>,<footer>semantic elements - Heading hierarchy logical — H1, H2, H3 in order, no skipped levels
- Form labels associated with their inputs
- Error messages programmatically associated — aria-describedby or aria-errormessage
- Icon-only buttons have aria-label
- Images have alt text — meaningful alt, or empty alt="" for decorative
- Dynamic content changes announced — aria-live regions for toasts, alerts
- Modal focus trap works — focus stays within modal while open
Visual Accessibility
- Color contrast passes WCAG AA — verify with browser DevTools or WebAIM
- Touch targets are 44×44px minimum on mobile
- Text can resize to 200% without loss of functionality
- Content reflows at 320px width
Motion
- prefers-reduced-motion respected — animations disabled when set
Part 6: Performance (10 Points)
Core Web Vitals (Google's thresholds)
- LCP (Largest Contentful Paint) < 2.5 seconds — measured via Lighthouse or PageSpeed Insights
- INP (Interaction to Next Paint) < 200 milliseconds — measured via field data (Chrome UX Report)
- CLS (Cumulative Layout Shift) < 0.1 — no unexpected layout jumps
Lighthouse Scores (Target: 90+)
- Performance: 90+ — measures load time and responsiveness
- Accessibility: 95+ — automated accessibility checks
- Best Practices: 95+ — security and modern web standards
- SEO: 90+ — meta tags and indexability basics
Specific Optimizations
- Images are optimized — WebP format, appropriate sizes, lazy-loaded below the fold
- JavaScript is code-split — no massive single bundle
- CSS is minified and tree-shaken — no unused styles in production
- Fonts are optimized — font-display: swap, subsets used
- Third-party scripts are deferred — analytics, chat widgets don't block rendering
- Caching headers set — static assets cached appropriately
Part 7: Cross-Browser Compatibility (8 Points)
Test the build on:
Desktop Browsers
- Chrome (latest) — the baseline
- Firefox (latest) — notable differences in form styling, scrollbars
- Safari (latest) — known issues: different font rendering, older CSS spec support
- Edge (latest) — usually same as Chrome (Chromium-based)
Mobile Browsers
- Safari iOS (iPhone) — most common mobile browser; critical for testing
- Chrome Android — most common Android browser
- Samsung Internet — popular on Samsung devices in some markets
Features to verify per browser
- Layout renders correctly — no broken grids or flexbox issues
- Animations play smoothly — no janky transitions
- Forms work — validation, submission, keyboard behavior
- Media playback — videos, audio (if used)
- Touch interactions work on mobile browsers
Tools:
- BrowserStack or LambdaTest — cloud-based testing across many browser/OS combinations
- Can I Use (caniuse.com) — check CSS/JS feature support
- Physical device testing for mobile
Part 8: Content & Copy (5 Points)
- No Lorem Ipsum anywhere in production
- Real product copy is in place — headlines, CTAs, labels all use final copy
- Error messages are the final version — not placeholder text
- Empty states have final copy
- Typos checked — run through a proofreading tool
Text Overflow Handling
- Long names/titles handled (truncate with ellipsis or wrap)
- Long URLs don't break layout
- Large numbers format correctly (1,000,000 not 1000000)
Part 9: Data & Edge Cases (7 Points)
- Empty data states work — new user, filtered-to-zero-results, no history
- Single item states work — lists with only 1 item
- Many items states work — lists with 1000+ items; pagination or virtualization
- Long text handled — very long names, titles, descriptions
- Numeric edge cases — 0, negative, very large (1,000,000+), decimal precision
- Date edge cases — past dates, far future, edge timezones
- Null/undefined handled — missing fields don't crash the UI
Part 10: SEO & Metadata (5 Points)
- Page titles are unique and descriptive
- Meta descriptions set for public pages
- Open Graph tags present — og:title, og:description, og:image
- Favicon loads correctly
- Structured data (JSON-LD) implemented for relevant page types
See Resource 12: SaaS Meta Tags Cheat Sheet for detailed requirements.
Part 11: Analytics & Tracking (5 Points)
- Analytics installed and firing — Google Analytics, Mixpanel, or similar
- Key events tracked — signups, conversions, feature adoption
- Error tracking setup — Sentry or similar
- Performance monitoring — real-user metrics collected
- Privacy compliance — cookie banners, consent management (GDPR/CCPA if applicable)
Part 12: Security Basics (5 Points)
- HTTPS everywhere — no mixed content warnings
- Forms use POST for sensitive data — not GET
- Passwords never shown in URLs or logs
- CSRF protection on mutating forms
- Content Security Policy set appropriately
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)
Launch-Ready Criteria
A feature is launch-ready when:
- All Blocker issues resolved
- All Major issues resolved or explicitly deferred with tickets
- Core Web Vitals pass
- Accessibility audit passed
- Cross-browser testing complete
- Designer has signed off
- Engineer has signed off
- QA has signed off
- Analytics verified firing
- Error tracking verified
- Post-launch monitoring plan in place
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.
Keep Building With These Next
Design-to-Dev Handoff Checklist - Everything Developers Need From Designers
A pre-handoff checklist for states, breakpoints, spacing, animations, color tokens, typography, exports, and accessibility annotations.
Open Handoff ChecklistThe 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, accessibility, mobile responsiveness, and performance.
Open UX Audit ChecklistThe UI Design Checklist - 80 Points for Pixel-Perfect Screens
A UI review checklist for typography, color systems, spacing, consistency, responsiveness, states, accessibility, and handoff readiness.
Open UI ChecklistNeed This Applied to Your Product? We'll Turn It Into Execution.
These resource pages are meant to be used hands-on. If you want the audit, plan, or framework translated into live product work, we can do that with your team.