A well-organized icon library reduces design drift, speeds up handoff, and makes new interface work easier to maintain. This reusable audit checklist helps you review icons in Figma, on the web, and in mobile apps, from naming and grid alignment to accessibility, component properties, and export files.
Overview
An icon audit is more than a visual tidy-up. It is a structured review of the assets, rules, and usage decisions that make an icon system dependable. The goal is to identify duplicates, remove inconsistent drawings, clarify which variants are approved, and give designers and developers enough information to use each icon correctly.
Start by defining the scope. You might audit a complete product library, a single feature area, or the icons included in a new release. Collect the source components in Figma, exported SVG or raster files, code references, and any existing documentation. If the library serves both web and mobile products, record platform-specific requirements rather than assuming one export works everywhere.
Use the table below as a quick review framework. The exact values will depend on your visual language, but consistency within the system matters more than choosing a particular number.
| Audit area | What to review | Useful decision |
|---|---|---|
| Naming | Names, capitalization, separators, and category structure | Adopt a predictable pattern such as category/action-variant. |
| Icon size | Base frame, optical size, and allowed display sizes | Define standard sizes and document exceptions. |
| Stroke weight | Stroke thickness, joins, caps, and corner treatment | Use a shared visual rule unless a deliberate exception is documented. |
| Grid alignment | Keyline placement, padding, baseline, and pixel alignment | Align geometry to a common grid and check optical balance. |
| Variants | Outlined, filled, compact, active, disabled, and selected versions | Keep only variants that have a defined product use. |
| Accessibility | Labels, focus behavior, contrast, and decorative treatment | Specify when an icon needs an accessible name and when it is decorative. |
| Formats | Figma components, SVG, raster previews, and platform files | Export the smallest appropriate format without losing required behavior. |
| Figma properties | Component names, variants, exposed properties, and documentation links | Make common changes available through clear, limited properties. |
Checklist by scenario
For a full library audit
- Export or list every icon currently available in the source library and product code.
- Group icons by meaning and function, not only by the page or team that created them.
- Find duplicate concepts, such as multiple versions of search, settings, close, or download.
- Compare the grid, bounding box, stroke weight, corner radius, and optical weight across related icons.
- Mark each icon as approved, needs revision, deprecated, or pending review.
- Record a replacement path for deprecated icons so existing screens can be migrated safely.
- Check whether filled and outlined versions communicate different states or merely reflect historical usage.
For a new feature or product area
- Search the existing library before drawing a new icon for a familiar action.
- Confirm the proposed name, semantic meaning, and intended size with the product team.
- Test the icon beside related actions, at typical interface sizes, and in dense controls.
- Define states such as default, hover, pressed, selected, disabled, loading, or error only when the feature needs them.
- Add the icon to the shared component set rather than leaving a one-off local asset.
- Document a brief usage rule, including what the icon means and what it should not represent.
For web export and handoff
- Use SVG when scalable vector output is suitable for the implementation.
- Remove unnecessary metadata, hidden layers, duplicate paths, and accidental clipping before delivery.
- Decide whether color should inherit from the interface or remain embedded in the file.
- Preserve a view box that supports the intended sizing behavior and does not create unexpected whitespace.
- State whether the icon is decorative or requires an accessible name in the implementation.
- Test the exported file at small and large sizes, against light and dark surfaces, and alongside text.
For mobile app handoff
- Confirm the file format and naming expectations for each mobile platform and codebase.
- Check whether the icon will be rendered as a tintable asset, a multicolor image, or part of a custom interface.
- Review the icon inside the actual control, including touch target spacing and alignment with adjacent labels.
- Provide density or scale variants only when the implementation requires them.
- Verify that platform-specific navigation or system icons are not being replaced casually with visually similar custom assets.
- Test accessibility labels, focus order, and state announcements in the product environment.
What to double-check
Naming conventions: Choose names that describe meaning rather than appearance. “Search” is more useful than “circle-line.” Keep singular and plural forms, separators, and state suffixes consistent. Avoid names that depend on a temporary screen or campaign.
Geometry and optical alignment: Two icons can share the same frame and still appear different in size. Compare their visual mass, side bearings, baseline, and relationship to text. A geometric center is not always an optical center, so inspect icons in context as well as on the grid.
Outlined versus filled variants: Establish a clear rule for when each style is used. For example, a filled version might indicate a selected state, while an outlined version might represent the default state. Do not keep both variants if users or developers cannot tell when to choose one.
Accessibility labels: An icon-only control generally needs a meaningful accessible name, while an icon that repeats nearby text may be decorative. Record this distinction in the component documentation and test it in the implemented interface. Do not rely on the asset filename as the user-facing label.
Figma component properties: Keep properties understandable and purposeful. Expose only the changes people are expected to make, such as icon selection, size, or state. Check that variant names match the naming used in code and documentation. If a property can create an invalid combination, redesign the component structure or document the limitation.
Export quality: Open exported files independently of Figma and inspect them at actual interface sizes. Look for extra padding, unexpected fills, broken masks, fractional coordinates, and strokes that scale unpredictably. For broader SVG workflow guidance, see How to Optimize SVG Files for Faster, More Accessible Websites.
Common mistakes
- Auditing only the canvas: A clean Figma page does not prove that old files, code references, or local overrides have been removed.
- Adding every possible state: Unused variants increase search time and make the system harder to understand. Add states in response to a real interaction requirement.
- Using visual similarity as semantic equivalence: A pencil, edit, and compose icon may look related but can represent different actions. Confirm meaning with the product language.
- Ignoring implementation constraints: An icon that looks correct in a design file may fail because of unsupported color behavior, masks, sizing, or platform conventions.
- Changing icons without a migration plan: Replacing a familiar symbol across a product can affect documentation, code, tutorials, and user expectations. Record what changes and where it must be updated.
- Leaving accessibility until the end: Decide the labeling and decorative behavior while defining the component, not after export.
When to revisit
Run a focused icon review before a major feature launch, app redesign, or design-system handoff. Schedule a broader audit during regular planning cycles, especially when several teams have added local icons or when product terminology has changed. Revisit the checklist whenever the design tool, component architecture, export pipeline, or target platform requirements change.
Because Figma features, platform guidance, and implementation conventions can evolve, verify the current behavior of your tools and code libraries at least every six months or after a major release. The audit does not need to restart from zero each time. Keep a dated review log with open issues, approved exceptions, deprecated assets, and the owner responsible for each decision.
For the next audit, copy this short action list into your project workspace:
- Set the scope and collect source, exported, and implemented icon files.
- Run a duplicate and naming review.
- Compare size, stroke, grid, variants, and optical alignment.
- Test accessibility behavior in the real interface.
- Approve, revise, deprecate, or replace each asset.
- Update Figma properties, documentation, exports, and migration notes.
- Record the audit date and set the next review trigger.
A consistent process turns an icon collection into a dependable design asset: easier to find, safer to implement, and clearer for every team that uses it.
