Icon Systems & Visual Language

The plain-language idea

An icon set is a visual language, and like any language it needs internal consistency to read as one voice. The dimensions that matter are the same ones a type system cares about, just applied to shapes instead of letterforms: stroke width (how thick the lines are), corner radius (sharp vs. rounded terminals), grid size (the bounding box every icon is drawn inside, usually 16, 20, or 24px), and filled vs. outline style. Two icons can each be individually well-drawn and still visibly clash the moment they sit next to each other with different values on any of these.

The most common way this breaks in practice isn't a designer drawing bad icons — it's a codebase pulling icons from two different libraries. Library A draws on a 24px grid with a 1.5px rounded stroke; library B draws on a 20px grid with a 2px square stroke. Individually, both look fine. Side by side, the product looks like it was assembled from two different apps, because it was.

See it in a real thing: two icons that shouldn't sit next to each other

<TrashIcon strokeWidth={1.5} />   {/* icon-library-a: 24px grid, rounded line caps */}
<DeleteIcon strokeWidth={2} />    {/* icon-library-b: 20px grid, square line caps */}

Nothing here is a bug — both components render valid, readable icons. The problem only shows up visually, once they're placed in the same toolbar: one line is noticeably thinner, one corner is noticeably sharper, and a user's eye registers "inconsistent" before they could ever articulate why. Fixing it isn't a matter of picking a "better" icon — it's picking one icon library (or one internally consistent custom set) for the whole product and never mixing in a second one, the same discipline the type-scale and spacing-scale lessons already argued for.

<button aria-label="Delete item">
  <TrashIcon aria-hidden="true" />
</button>

What people usually miss

Watch out

• Mixing icon libraries is the visual-language version of mixing fonts. Even individually clean icons clash the instant stroke width, corner radius, or grid size differ between them — the fix is one consistent source, not a "better" individual icon.
• A visible tooltip is not an accessible label. It doesn't exist for touch users (no hover), and screen readers don't reliably read title attributes — an icon-only control always needs a real aria-label regardless of whether it also shows a tooltip on hover.
• Filled vs. outline usually encodes meaning, not just style. A common convention is filled = selected/active, outline = unselected — using both inconsistently (a filled bookmark that isn't actually bookmarked) actively misleads instead of just looking sloppy.
• Recognizability beats novelty for high-frequency utility icons. A custom, "on-brand" reinterpretation of save, search, or delete costs every user a moment of re-learning — a bad trade for icons used dozens of times a session. Novelty is a more reasonable trade for icons that are rare, decorative, or themselves part of the brand.
• Icon size should be tuned to the type it sits beside, not just to a fixed pixel value. An icon that's the "correct" 16px next to 24px text still reads as mismatched — icon grid sizes should track the type scale's steps, not exist as an unrelated constant.

Why this matters in interviews

"This app's icons look inconsistent, what would you check" is testing whether a candidate can name concrete, systemic causes — mismatched stroke width, grid size, or two icon libraries in one codebase — instead of a vague "make them match better." The stronger answer also catches the accessibility half of the same question unprompted: an icon-only button needs a real label independent of any tooltip.