Figma Design QA Checklist: 30 Things to Check Before Handoff

Nikita Glazunov — Wed, 02 Sep 2026 10:33:35 +0000

A Figma file can look finished and still contain dozens of small problems.

A color might be slightly different from the design system. A button might use a detached component. Two frames might use different spacing for the same layout. A text layer might have the wrong line height. A developer might open the file and have no idea which components are actually ready to build.

None of these problems are particularly difficult to fix.

The difficult part is finding them.

That's what design QA is for.

Before handing a Figma file to development, use this checklist to catch inconsistencies, accessibility problems, design-system violations, and other issues that are easy to miss during a normal design review.

1. Typography

1. Check font families

Make sure the file uses the fonts defined by your design system.

Look for accidental use of:

fallback fonts
old brand fonts
fonts used only once
inconsistent fonts between similar components

2. Check font sizes

Look for arbitrary font sizes that don't belong to your type scale.

For example, if your system uses 12, 14, 16, 20, 24, and 32px, a random 15px text layer is worth investigating.

3. Check font weights

Make sure headings, body text, buttons, and other UI elements use the expected font weights.

A single Medium where everything else uses Semibold can easily slip through a manual review.

4. Check line heights

Line height is particularly easy to overlook.

Two text layers can have the same font size while producing noticeably different layouts because their line heights are different.

5. Check text styles

If your team uses text styles or variables, check for raw values that should be connected to the design system.

Figma variables can represent typography and other design tokens and can also be exposed during developer handoff.

2. Colors

6. Look for hardcoded colors

If your design system has a defined color palette, check for colors that were entered manually instead of using the appropriate style or variable.

This is one of the easiest ways for a design system to slowly become inconsistent.

7. Find duplicate colors

Sometimes two colors have exactly the same value but different names.

Other times, two colors are almost identical:

#1F2937
#202937

These differences are difficult to notice visually but can create unnecessary complexity in a design system.

8. Check semantic colors

Make sure colors are being used for the correct purpose.

For example:

error → error color
success → success color
primary action → primary color
secondary text → secondary text color

Don't rely only on whether the color "looks right."

9. Check contrast

Check text and interactive elements against their backgrounds.

Low contrast is easy to miss when you're designing on a large monitor, especially when the UI contains many similar shades.

Figma currently provides accessibility-related checks for color combinations, and its accessibility guidance is based around WCAG standards.

3. Spacing and layout

10. Check spacing consistency

Look for repeated patterns that use different spacing values.

For example:

16px between one card's elements
20px between another card's elements
15px somewhere else

Sometimes the difference is intentional. Often it isn't.

11. Check padding

Review components for inconsistent internal padding.

Buttons, cards, inputs, menus, and other repeated components should normally follow predictable spacing rules.

12. Check alignment

Look for elements that are almost aligned but not quite.

Common examples:

text slightly offset from icons
cards with different left padding
buttons that don't align with nearby inputs
inconsistent column alignment

13. Check dimensions

Look for arbitrary widths and heights.

If similar components have wildly different dimensions without a good reason, investigate them.

14. Check Auto Layout

Make sure reusable components use Auto Layout where appropriate.

A component that only works at one specific size can cause problems later when content changes.

4. Components

15. Check detached instances

Detached components are one of the easiest ways to accidentally bypass a design system.

A designer may detach a component to make a quick change and forget to reconnect it later.

Not every detached component is a problem, but they're worth reviewing.

16. Check component variants

Make sure components use the correct variants.

For example, a button might have:

Primary
Secondary
Destructive
Disabled

Using a slightly modified copy instead of the actual variant can create unnecessary divergence.

17. Check component consistency

Compare repeated components across the file.

Do all buttons behave the same way?

Do all inputs use the same height?

Do cards use the same radius?

Do icons have consistent sizing?

18. Look for duplicate components

Large files often accumulate multiple components that do almost exactly the same thing.

If two components have the same purpose, consider consolidating them.

5. Design system

19. Check variables and tokens

