This guide walks you through a complete Figma component audit from setup to sign-off. Following all six steps takes roughly three to four hours for a mid-sized library of 100 to 300 components. You will end with a documented, deduplicated component set that your developers can trust and your designers can actually use.

What You'll Build

  • A structured audit spreadsheet that maps every component to its usage, owner, and status
  • A standardised naming convention applied consistently across your Figma library
  • A clear deprecation and merge plan for duplicate or orphaned components
  • A live coverage report so stakeholders can track design system health over time

Prerequisites

  • Figma Professional or Organisation plan (required for branch and library management features, as of 2026)
  • Editor access to the target Figma file
  • A spreadsheet tool such as Google Sheets or Notion database
  • At least one developer or design lead available for a 30-minute review call at the end
  • The Figma plugin Similayer (free) and Component Utilities (free) installed

Step 1: Export a Full Component Inventory

Before you fix anything, you need to see everything. Open your main design system Figma file and run the Component Utilities plugin. Select "Export all components" and choose CSV as the output format. This gives you a flat list of every component, its page location, and its variant count.

Import that CSV into Google Sheets. Add four columns to the right: Status, Owner, Duplicate Of, and Priority. Leave them blank for now. You will fill them in across the next steps.

What if the plugin fails to export?

Component Utilities occasionally times out on files with more than 500 frames. If that happens, duplicate your file, delete all non-component pages, and re-run the export on the stripped copy. Merge the results back manually.

Common pitfall: Do not export from a branch. Always run the audit against the main file. Branches can have local overrides that skew your count.

Step 2: Identify Duplicates and Ghost Components

Duplicate components are the biggest source of design system debt. They usually appear when designers create one-off variations rather than extending an existing component with properties.

In Figma, open the Assets panel and switch to the List view. Sort by name. Scan for near-identical names such as Button/Primary and Button / Primary (note the spaces). These are two separate components in Figma's eyes.

Next, use the Similayer plugin. Select any component on the canvas, run Similayer, and set the similarity threshold to 85%. It highlights layers with nearly identical structure. Flag anything it finds in your spreadsheet under Duplicate Of.

Ghost components are a second problem. These are components that exist in the file but are never used in any published design. Set the Status column to Ghost for any component that has zero instances in your product screens. You will deal with them in Step 5.

How do you find usage counts without a paid tool?

In Figma, right-click any component in the Assets panel and choose "Find all instances". It highlights every instance across the open file. For cross-file usage, you need the Figma Organisation plan or the third-party tool Zeplin (2026 version supports cross-file analytics natively).

Step 3: Apply a Consistent Naming Convention

Inconsistent naming is the second biggest audit finding. The current industry standard, confirmed by the Figma community design system guidelines updated in early 2026, uses a three-level hierarchy:

[Category]/[Component]/[Variant]

Examples:
  Forms/Input/Default
  Forms/Input/Error
  Navigation/Tab Bar/Active
  Feedback/Toast/Success

Work through your spreadsheet. For every component, write the correct name in a new Proposed Name column. Do not rename anything in Figma yet. Renaming components breaks any published library links until subscribers accept the update. You rename in batch during Step 4.

Pro tip: Prefix internal or work-in-progress components with an underscore, for example _WIP/Button/Experiment. Figma sorts underscored names to the bottom of the Assets panel, keeping your published library clean.

Should you use PascalCase or kebab-case for component names?

Use PascalCase for display names inside Figma. Your design tokens pipeline, such as the Figma-to-Tailwind setup described in the Style Dictionary documentation, handles the conversion to kebab-case automatically during export. Keeping the two environments in sync this way reduces manual errors.

Step 4: Batch Rename and Restructure

With your proposed names confirmed in the spreadsheet, it is time to apply them in Figma. Batch renaming manually is slow and error-prone. Use the Rename It plugin (free, updated for Figma variables in 2026) to apply your naming convention in bulk.

Here is the general workflow:

  1. Select all components in a single category page using Cmd+A (Mac) or Ctrl+A (Windows).
  2. Open Rename It and use the Find/Replace mode to correct prefixes first, for example replacing btn with Button.
  3. Then apply the three-level hierarchy using Rename It's path builder.
  4. Publish the library update when the page is done. Do not wait until all pages are complete. Smaller updates are easier for your team to accept.

Common pitfall: If you move a component to a different page as part of the restructure, Figma treats it as a new component. All existing instances break. Move components only as a last resort. Rename in place whenever possible.

