Iconography in UI Design: A Practical Guide

Icons get added to an interface for two reasons that pull in opposite directions. One is space: a toolbar with twelve labeled buttons doesn't fit, and twelve glyphs do. The other is speed: a symbol you already know is recognized faster than a word you have to read. The first reason solves the designer's problem. The second solves the user's, and it only pays out for symbols the user has already met somewhere else.

That condition is doing more work than most teams give it credit for. Iconography is a language with almost no shared vocabulary, and the part of it that carries meaning is much smaller than the part that carries style. What follows is what a usable icon set costs to build.

Icons are also one of the loudest elements on a screen. A dense icon row competes with everything around it for attention, including the thing you wanted people to notice, which puts iconography squarely inside visual hierarchy.

What iconography means, and where the meaning comes from

Iconography is the system of symbols a product uses to stand for objects, actions, and states. It covers the metaphors chosen, the grid and stroke weight they're drawn on, the level of abstraction, and the rules that keep the whole thing consistent. Two designers can draw the same twenty concepts and produce sets that feel nothing alike.

Comprehension is a memory effect. NN/g puts it plainly in Icon Usability: a user's understanding of an icon is based on previous experience, and because most icons have no standardized meaning, text labels are necessary to reduce the ambiguity. The magnifying glass reads as search because roughly every interface for two decades has used it that way, and for no other reason.

You cannot design a novel icon that is self-explanatory. You can design one that's memorable, distinctive, and easy to relearn. Recognition arrives with repetition.

"Universal" icons are rarer than the icon libraries suggest

The list of icons NN/g identifies as enjoying mostly universal recognition runs to three: home, print, and the magnifying glass for search. Everything past that is contested somewhere.

The save icon is the standard example, and it's usually told as a story about obsolescence. The more useful reading is that the metaphor stopped mattering at all. Nobody decodes the drawing; they've learned the shape. A floppy disk works fine for people who have never seen one, so the skeuomorphic origin of an icon and its current legibility are unrelated facts.

Other common icons fail more quietly:

• The hamburger menu icon. Three lines usually means main navigation, sometimes a list, sometimes filters. NN/g's study of hidden versus visible navigation ran 179 participants through tasks on 6 live sites and found that hiding the main navigation cuts discoverability almost in half, with longer task times and higher perceived difficulty. The penalty runs larger on desktop than on phones. The space argument that justifies hiding navigation applies on phones.
• Heart and star. Tap the heart on an Airbnb listing and it goes into a wishlist you can open later. Tap the heart on an Instagram post and you've sent the author a public signal that saves nothing — Instagram puts saving on a separate bookmark glyph. Same shape, same placement, one of them files things and the other applauds. Between them, heart and star cover favorites, bookmarks, likes, ratings, watchlists, and featured items, and they compete with each other for all of it.
• The three-dot overflow. Its name in Material's own documentation is overflow, which is an honest description of a container defined by exclusion: it holds whatever didn't earn a place in the toolbar. That set differs between products and between screens inside one product, so nobody can predict its contents from the glyph.

These are vocabulary collisions. Redrawing them changes nothing.

Icons need text labels

The recommendation follows from everything above, and it's the change that moves the most for most teams: label the icon unless it's in the small universal set, or unless a label is genuinely impossible to place.

The common objection is space, and usually it's answerable. Labels can sit beneath icons in a bottom tab bar, alongside them in a sidebar, or be set a step smaller than the surrounding body text. Where they truly won't fit, a tooltip on hover and focus is a partial mitigation. It's slow, it demands an interaction to reveal the meaning, and on touch devices it frequently doesn't exist at all.

Labels also fix an alignment problem people don't anticipate. Once an icon has a word attached, that word becomes the name of the thing everywhere: in support docs, in release notes, in the search field, in a user telling a colleague what to click. An unlabeled icon has no agreed-upon name, so nobody can talk about it.

Drawing a set that holds together

Consistency in iconography is mechanical. It's the part that reads as "professional" when it's right and as "assembled from three libraries" when it isn't.

Use one grid. A 24×24 canvas with a padded live area, commonly 20×20, is the usual choice. The grid is what stops a hand-drawn set from wobbling.

Fix the stroke weight, then correct it by eye. This is the rule teams get wrong most often, because the numerically correct answer and the right answer diverge. Set a nominal weight first: 1.5px or 2px on a 24px grid, applied to everything. Then look at the sheet. A glyph with six strokes packed into the live area reads visibly heavier than one with two, at identical stroke width, because the eye is integrating total ink rather than measuring line thickness. The dense ones have to be thinned, or opened up, or simplified until they stop shouting. If the question is which stroke thickness is better, the answer is whichever one matches your type: icons sitting beside a light UI font at a heavy weight look pasted in from somewhere else, and the mismatch is obvious even to people who can't name it.

Keep abstraction level constant. A set mixing flat pictograms with detailed illustrated objects is the tell of a library that grew by accretion.

Draw for the size you'll ship. An icon drawn at 48px and scaled to 16px loses its interior detail and turns to mush. Real systems handle this with distinct optical sizes: Material Symbols ships as a variable font with weight, fill, grade, and optical-size axes, and SF Symbols provides matched weights and scales aligned to the system typeface.

Use fill as a state. Outlined for inactive, filled for active. It gives you a selection signal that survives for users who don't perceive your accent hue.

The three numbers icon accessibility depends on

Three parts of icon accessibility have exact answers. The rest is judgment.

Contrast: 3:1. WCAG 1.4.11 Non-text Contrast requires graphical objects needed to understand content, and the visual indicators of interface components, to reach a contrast ratio of at least 3:1 against what's adjacent. The light-gray icon on white is the standard failure, and it's usually defended as restraint.

