Why Icon Kits Matter in a Design System
Icons are the highest-frequency component in most UI systems. Navigation, actions, status indicators, empty states — icons appear everywhere, and every one is a decision. Without a structured icon kit, those decisions compound: a slightly different stroke weight here, a mismatched visual weight there, and within a week your interface looks like it was assembled from five different sources.
A well-built icon kit solves three problems simultaneously: consistency (every icon shares the same visual rules), swap speed (swapping one icon for another is a two-second operation, not a search-and-replace), and variant control (filled, outlined, and colored states are all organized and accessible from one component).
In a design system context, an icon kit isn't a set of files — it's a library of components your entire team can publish, subscribe to, and update from a single source of truth. When the icon changes in the library, it updates everywhere it's been placed.
Building Your Own: Frame Naming, Component Sets, the 4-Sizes Rule, and Stroke vs Fill
If you're building your own icon kit in Figma, start with four decisions before you draw a single icon.
Frame naming conventions — every icon frame should follow a consistent naming pattern: Icon/Category/Name (e.g., Icon/Navigation/Arrow-Right). This naming structure creates the auto-organized component panel that makes icons discoverable without searching.
Component sets — use Figma's component properties (boolean, variant) to organize filled vs outlined states within a single component. Designers can switch states in the properties panel rather than hunting for a second component. One component with states is always better than two separate components.
The 4-sizes rule — design icons at four standard sizes: 16px, 20px, 24px, and 32px. Each size is a separate variant, not a scaled version. Icons scaled from 24px to 16px lose precision; icons drawn natively at each size retain optical weight. Most design systems only need 16px and 24px in practice, but having all four sizes future-proofs the kit.
Stroke vs fill — choose one and apply it consistently across every icon in the set. Mixing stroke-based and fill-based icons in the same kit creates visual inconsistency that's nearly impossible to resolve without rebuilding half the set. Most modern design systems use a 1.5px or 2px consistent stroke weight; older systems use solid fills. Neither is wrong; inconsistency is.
How to Use Icon Components Inside Your UI Kit
The master → instance workflow is the core pattern. Every icon you use in a design is an instance of a master component from the library. You never copy a raw icon frame — you insert an instance of the component, then override properties (size, color, state) locally.
In practice: open the Assets panel (Shift+I), search for the icon by name, drag it into your frame. It arrives as a component instance. Select it and use the Design panel to swap to a different icon (Swap component button), or use the component properties panel to toggle between filled and outlined states. If your icon library is published as a team library, the swap works across any file in the workspace.
Color overrides work through fill or stroke on the instance — you don't detach from the component to recolor an icon. Set the fill or stroke color directly on the instance using your color styles. The instance stays linked to the master component, so if the icon is updated, your instance picks up the update automatically.
Common Mistakes: Inconsistent Stroke Width, Missing Touch Targets, No Dark Mode Variants
Inconsistent stroke width is the most common quality issue in designer-built icon kits. Three icons with 1px stroke, two with 2px, and one with 1.5px — individually unnoticeable, collectively visible. Set a stroke width rule on day one (2px is the standard; 1.5px works for dense UIs) and audit every icon against it before publishing the kit.
Missing touch targets are a mobile design failure mode. A 16px icon as a tappable element needs a minimum 44×44px touch target wrapper, not a 16px frame. Build touch target padding into the component using an invisible rectangle behind the icon at the larger size. Without it, your icon components look clean in the file and create accessibility failures in production.
No dark mode variants is the most common omission in icon kits used across light and dark interfaces. If your icons use fills rather than strokes, a filled dark icon will disappear on a dark background. Build color styles into your component system — one style for light mode, one for dark — and apply them as semantic tokens rather than hardcoded colors.
Why Buying a Complete UI Kit Saves More Time Than Building Icon Sets Alone
Building a professional icon kit from scratch is a multi-week project. You need to design 100+ icons at consistent optical weights, build the component structure, create the variant properties, test across sizes, and publish the library. Most designers who start this project finish about 40 icons and abandon it.
A pre-built icon kit inside a comprehensive UI system solves the problem at a higher level. The icons are already drawn, organized, and structured as components — but they exist alongside button components, form elements, navigation patterns, and color systems that all share the same visual language.
The Figma UI Component Kit includes a complete icon library as part of a full UI system — icons, buttons, forms, and layout components that all belong to the same design language. The Figma Pro Design System extends this with design tokens, responsive grid structures, and documentation components. Both ship ready to publish as Figma team libraries.
The math is simple: the hours required to build what's in either kit from scratch would cost more than the kit itself, even at junior designer rates. Buy the foundation. Build the product on top of it.