Skip to content
Favas
← All writing

· Engineering · 3 min read

Why every icon strategy fails

By

One lobe per minute of reading. The dot marks the day it was written.

We spend weeks debating icon libraries, then end up six months later with a Frankenstein's monster of inline SVGs, legacy font icons and random PNGs.

I've watched this happen more than once. It starts with good intentions and a very optimistic kickoff meeting:

"We need a unified visual language. We'll pick one icon library and stick to it."

Two quarters later, open the DOM and you'll find layers, like an archaeological dig:

  • Lucide icons in the newer React components
  • Font Awesome 4.7 hanging on in the legacy dashboard
  • Feather icons, because someone preferred the line weight
  • SVGs copied from the internet and pasted straight into JSX
  • A few blurry PNGs left over from the first marketing site

It's not a technical problem

It's tempting to treat this as a technical problem. We debate SVG sprites versus component libraries. We build clever pipelines to bundle icons. We optimize delivery.

None of that touches the real issue, which is people meeting friction. The decay runs on a schedule.

In week 1 the team agrees on a library. By week 3 a screen needs an icon the library doesn't have, and one custom SVG goes in as an exception. In week 5 someone can't change the stroke width through the component API, so a one-off SVG ships to meet a deadline. In week 8 a new set arrives for the navigation, each icon a slightly different size. By week 12 the legacy dashboard still uses Font Awesome, and nobody has time to touch it.

Systems don't maintain themselves

Icon consistency fails because we treat it as a one-time decision instead of ongoing maintenance. We install the library and assume it will police itself.

It won't. If the approved path needs a Jira ticket and two days of discussion, people take the shortcut.

After a few rounds of this, I've found one approach that holds up. Make the right choice the easy choice: if importing an approved icon takes three seconds and pasting a random SVG takes four, the system holds. Plan for exceptions, because you will need custom icons, and a documented way to add them to the main library beats letting stray files pile up. Give the system an owner, since a system without a gatekeeper is a suggestion, and someone needs the authority, and the nerve, to block a pull request over an icon. Audit it with a recurring check on the calendar and delete the orphans; tooling helps, but someone still has to look. And write down the boring rules: when to use which icon, how to ask for a new one, who decides.

The icon systems that last are rarely the prettiest. They're the ones with the least friction.

A mediocre system people actually follow beats a perfect one nobody respects.