This guide walks you through building a reusable design QA checklist that your team can use before every handoff. By the end, you will have a structured, version-controlled checklist covering visual consistency, accessibility, responsive behaviour, and component accuracy. The full process takes about two to three hours to set up and pays for itself on the first review cycle.

What You'll Build

  • A layered design QA checklist covering spacing, typography, colour, accessibility, and responsiveness
  • A Figma annotation workflow that ties each QA item directly to a frame or component
  • A Notion or GitHub Issues template so QA findings become trackable tickets automatically
  • A sign-off protocol that both designers and developers follow before a build goes to staging

Prerequisites

  • Figma (any paid plan with Dev Mode enabled, as of 2026)
  • Access to your team's component library or design system
  • A project management tool: Notion, Linear, or GitHub Issues
  • Basic familiarity with WCAG 2.2 success criteria

Step 1: Audit What Is Actually Breaking in Production

Start with evidence, not assumptions. Before you write a single checklist item, pull a list of every UI bug or design inconsistency that shipped in the last three to six months. Check your bug tracker, Slack threads, and any Loom recordings from developer handoff sessions.

Categorise each issue. Common categories include spacing errors, wrong font weights, missing states, colour contrast failures, and broken responsive layouts. The categories that appear most often become the top sections of your checklist.

This step takes about thirty minutes. Skip it and you risk building a checklist that covers theoretical problems while real ones keep slipping through.

What if your team has no bug history to review?

Run a one-hour QA pass on your current live product. Open it on a desktop browser, a mid-range Android device, and an iPhone at 150% text size. Screenshot every inconsistency you find. That becomes your baseline.

Step 2: Structure the Checklist Into Layers

A flat list of sixty items is hard to use. A layered checklist is scannable and lets reviewers focus on one concern at a time.

Use these five layers as your starting structure:

  1. Foundations: spacing scale, colour tokens, typography scale
  2. Components: states (default, hover, focus, disabled, error, loading), variants, slot content
  3. Accessibility: colour contrast, focus order, touch target size, alt text, ARIA labels
  4. Responsiveness: breakpoints, text wrapping, image scaling, sticky elements
  5. Copy and content: truncation, placeholder text removed, real data tested

Keep each item binary. Every entry should have a clear yes or no answer. Avoid items like "spacing feels right" because that is not testable. Write "Spacing matches the 8px base grid defined in the design token set" instead.

How many items should a good design QA checklist have?

Between thirty and fifty items is a practical range for most product teams. Fewer than thirty misses edge cases. More than sixty creates fatigue and reviewers start skimming. If your list exceeds fifty, split it into a quick review (twenty items for minor UI updates) and a full review (all items for new features or page redesigns).

Step 3: Build the Checklist as a Figma Template

Keep the checklist close to the work. A Figma template means reviewers never have to switch tools to log a finding.

Create a new Figma page in your main file called QA Review. On that page, build a checklist frame with the following structure:

QA Review — [Feature Name] — [Date]

▸ Foundations
  ☐ All spacing uses the 8px grid
  ☐ Colour values match design tokens (not hex overrides)
  ☐ Font styles use Text Styles, not local overrides

▸ Components
  ☐ All interactive components show hover and focus states
  ☐ Error states are designed, not placeholder text
  ☐ Loading states exist for async actions
  ☐ No detached component instances

▸ Accessibility
  ☐ All text passes WCAG 2.2 AA contrast (4.5:1 for body, 3:1 for large text)
  ☐ Focus order follows reading order
  ☐ Touch targets are minimum 44x44px
  ☐ Images have descriptive alt text noted in annotations

▸ Responsiveness
  ☐ Reviewed at 375px, 768px, 1280px, and 1440px
  ☐ No content overflow at any tested breakpoint
  ☐ Sticky/fixed elements tested with keyboard scroll

▸ Copy
  ☐ No lorem ipsum remaining
  ☐ Long strings tested (name fields, error messages)
  ☐ All CTAs reviewed for clarity with a non-technical reader

Use Figma's built-in checkbox component or a simple icon toggle so reviewers can mark items inline. Add a sticky annotation layer at the top of each frame for the reviewer's name and sign-off date.

Should you use Figma's Dev Mode annotations for QA findings?

Yes, for component-level issues. Use Dev Mode annotations to flag a specific layer when a token is overridden or a spacing value is off. For higher-level findings, a comment on the frame works better because it is visible to everyone, not just developers in Dev Mode.

Step 4: Connect QA Findings to a Ticket System

A finding that stays in Figma rarely gets fixed. Wire your checklist to your project management tool so every failed item becomes a trackable ticket automatically.

Here is a basic Notion database template you can duplicate:

Properties:
- Finding (text)
- Layer: Foundations / Components / Accessibility / Responsiveness / Copy
- Severity: Blocker / Major / Minor
- Linked Frame (URL to Figma frame)
- Assigned to (person)
- Status: Open / In Review / Resolved
- Sprint (relation to sprint table)

If your team uses Linear or GitHub Issues, create an issue template with the same fields. The goal is one click from a Figma comment to an open ticket.

Teams that use this system report cutting the average time between a QA finding and a developer fix by roughly fifty percent, because context lives in the ticket rather than in a conversation thread.

