Iconography Systems: Consistency Across a Growing Product

We inherited an icon library on a fintech client project that had grown to include icons from four different open-source sets, each with slightly different stroke widths, corner radii, and optical sizes. Individually, none of them looked wrong. Side by side on a settings page, the inconsistency was obvious enough that it made the whole product feel unpolished, even though every other design element was tightly controlled.

Rebuilding from scratch wasn't realistic given the volume — over 200 icons across the product — so we defined a strict construction grid (24x24 base, 2px stroke, consistent corner radius) and rebuilt only the icons that appeared on primary navigation and frequently used actions first, prioritizing by usage frequency rather than trying to fix everything at once. That let us ship visible improvement within two sprints instead of stalling on a six-month full rebuild.

We learned to separate functional icons from decorative ones in the system itself, because they have different rules. Functional icons — used in buttons, nav, status indicators — need to stay legible at 16px and carry consistent meaning across contexts; a trash icon must always mean delete, never 'clear' in one place and 'remove' in another. Decorative icons used in empty states or marketing sections have more stylistic freedom since they're not load-bearing for comprehension.

The naming convention mattered as much as the visual grid. Early on, icons were named by appearance ('arrow-circle', 'gear-outline') rather than function, which meant engineers guessing at which icon to pull for a new feature often picked the wrong one or duplicated an existing icon under a new name. Renaming the library by function ('settings', 'delete', 'expand') and keeping a searchable index cut duplicate icon requests significantly, according to the design system team's own tracking.