Target size: 24×24 CSS pixels. WCAG 2.5.8 Target Size (Minimum), Level AA in WCAG 2.2, sets 24×24 as the floor for pointer targets, with defined exceptions including sufficient spacing between targets and inline targets in a sentence. The AAA criterion asks for 44×44. One distinction trips teams up here: the requirement is on the target, not the glyph. A 16px icon padded out to a 24px hit area passes; a 16px icon in a 16px button does not.

A text alternative, or none at all. Under WCAG 1.1.1 Non-text Content, an icon that carries meaning needs a programmatic name, and an icon that's purely decorative — sitting beside a text label that already says the same thing — needs to be hidden from assistive technology rather than announced twice. Getting this right means knowing which case you're in. The mechanics are in our guide to ARIA labels.

A fourth rule has no number attached: never let an icon carry a state through color alone. Colour vision deficiency affects approximately 1 in 12 men and 1 in 200 women. For those users, a red error icon and a green success icon are the same icon unless the shape changes too.

SVG or icon font

Inline SVG is the default answer now, and the reasoning is about failure modes.

Icon fonts render glyphs as text, so they inherit every risk that applies to text. They break when the font file fails to load. They can be overridden by user or extension stylesheets that force a different typeface — including the accessibility stylesheets some readers depend on. Glyphs mapped into the Unicode private-use area sometimes get announced as garbage by screen readers. When an icon font fails, users get a box or an unrelated character where a control should be.

SVG avoids all three. It's also independently styleable per path, supports multi-color and animation, and can be inlined so a critical icon doesn't need a second network request. The one real advantage icon fonts retained was bundling a large set into a single cacheable file, and an SVG sprite sheet or a build step that inlines only the icons a page uses gets you the same thing.

How to test icons before shipping them

The only way to know whether an icon communicates is to ask people who weren't in the room when it was drawn. NN/g's Usability Testing of Icons splits it into four quality criteria. They fail independently. Passing one tells you nothing about the others:

• Findability — can people locate the icon on the screen at all?
• Recognition — do they understand what it represents?
• Information scent — can they predict what happens when they act on it?
• Attractiveness — is it pleasant to look at?

Recognition is tested out of context: show the glyph alone, without label or surroundings, and ask what it means. It's uncomfortable, and it's the fastest way to find out that your beautifully drawn set is a Rorschach test. Findability has to be tested in the real interface, where similar icons compete and dense areas swallow things. A time-to-locate task with first-click tracking separates "couldn't find it" from "found it and picked the wrong one."

Run recognition tests early, when redrawing is cheap, and findability tests on the assembled interface. Both fit inside a normal usability testing session.

Map iconography is a different discipline

One specialist case deserves its own note, because half the rules above stop applying. Map iconography — pins, category markers, transit and amenity symbols — operates under constraints interface icons don't have. Markers overlap at density. They sit on a background whose color and busyness change as the user pans. They scale with zoom rather than with layout. And they're read peripherally, while attention is on the route.

So map symbols need heavier simplification than UI icons at the same pixel size, they usually need a halo or plate to survive an arbitrary background, and category distinctions have to hold up at a glance in a cluster of twenty. Established map symbol sets exist for exactly this reason, and borrowing one beats inventing a parallel vocabulary for concepts that already have symbols people have seen.

Frequently asked questions

What is iconography in UI design?

The system of symbols an interface uses to represent objects, actions, and states, plus the rules that make those symbols a coherent set. It covers the metaphors chosen, the grid and stroke weight they're drawn on, the sizes they're drawn for, and how they're labeled.

Do icons need text labels?

Nearly always, yes. Outside a short universal set — home, search, print, media controls — icon meaning depends on prior exposure you can't count on. Labels remove the ambiguity and give the control a name that users, support docs, and your own team can all use.

What size should UI icons be?

Common glyph sizes are 16, 20, and 24px, drawn on a 24px grid. The size that matters more is the interactive target around the glyph: WCAG 2.2 sets 24×24 CSS pixels as the AA minimum for pointer targets, and 44×44 as the AAA level. Pad a small icon out to a large target instead of growing the drawing.

What contrast ratio do icons need?

3:1 against the adjacent background, under WCAG 1.4.11, for any icon that conveys meaning or indicates the state of a control. Purely decorative icons that duplicate an adjacent text label are exempt, and they should then also be hidden from screen readers.

Should I use an icon font or SVG?

SVG. Icon fonts fail in ways that leave users staring at a box where a button should be: font load failures, user stylesheets that override the typeface, and private-use-area characters that assistive technology can mangle. SVG sidesteps all three and gives you per-path styling as well.

Is the hamburger menu icon bad?

The icon isn't the problem; hiding the navigation behind it is. NN/g's 179-participant study found discoverability almost halved when main navigation is hidden, with worse task times and higher perceived difficulty, and a larger penalty on desktop, where the space constraint that justified the pattern doesn't apply.

Where this actually goes wrong

Most icon sets in production were reviewed for coherence and never once for comprehension: drawn on a consistent grid, aligned to the brand, judged entirely by people who already knew what every glyph meant. Ugliness was never the issue.

The correction is cheap. Take the icons in your primary navigation and toolbars, strip the labels, and show them to five people who don't work on the product. Twenty minutes tells you which glyphs are carrying meaning and which are carrying only style. The second group is decoration, and decoration is welcome to stay, as long as something else on the screen is doing the actual work of saying what the control does. Choosing what deserves a symbol at all is the ordinary design question covered in our guide to UI design principles and patterns.

Sources: NN/g — Icon Usability · NN/g — Usability Testing of Icons · NN/g — Hamburger Menus and Hidden Navigation Hurt UX Metrics · W3C — WCAG 2.2 Understanding docs · Colour Blind Awareness.