How to Manage Icons in Figma and Code

If you have ever shipped a screen and later noticed three different styles of icons on it, you are not alone. One icon is sharp, another is rounded, a third is thicker than the rest. The layout may be fine, colors may be correct, but the UI still feels “off”.

That is what inconsistent iconography does.

In this guide, we will look at how to keep icons consistent between design and development. You will see how to pick an icon library, set it up in Figma, mirror the same choices in code, and handle custom icons without breaking your system. The ideas apply whether you work with Ant Design, Shadcn/UI, or your own design system.

Why consistency in iconography matters

Icons are part of the visual language of your product. They sit next to labels, buttons, inputs, and navigation items. If they change style from screen to screen, the whole interface starts to feel noisy.

Clear, consistent iconography is key to a coherent user experience and helps users navigate without confusion. When every icon shares the same style, users do not have to “re-learn” what each one means on every page.

Inconsistent icons cause problems like:

Mixed signals: outline icons next to filled icons look like they have different importance or states, even when they do not.
Visual clutter: icons with different stroke widths or corner radii pull the eye to the wrong places.
Harder maintenance: designers and developers keep adding “just one more icon” from random sources, and the system slowly loses its structure.

A single, well-defined icon library solves these issues and makes it easy to add new icons without breaking the look and feel.

Choosing an icon library for your design system

Before you import anything into Figma or code, you need to pick the actual icon set.

Here are the main factors to look at.

1. Visual style

Decide what style fits your product:

Outline vs filled
Stroke thickness (for example, 1.5px or 2px at 24×24)
Corner radius (sharp, slightly rounded, fully rounded)
Level of detail (simple geometric shapes vs detailed icons)

You want one “base” style that can scale across your entire product. Use the same line thickness, corner radius, and style for all icons in your system.

2. Coverage

Check whether the library has:

Core UI actions: search, edit, delete, filter, share, download
Navigation icons: home, dashboard, settings, profile
Domain-specific icons: whatever your product needs (finance, SaaS, education, etc.)

You should be able to cover 90% of your product with the base set. Custom icons are fine, but they should be the exception, not the rule.

3. Licensing and format

Look at:

Open source vs paid license
Available formats: SVG, React components, icon font (SVG or React is preferred)
Support for tree-shaking in modern build tools

Popular examples include:

Material Icons (Google)
Lucide (a modern fork of Feather Icons)
Heroicons
Ant Design Icons (the official set for Ant Design)
Other specialized sets, depending on your brand

For example, Ant Design comes with its own icon pack in the Ant Design ecosystem. Shadcn/UI by default uses Lucide icons (a streamlined Feather Icons fork) in code. Many teams pick one of these and build their design system around it.

Setting up your icon library in Figma

Once you choose a library, the next step is to set it up as a proper icon source in Figma.

1. Create a dedicated icons file

Make a separate Figma file called something like Design System – Icons. This file becomes your single source of truth for all icons.

Inside that file:

Create a main page called Icons
Optional: add subpages for different sets (e.g. “System”, “Brand”, “Product area”)

2. Import icons as components

Take the SVG files from your chosen library and bring them into Figma:

Drag and drop the SVGs into the Icons page.
Normalize them to the same frame size (for example, 24×24).
Convert each icon into a Figma component.
Place them into a grid so designers can browse them easily.

Good practice:

Keep all icons aligned to the pixel grid.
Make sure strokes are intact and not converted to outlines unless needed.

3. Use simple, predictable names

Name icons so that both designers and developers understand them:

icon/search
icon/settings
icon/user
icon/arrow-left

Avoid vague names like Icon 123 or Vector 9. Match the naming in code where possible. If the React package uses Search, your Figma component should also be Search.

4. Organize by category

Within your icons page, group related icons:

Navigation
Actions (add, remove, edit, etc.)
Media (play, pause, volume)
Status / feedback (success, error, warning)

You can use Figma sections or frames to keep categories clear. This helps both new designers and developers understand what is available.

5. Standardize size and constraints

Pick a base size (often 24×24) and stick to it. You can also define alternative sizes like 16×16 or 20×20, but keep them in a separate section and still use consistent strokes.

Set auto layout and constraints so icons scale correctly when used in components such as buttons, inputs, and navigation items.