Step 5: Define Severity Levels

Not every QA issue is equal. Without severity levels, a misaligned icon gets the same urgency as a failed contrast ratio on a primary CTA.

Use three levels:

  • Blocker: Fails WCAG 2.2 AA, breaks a user flow, or causes data loss. Cannot ship.
  • Major: Visually incorrect but functional. Must be resolved before release unless there is a documented exception.
  • Minor: Cosmetic or inconsistent with the design system but does not affect usability. Can ship with a follow-up ticket logged.

Add the severity definition to the top of your Figma QA template and your Notion database. Reviewers should apply the same definition every time, not use their judgment in the moment.

Step 6: Run a Pilot QA Review

Before rolling the checklist out to the full team, run one complete QA review yourself. Choose a real feature that is about to go to handoff.

Time the review. A well-structured checklist for a single screen or flow should take between fifteen and forty-five minutes, depending on complexity. If it takes longer, the checklist has too many ambiguous items. Rewrite those items to be more specific.

Document every finding in your ticket system. At the end, count how many issues you found that would not have been caught without the checklist. Share that number with your team. That is your internal case for adopting the process.

What if developers push back on the extra process?

Frame it around time. A QA finding caught in Figma takes five to ten minutes to fix. The same finding caught after a build goes to staging takes thirty to ninety minutes. The checklist saves developer time, it does not add to it. Show the pilot data from your first review to make that case.

Step 7: Build a Sign-Off Protocol

The checklist only works if it is required, not optional. Create a sign-off protocol with two gates.

Gate 1: Designer sign-off. The designer who created the work completes the full checklist before marking the Figma file as ready for handoff. They add their name and date to the QA Review page.

Gate 2: Second reviewer sign-off. A second designer or a designated QA reviewer checks the Blockers and Major items only. This takes roughly fifteen minutes and catches issues the original designer missed because of familiarity bias.

Add both sign-offs as a required field in your handoff workflow, whether that is a Figma status label, a Notion checkbox, or a Linear workflow step. Nothing moves to development until both gates are complete.

At Lenka Studio, we use a version of this two-gate system across all client projects. It has become one of the simplest ways to reduce revision cycles after development starts.

Step 8: Schedule a Quarterly Checklist Review

Your product changes. New components get added. New accessibility standards are published (WCAG 3.0 is progressing as of mid-2026). Your checklist needs to keep pace.

Block a one-hour session every quarter to review each checklist item. Ask three questions about each one:

  1. Did this item catch a real issue in the last three months?
  2. Is this item still relevant to our current component library?
  3. Has any tool or standard changed that requires us to update how we test this item?

Remove items that never catch anything. Add items based on new patterns of failure. Version the checklist in your Figma file using page names like QA Checklist v1.0 and QA Checklist v1.1 so you have a history.

If you want a starting point for evaluating your overall design consistency before building the checklist, the Lenka Studio brand health score assessment gives you a structured view of where your visual identity and UI consistency currently stand.

Frequently Asked Questions

How is a design QA checklist different from a developer QA checklist?

A design QA checklist is completed before handoff and focuses on visual accuracy, design system compliance, and accessibility at the design layer. A developer QA checklist is completed after build and focuses on functional correctness, browser compatibility, and code-level accessibility implementation. Both are needed and they should reference each other, but they are not the same document.

Can this process work for small teams of one or two designers?

Yes. For solo designers, skip Gate 2 and replace it with a twenty-four-hour cool-down before doing your own second pass. Familiarity bias is the main thing Gate 2 addresses, and time away from the work produces a similar effect.

Which accessibility contrast tool should I use alongside this checklist?

Use the Figma plugin Contrast by Stark or the standalone WebAIM Contrast Checker for WCAG 2.2 AA and AAA values. Both tools are current as of 2026 and reference the 4.5:1 ratio for normal text and 3:1 for large text and UI components defined in WCAG 2.2.

How do I handle QA for dark mode or multiple themes?

Add a theme column to each checklist item and duplicate the relevant sections for each theme variant. Colour contrast and token checks in particular must be run separately for each theme. Components that use semantic tokens rather than hard-coded hex values will pass this check faster because the token system handles the mapping.

Should the checklist live in Figma or in a separate tool?

Keep the checklist template in Figma for frame-level reviews and mirror the findings in your project management tool for tracking. Splitting them entirely means context gets lost. Keeping everything in Figma means nothing gets tracked to completion. The hybrid approach works best for teams of three or more.

Next Steps

Start with Step 1 today. Pull your last three months of bug reports and spend thirty minutes categorising them. That single exercise will tell you more about where your design QA process is failing than any template can.

Once you have your checklist running, consider pairing it with a content planning rhythm to keep design and marketing work in sync. The Lenka Studio social media toolkit is a free content calendar template that works well alongside structured design workflows for teams managing both product and brand output.

If you want help building a design QA process that fits your team's specific stack and handoff workflow, the team at Lenka Studio works with SMBs across Australia, Singapore, Canada, and the US to set up exactly this kind of structured design practice. Get in touch and we can show you what a clean handoff process looks like in practice.