If your team uses Figma variables, check that designs actually use them.

Raw values can appear when designers detach variables or manually enter values. Figma's Dev Mode can even suggest matching variables for raw values when the value and scope match.

20. Check naming

Use a consistent naming convention for:

components
variants
variables
styles
layers
pages

Good naming becomes especially important when developers inspect the file.

21. Check deprecated styles

If your design system has old styles or variables, make sure new designs aren't still using them.

Otherwise, old tokens can continue spreading through new work.

22. Check design-system deviations

Ask a simple question:

Does this design actually use the design system?

Not every deviation is wrong. Sometimes the design genuinely requires something new.

The important thing is knowing which deviations are intentional.

6. Accessibility

23. Check color contrast

Don't assume that a visually pleasing combination is accessible.

Check important text, controls, and UI states against their backgrounds.

24. Check touch target sizes

Small interactive elements can create accessibility problems, particularly on mobile.

Buttons, icons, checkboxes, and other controls should have sufficiently large interactive areas.

25. Check labels and names

Important UI elements should have meaningful names and labels.

This is especially important when the design will eventually be used with assistive technologies.

26. Don't rely only on color

If color is the only way users can understand a state, the interface may not be accessible.

For example, don't communicate:

Red = error
Green = success

without another visual or textual indicator.

Figma's current accessibility tooling specifically addresses issues such as contrast, touch targets, missing labels, and color combinations for colorblind users.

7. File organization

27. Clean up layer names

A developer shouldn't have to decipher:

Frame 234

Rectangle 182

Group 17

Use meaningful names for important layers and components.

Figma also recommends meaningful layer and component names as part of preparing files for developer handoff.

28. Remove unnecessary layers

Delete:

unused objects
hidden experiments
old versions
temporary elements
unnecessary duplicates

A clean file is easier for everyone to work with.

29. Organize pages and sections

Make it obvious where developers should look.

A typical structure might be:

Cover
Design system
Components
Screens
Prototypes
Archive

The exact structure doesn't matter as much as consistency.

8. Developer handoff

30. Make the handoff explicit

Before saying "ready for development," check:

Are all relevant screens complete?
Are component states included?
Are important interactions documented?
Are assets available?
Are measurements clear?
Are variables and styles connected?
Are important edge cases covered?
Is it obvious which designs are ready to build?

Figma's Dev Mode provides statuses, annotations, measurements, and inspection tools specifically to make the handoff process clearer.

A good handoff isn't just a finished-looking screen. It's a file that another person can actually understand and implement.

The problem with doing all of this manually

The checklist above is useful, but there's a catch.

Most designers don't forget to check these things because they don't care about quality.

They forget because there are too many things to check.

You can spend 20 minutes reviewing a file and still miss:

a few inconsistent colors
several spacing violations
detached components
raw values that should use variables
accessibility issues
inconsistent naming

And the larger the file gets, the harder manual QA becomes.

That's why I built StyleGuard.

StyleGuard scans a Figma file for design issues and lets you define your own rules. It can identify inconsistencies and automatically fix many of them.

The idea isn't to replace design judgment.

It's to automate the boring checks so you can spend your time on the things that actually require judgment.

Try StyleGuard in Figma →

Final checklist

Before handing off a Figma file, ask:

Are fonts correct?

Are font sizes and weights consistent?

Are line heights correct?

Are text styles being used?

Are colors consistent?

Are variables and tokens being used?

Is contrast sufficient?

Is spacing consistent?

Are layouts aligned?

Are components connected correctly?

Are component variants correct?

Are there unnecessary detached components?

Are naming conventions followed?

Are deprecated styles avoided?

Are accessibility issues addressed?

Are layers named clearly?

Is the file organized?

Are unnecessary layers removed?

Are all important states included?

Are annotations and measurements clear?

Is the file actually ready for development?

If you can answer yes to all of these, your handoff is going to be much smoother.

And if you can't, that's exactly what design QA is for.

DEV Community: Nikita Glazunov