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.
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.
Top comments (0)