Step 5: Deprecate, Merge, or Delete

Return to your spreadsheet. You now have three groups to process:

  • Duplicates: Choose the canonical version. Update all instances to point to the canonical component using Figma's "Swap instance" feature. Then delete the duplicate.
  • Ghost components: If a ghost has been untouched for more than 90 days, delete it. If it is newer, mark it Deprecated and leave it for one sprint cycle before deleting. This gives any designer using a local copy time to notice.
  • Orphaned variants: These are variants inside a component set that no design screen ever uses. Remove them from the variant set. Fewer variants mean faster library loads. Teams at Atlassian reported a 30% reduction in Figma file load times after removing unused variants in their 2025 design system audit.

When should you keep a component even if it has no current usage?

Keep it if a product roadmap item in the next two quarters explicitly requires it. Otherwise, delete it. A design system is a product, and unused code is technical debt regardless of whether it lives in a repo or a Figma file.

If you are unsure whether your component library is causing UX inconsistencies in your product, a quick brand health score assessment can surface alignment gaps between your design system and how your brand is perceived externally.

Step 6: Build a Coverage Report and Ownership Model

An audit is only useful if it prevents the same problems from recurring. Build a lightweight coverage report so your team can track design system health over time.

In Google Sheets, add a summary tab with these five metrics:

  • Total components: Count of all published components
  • Coverage rate: Percentage of product screens built exclusively from library components (target: above 80%)
  • Orphan rate: Percentage of components with zero instances (target: below 5%)
  • Naming compliance: Percentage of components following the three-level hierarchy (target: 100%)
  • Last audit date: Simple date field. Schedule the next audit for 90 days out.

Assign an owner to each component category. In smaller teams, one designer can own multiple categories. In larger organisations, ownership should map to product squad boundaries. Document this in your Zeroheight or Storybook documentation site so developers know who to contact when a component behaves unexpectedly.

How often should you run a full component audit?

Run a full audit every quarter for teams shipping weekly. For teams with slower release cycles, every six months is sufficient. Between full audits, add a five-minute component hygiene check to your sprint retrospective. Ask: did anyone create a new component outside the system this sprint, and if so, why?

Pro tip: Set up a Figma branch called audit/q4-2026 before you start any destructive changes such as deleting ghost components. If something breaks in production screens, you can compare against the branch to identify the source. Teams at mid-sized SaaS companies in Australia and Singapore have adopted this branch-based audit approach to reduce rollback incidents by roughly 40%.

Frequently Asked Questions

How long does a Figma component audit take for a large library?

A library with 300 to 600 components typically takes two full working days for one designer. Breaking it into category-by-category sessions over a week is more sustainable than trying to do it all at once.

Does renaming components in Figma break developer handoff in tools like Zeplin or Storybook?

Yes, if developers have mapped Figma component names to Storybook story names manually. Coordinate with your development team before publishing renamed components. If your team uses the Figma-to-Storybook connector plugin, update the mapping config at the same time as the rename.

What is the difference between a ghost component and a detached component?

A ghost component still exists in the library but has no instances anywhere. A detached component is the opposite: it was once a library instance but a designer right-clicked and chose "Detach from component," so the library no longer controls it. Detached components do not show up in your audit export. Use Figma's "Find detached instances" search to locate them separately.

Should I audit a Figma file that is still actively used by a design team?

Yes, but use a Figma branch for any destructive steps. Inform the team before you publish changes, and set a two-day window where no new work is pushed to main. This prevents conflicts between your audit branch and in-progress design work.

How is this different from just cleaning up a Figma file manually?

A manual cleanup is reactive and undocumented. This audit workflow produces a spreadsheet record of every decision, an ownership model, and a repeatable process your team can run without you. That documentation is what turns a one-time cleanup into an ongoing design system practice.

Next Steps

Once your audit is complete, connect your component library to a tokens pipeline. The design tokens move from Figma through Style Dictionary into your front-end codebase, so a naming change in Figma automatically updates your CSS variables. That connection is what makes a design system genuinely scalable rather than just tidy.

If your team is working through a broader design system project or preparing for a product redesign, the team at Lenka Studio runs structured design system audits and handoff processes for product teams in Australia, Singapore, Canada, and the US. Get in touch if you want a second set of eyes on your component library or need help building the governance model alongside it.