Open any product that has shipped for three years straight and look closely at the icons. A trash can with rounded corners sits next to one with square corners. Some arrows have a two pixel stroke, others have three. One team imported an icon font in 2023, another dropped in raw SVGs from a Figma community file last quarter, and a contractor added a custom hamburger menu icon that nobody else's icons look anything like. None of this was a single bad decision. It was a hundred small, reasonable ones made without a shared system to check them against.
Icon systems rot faster than color palettes or typography scales because icons get added constantly, by whoever is closest to the ticket, usually under time pressure. This guide covers how to pick a format that will not fight you later, set a sizing and naming convention that holds up as the set grows past a few dozen icons, handle color and accessibility correctly, and put light governance in place so the system does not quietly fall apart six months after launch.
Photo by Lex Photography on Pexels
Why icon systems decay faster than the rest of the design system
A color palette has maybe a dozen values. A type scale has six or seven sizes. An icon system, by contrast, can grow to hundreds of individual assets, each one added by a different person solving a different immediate problem. Nobody sits down to redesign the icon set the way they might revisit a color palette during a rebrand. Icons accumulate one ticket at a time, and each addition is small enough that skipping the convention feels harmless in the moment.
The other reason icon systems decay is that they are genuinely easy to source from outside the product. A developer needs a "settings" icon, searches an icon pack, finds one that looks fine, and drops it in. That one icon was designed by someone with different stroke-width and corner-radius conventions than the rest of the set, and now the product has two visual languages sitting side by side. The fix is not more discipline from individual contributors. It is a system specific enough that grabbing a random icon from the internet is visibly the wrong move.
Decide the format before you pick a library
Before browsing icon libraries, settle the technical format, because switching later means touching every screen that renders an icon. The three common options are icon fonts, SVG sprites, and individual inline SVG components.
Icon fonts were popular for years because a single font file could ship hundreds of icons cheaply, but they carry a real accessibility cost. Screen readers frequently announce icon font glyphs as garbled Unicode private-use characters unless every instance is wrapped with careful aria-hidden and label markup, and that discipline rarely survives contact with a growing team. The W3C Web Accessibility Initiative covers why non-text content needs a reliable text alternative, and an icon font makes that alternative easy to forget.
SVG sprites and inline SVG components solve the accessibility problem more directly, since each icon is markup you control, not a font glyph standing in for one. Inline components are the more common choice for modern component-based frontends because each icon can carry its own role and aria-label attributes and gets tree-shaken out of the bundle if a page never uses it. The MDN documentation on SVG and accessible markup is worth reading in full before locking in a format, since the right choice depends on how much control your build pipeline gives you over inlining versus sprite generation.
Set a sizing and naming convention early
Every icon in the set should sit on the same pixel grid, typically 24x24 with a small internal padding so strokes do not touch the edge of the frame. A shared grid is what makes icons from different contributors line up visually even before anyone checks the style guide, because the geometry itself enforces consistency that a written rule alone will not.
Naming matters just as much as geometry. A convention like icon-{category}-{name}-{variant}, for example icon-nav-search-outline, gives every contributor an unambiguous slot to fill instead of a blank naming decision to make from scratch. Loose naming is how a product ends up with icon-trash, icon-delete, and icon-remove all pointing at three slightly different bin shapes, because three different people solved what they each thought was a new problem.
Photo by Polina Zimmerman on Pexels
Color and state need a non-color signal too
Icons frequently carry meaning through color alone, a red icon for "error," a green one for "success," and that pattern fails for the roughly one in twelve men with some form of color vision deficiency. The fix is not to drop color, it is to pair it with a shape or position difference, a filled versus outlined state, a checkmark next to the green icon, an exclamation mark inside the red one. Running the palette through a contrast checker against your actual background colors, not just the design file's white canvas, catches a surprising number of icons that look fine in Figma and disappear on a real screen.
State changes deserve the same rigor. A toggle icon that only changes color between "on" and "off" is functionally invisible to a meaningful share of users, while the same toggle with a filled-versus-outline change communicates state to everyone regardless of how they perceive color.
Photo by Viktorya Sergeeva š« on Pexels
Document the system where both designers and engineers will actually see it
An icon system that lives only in a Figma file gets ignored by whoever is writing code that day, and one that lives only in a component library gets ignored by whoever is designing a new screen in Figma. Both halves of the team need a shared, browsable reference, whether that is a synced Figma library with matching component names or a small internal site that renders every icon next to its name and usage guidance.
The specific tool matters less than the habit of checking it before adding anything new. A README buried three folders deep in a repository does not get checked. A component library page that shows up in the same tool designers already open every day does.
"Every icon system we've inherited from a client had the same origin story. Someone needed one icon fast, grabbed it from wherever was convenient, and nobody circled back to reconcile it with the rest. The fix isn't a bigger icon library, it's a five-minute checklist someone actually has to run before a new icon ships." - Dennis Traina, founder of 137Foundry
Buying a library versus building your own
Full custom icon sets make sense for products where the icon style is part of the brand, but most teams are better served starting from an established library and customizing only what needs it. Font Awesome and The Noun Project both cover the common cases, navigation, actions, status, well enough that hand-drawing them from scratch is wasted effort. Google's Material Symbols set is a solid default for teams that want a large, consistently drawn base library to start from and diverge from selectively as the product's visual identity matures.
The trap to avoid is mixing libraries without normalizing them first. Dropping icons from two different sets into the same interface, each with its own stroke width and corner radius, recreates the exact inconsistency a system was supposed to prevent, even though every individual icon came from a professionally designed source.
Governance: who signs off on a new icon
Once the format, grid, and naming convention exist, the last piece is a lightweight approval step. It does not need to be a formal review board. It needs one question asked before a new icon merges: does an equivalent already exist in the system? Most duplicate or off-style icons happen because nobody checked, not because the existing icon was actually wrong for the job.
A short checklist works better than a meeting. Confirm the new icon sits on the shared grid, follows the naming convention, includes accessible markup, and was checked against the existing set for a near-duplicate before it ships. Attaching that checklist to the pull request template, rather than a wiki page nobody opens, is usually the difference between a rule that holds and one that quietly stops mattering within a month.
Photo by Tima Miroshnichenko on Pexels
Keeping the system alive past launch
An icon system is never really finished, because the product keeps adding features that need new icons. What separates a system that stays coherent for years from one that decays within a quarter is not the initial quality of the first fifty icons, it is whether the format, grid, naming convention, and lightweight review step survive contact with the next hundred additions made by people who were not in the room when the system was designed.
If your team is weighing whether to build this internally or bring in outside help to set the format and governance up correctly the first time, 137Foundry works with product teams on exactly this kind of design system work. The services page covers our broader web design and development engagements, the about page has more on how we approach a project like this, and our web development service page goes into the implementation side in more detail. Whichever route a team takes, the earlier the grid and naming convention exist, the cheaper the eventual cleanup turns out to be.
