Iconography & Symbol Systems

The full lesson

Icons are everywhere in interfaces, yet they are routinely misused. They get deployed as decoration where words would serve better. They end up inconsistent in visual weight between screens. Or they are ambiguous enough that users have to hover just to guess what they mean.

A disciplined icon system is not a collection of images — it is a shared visual vocabulary. It carries meaning, communicates affordances, and scales coherently from a 16px notification badge to a 64px onboarding illustration. Getting it right requires two things: the craft of designing individual icons well, and the systemic thinking that makes a whole set cohere.

Why Icon Systems Matter Beyond Aesthetics

Icons reduce cognitive load when they match established mental models. The floppy-disk save icon has persisted not because it is literally accurate — almost nobody uses floppy disks anymore — but because decades of exposure have made the symbol conventional.

That historical quirk reveals something important: an icon’s value is almost never intrinsic. It comes from shared cultural context, repeated exposure within a product, and — most importantly — clear pairing with a label or tooltip.

A coherent icon system also carries operational weight. Consistent stroke weight, corner radius, and optical sizing mean every icon in a product reads as if it came from the same hand. When a new icon needs to be added six months after launch, a well-documented system makes it trivially reproducible. An ad-hoc set sourced from five different libraries becomes a maintenance burden that compounds with every release.

The Spectrum from Symbol to Illustration

Not all small graphics are icons. It helps to name the points on the spectrum:

Treating all of these as the same design problem leads to icons that are overworked at small sizes (too much detail) or underpowered at large sizes (too flat and generic). Design for the intended size and usage context, not for a hypothetical “universal” rendering.

Core Craft Principles for UI Icons

Optical sizing over geometric consistency

A common mistake is building every icon inside a strict 24×24px bounding box and assuming that geometric equality means visual equality. It does not. A circle and a square with identical bounding boxes appear to be different sizes — the circle looks smaller. Wide horizontal shapes (a minus symbol, a hamburger menu) look lighter than tall narrow shapes (a vertical ellipsis, a lock).

Optical correction means:

• Circles and diamonds are drawn slightly larger than their bounding box so they feel visually equivalent to square shapes.
• Wide icons get slightly more stroke weight than tall icons.
• Complex icons are simplified aggressively — not just pruned slightly. At 16px, detail that reads fine at 48px becomes noise that hurts legibility.

Stroke weight and fill style

Two parameters define an icon system’s character more than anything else: stroke weight and fill style (outline vs. filled). Both should be explicit system decisions.

• Stroke weight: typically 1.5–2px at the design canvas size (1px renders too thin at 1x). Heavier strokes read more confidently at smaller sizes and on lower-DPI displays.
• Fill style: outlined icons carry a lighter, more neutral tone. Filled icons carry more visual weight and communicate confidence. Many systems use outlined for default and filled for active or selected states — giving fill a semantic job, not just a decorative one.

Mixing outline icons from one library with filled icons from another is one of the fastest ways to break visual cohesion. The stroke logic differs, the terminal styles (rounded vs. butt caps) differ, and the optical sizing decisions differ.

Grid and keyline structure

Professional icon sets are drawn on a keyline grid that defines how different shapes relate. The standard approach — used by Material Symbols, Phosphor, and Heroicons — divides the canvas into:

• A square shape keyline (e.g., 18×18 inside a 20×20 canvas)
• A circle keyline (slightly larger than the square to compensate optically)
• A horizontal rectangle and a vertical rectangle keyline

Every icon is drawn so its primary form lands on or near the appropriate keyline. This keeps visual weight consistent across shapes without requiring manual optical correction on every single icon.

Icon Accessibility: Beyond Alt Text

Icon accessibility is one of the most widely misunderstood requirements in WCAG 2.2. The rules depend on how an icon is used.

Icon-only interactive controls — buttons, links, and toggles with no visible text label — must have a programmatic text alternative. In practice this means:

• A visible tooltip on hover and focus
• An aria-label on the button element
• Never alt on an SVG that lives inside a button — screen readers announce the aria-label on the interactive element, not the SVG

Decorative icons paired with a visible text label on the same interactive element should be hidden from the accessibility tree entirely. An SVG inside a labeled button should carry aria-hidden="true" so screen readers do not announce both the icon name and the button label.

Non-text contrast (WCAG 2.2 SC 1.4.11): Interactive UI icons must meet a 3:1 contrast ratio against their surrounding background. This is the legal baseline. Low-contrast icons used to “de-emphasize” secondary actions are not an aesthetic choice — they are a compliance failure.

