The Design QA Checklist We Use on Every Project

Design QA is the least glamorous part of our process. It’s methodical, detailed, and time-consuming. It’s also non-negotiable.

Catching inconsistencies before development saves days of back-and-forth later. A $100 problem in Figma becomes a $1,000 problem in code. We’ve learned this the hard way.

Here’s the checklist we run on every project before anything goes to development.

Typography

Consistency

• All text uses defined type styles (no one-off formatting)
• Heading hierarchy is logical (H1 → H2 → H3, never skipping levels)
• Line lengths are readable (45-75 characters for body text)
• Line heights are appropriate (1.4-1.6 for body, 1.1-1.2 for headings)

Accessibility

• Base font size is at least 16px
• Text contrast meets WCAG AA (4.5:1 for normal text, 3:1 for large)
• No text smaller than 12px (14px preferred minimum)
• Font weights maintain readability at all sizes

Responsive

• Type scale is defined for all breakpoints
• Long words and URLs don’t break layouts
• Text remains readable on small screens

Color

System

• All colors are from the defined palette (no hex code orphans)
• Semantic colors are used consistently (error, success, warning)
• Dark mode colors are defined (if applicable)

Accessibility

• All text passes WCAG AA contrast requirements
• Interactive elements have sufficient contrast
• Color is not the only indicator of meaning
• Focus states are clearly visible

Application

• Background/foreground pairings are documented
• Gradients and overlays maintain text readability
• Colors work in both light and dark modes

Spacing

Consistency

• All spacing uses the defined scale (no magic numbers)
• Spacing is consistent across similar components
• Relationship between elements is visually logical

Responsive

• Spacing adjusts appropriately across breakpoints
• Touch targets are at least 44x44px on mobile
• Content doesn’t feel cramped on small screens

Layout

Grid

• All layouts align to the defined grid
• Column and gutter widths are consistent
• Content width is appropriate for readability

Responsive

• All pages have designs for each breakpoint
• Breakpoint transitions are logical (no jarring changes)
• Content priority is maintained across screen sizes

Edge cases

• Layouts work with minimum content
• Layouts work with maximum content
• Empty states are designed
• Error states are designed

Components

Completeness

• All states are designed (default, hover, focus, active, disabled)
• All variants are documented
• Edge cases are considered (long text, missing images, etc.)

Consistency

• Similar components behave similarly
• Interactive patterns are predictable
• Component naming follows conventions

Accessibility

• Focus order is logical
• Focus states are visible
• Components work with keyboard navigation
• Screen reader annotations are provided

Imagery

Quality

• Images are high resolution (2x for retina)
• Aspect ratios are defined and consistent
• Placeholder images indicate final requirements

Accessibility

• Alt text requirements are documented
• Decorative vs. informative images are distinguished
• Images have appropriate contrast with surroundings

Performance

• Image dimensions are appropriate (not oversized)
• Hero images have loading priority noted
• Lazy loading candidates are identified

Interaction

Feedback

• All interactive elements have hover states
• Click/tap feedback is immediate
• Loading states are designed
• Success/error states are designed

Animation

• Animations have purpose (not just decoration)
• Duration and easing are defined
• Reduced motion alternatives are considered
• Animations don’t block interaction

Navigation

• Navigation patterns are consistent
• Current page/section is indicated
• Back/forward navigation is logical

Content

Copy

• All placeholder text is marked for replacement
• Character limits are defined where needed
• Error messages are helpful and specific

Localization

• Text expansion is accounted for (30-50% for translations)
• Date/time/number formats are noted
• RTL considerations are documented (if applicable)

Documentation

Specs

• All measurements are explicit (no eyeballing)
• Interactions are described or prototyped
• Edge cases are documented
• Developer questions are anticipated

Assets

• All icons are exportable as SVG
• Images are organized and named consistently
• Color tokens are documented
• Typography tokens are documented

Final review

Fresh eyes

• Someone who didn’t design it reviews it
• Stakeholder approval is documented
• Outstanding questions are resolved

Handoff

• Design files are organized and named
• Prototype links are current
• Documentation is complete and accessible

---

How we use this checklist

This isn’t a one-time review. We check typography early, spacing mid-project, and everything before handoff.

We also customize per project. E-commerce needs product card states. SaaS needs form validation. Editorial needs reading experience details.

The checklist is a tool, not a ritual. The goal is quality, not checkbox completion.

---

Want to improve your design QA process? We offer design system audits that include process recommendations. Get in touch.