In fact, some design kits go further and ship icons as ready-to-use Figma components tied to the rest of the system. For example, the ShadcnDesign Figma library includes Lucide icons as components, ensuring your design’s icons match the ones developers use in the codebase.

Using icons in code

Now you have a clean icon system in Figma. The next step is to mirror that system in the codebase.

1. Install the matching icon package

Developers should use the same icon library that designers rely on. For example:

Lucide React package if the design uses Lucide
Ant Design Icons package for an Ant Design-based system
Heroicons React package if the design uses Heroicons

This avoids a common anti-pattern: designers using one icon set while developers install a different one because it is “easier” at the moment.

2. Create a shared Icon wrapper

Instead of sprinkling raw icon components everywhere, create a shared wrapper:

import { Mail } from "lucide-react";

type IconProps = {
  size?: number;
  className?: string;
};

export function IconMail({ size = 16, className }: IconProps) {
  return (
    <Mail
      aria-hidden="true"
      className={className}
      width={size}
      height={size}
    />
  );
}

‍

You can also create a generic Icon component that takes a name prop and maps to the right underlying icon. The main goal is to keep sizing and accessibility consistent.

3. Match names between design and code

If Figma uses icon/search, code should also use a Search icon. Keep a simple mapping table or shared documentation so both sides reference icons the same way.

Examples:

Figma: icon/settings
Code: <Settings />
Figma: icon/arrow-left
Code: <ArrowLeft />

This keeps handoff simple. Designers can mention icons by name in specs, and developers can drop in the correct component without guessing.

4. Handling icon updates

When your team decides to change an icon (for example, a new style for “search”):

Update the icon component in the Figma icons file.
Update the same icon in the code library, or bump the icon package version.
Communicate the change in your design system changelog.
Run through a quick visual check in key screens.

The key idea is to update design and code at the same time. Do not let one side drift for weeks; that is how inconsistencies sneak back in.

Custom icons and theming

Even with a strong base library, you will sometimes need custom icons or brand-specific styling.

1. Designing custom icons in Figma

When you design a new icon:

Use the same grid (for example, 24×24)
Match the stroke width (for example, 1.5px)
Match the corner radius and visual language
Keep similar levels of detail as the rest of the set

Treat custom icons as “extensions” of the base library, not a new style. Add them to the same icons file, with the same naming pattern.

2. Theming icons with color and backgrounds

If your product has light and dark themes, define icon color tokens and apply them through your design tokens and code:

icon.default
icon.muted
icon.on-primary

In Figma, attach icon fills to color styles. In code, use CSS variables or a theme system to style the icons.

If you need icons with a background shape (for example, circular badges), create a separate variant in Figma and a styled wrapper in code. Keep the base icon unchanged, and layer the background behind it.

3. Overriding icons in code

For special cases (like showing a different icon on a specific plan or feature), keep the override local rather than replacing the icon everywhere.

Example pattern:

import { Check, Star } from "lucide-react";

export function PlanFeature({ isPremium }: { isPremium: boolean }) {
  const Icon = isPremium ? Star : Check;

  return (
    <div className="flex items-center gap-2">
      <Icon aria-hidden="true" className="h-4 w-4" />
      <span>Unlimited projects</span>
    </div>
  );
}

The global design system still uses the standard Check icon, but one component can show a Star where it makes sense.

A simple workflow for teams

To keep icon usage clean and consistent, you can follow this simple loop:

Choose one icon library for your product, based on style, coverage, and licensing.
Set up a dedicated icons file in Figma, with all icons as components, categories, and clear names.
Install the matching icon package in code, and create a small wrapper or mapping system.
Align naming between design and code, so everyone talks about icons the same way.
Document a process for new icons and updates, and always change design and code together.

If you are working with UI libraries like Ant Design or Shadcn/UI, this workflow fits in nicely. For example, Ant Design Icons can be imported into Figma and treated as your system icons. Shadcn-based projects can use a Figma kit that already includes Lucide icons as components, so designers and developers stay aligned from day one.

When your icon system is set up this way, adding a new feature is simple: you pick an icon from the same library, drop it into Figma, and use the same one in code. No surprises, no mismatch, just a clear visual language across your product.