Icon + label pairing: An icon paired with a text label is almost always more usable than an icon alone. Research consistently shows that recognition rates for abstract icons hover around 70% without labels. A 70% recognition rate means users will mis-tap, mis-interpret, or simply ignore those icons. If screen real estate is genuinely tight, the icon still needs a tooltip accessible via keyboard focus — not just on hover.

Building a Scalable Icon System

Naming conventions

The naming system you choose propagates through your design tool, your token system, and your codebase. Flat namespacing (trash, chevron-right, lock) collapses quickly at scale. A structured prefix system survives:

• Category prefix: nav/home, action/delete, status/error, object/file
• Size suffix: home-16, home-24 — only when size variants are needed
• State suffix: bell, bell-filled — for outline and filled pairs

Avoid naming icons by appearance (circle-x-16) rather than meaning (action/dismiss). Appearance names become misleading when a visual redesign changes the shape but keeps the same semantic role.

Component architecture

In a React or component-based system, icons should be first-class components, not raw image imports. A good icon component:

1. Accepts a size prop that maps to one of a fixed set of canonical sizes (16, 20, 24, 32)
2. Inherits color from currentColor so it responds to CSS color without extra props
3. Accepts an aria-label prop that, when provided, sets role="img" and aria-label on the SVG, and when absent, sets aria-hidden="true"
4. Renders inline SVG (not an img tag) so color inheritance and CSS styling work predictably

Using currentColor for fills and strokes is the single most maintainable decision in an icon system. The icon automatically inherits text color, respects dark mode surface colors, and handles interactive states (hover, disabled) through a single CSS rule on the parent — no icon-specific color props needed.

Token integration

Icons connect to the token system at two points:

• Size tokens: icon.size.sm = 16px, icon.size.md = 20px, icon.size.lg = 24px — consumed by the icon component’s size prop
• Color tokens: icons should reference semantic color tokens through currentColor on the parent, not hardcoded hex values. Tokens like color.icon.default, color.icon.muted, color.icon.interactive, and color.icon.danger give icons the same theme-ability as text

Common Icon Anti-Patterns

Hamburger menus on desktop

On desktop, hamburger menus reduce task completion speed by approximately 39% compared to persistent visible navigation, and cut discoverability roughly in half. An icon that hides navigation is not a neutral space-saving choice — it is a usability penalty paid by every user, every session. On desktop, prefer visible navigation. The hamburger is a reasonable concession on mobile only.

Ambiguous abstract icons without fallbacks

The “three dots” overflow icon, the kebab menu, the settings gear — these have reasonable recognition rates in apps where users have seen them long enough for them to become familiar. In a new product, or an enterprise context where users log in infrequently, these abstract icons need text labels or tooltips. A 70% recognition rate means 30% of users are guessing. At scale, that is a large support burden.

Pixel-perfect icons at non-native sizes

An icon designed for 24px will look soft or misaligned if rendered at 20px or 18px on a whole-pixel display. Either design for the actual rendered size, or use a grid-aware icon library that provides discrete size variants (16px, 20px, 24px) rather than expecting a single SVG to scale cleanly to any size.

Icons as the sole indicator of a destructive action

Delete, archive, and remove actions should never be represented by an icon alone in a surface where users are moving fast. A trash icon alone in a data table row gets tapped accidentally at a high rate. Pair it with a confirmation step, a text label, or at minimum a distinct visual treatment — not just red color — that slows the tap-to-action path.

Maintaining and Evolving an Icon System

A maintained icon system produces compounding returns. A neglected one produces compounding debt. These practices work:

• Single source of truth: all icons live in one Figma file (or equivalent), exported via a pipeline to a versioned package that the codebase imports. Icons never live as one-off SVG files dropped into a feature folder.
• Contribution guidelines: document the keyline grid, stroke weight, corner radius, and export format. When a new engineer adds an icon and there is no documentation, they will make something that “looks close” — close enough to ship, inconsistent enough to erode cohesion.
• Deprecation policy: when an icon is renamed or replaced, the old name should emit a deprecation warning in the component library before it is removed. This prevents silent breakage in consuming apps.
• Accessibility testing: include an automated check for icons used inside interactive elements that lack either aria-label or a visible text label. This is checkable via axe-core and should run in CI.

Quick Reference: Icon Design Decisions