Building an Icon Set That Still Works at 16 Pixels

Icons are the part of a product’s visual language people notice only when they are wrong. A mismatched set — three stroke weights, two corner radii, one glyph that is filled while the rest are outlines — makes a well-engineered product feel unfinished.

Building a consistent set is mostly a matter of deciding the rules once and then holding to them.

Decide the grid and the weight first

Everything else follows from these two.

A grid, usually 24×24, with defined padding so no glyph touches the edge. Every icon is drawn on it. This is what makes icons look the same size even when their shapes differ wildly.

A stroke weight, typically 1.5px or 2px at 24px. One weight across the whole set. The most common failure in a custom set is icons drawn at different times at different weights — it reads as sloppiness even to people who cannot name what is wrong.

A corner radius and a terminal style — rounded or square ends — applied consistently.

Write these down before drawing anything. Retrofitting consistency is far more work than designing to it.

Optical size beats mathematical size

A circle drawn to the same bounding box as a square looks smaller. A horizontal shape at the same width as a vertical one looks bigger.

Icons need optical adjustment: circles slightly overshoot the grid, complex shapes are pulled in a little. If every glyph is mathematically identical in bounding box, the set will look uneven.

The check: line them all up in a row at 24px and squint. Anything that jumps out or recedes needs adjusting.

Design at the smallest size you will use

If icons will appear at 16px, draw and judge them at 16px. Detail that resolves beautifully at 48px turns to mush small, and small is where most icons live.

Practical consequences:

• Two or three elements per glyph, maximum
• No detail thinner than the stroke weight
• Counters — the enclosed gaps — need to stay open enough not to fill in
• Diagonals at awkward angles blur; 45° is safest

Make each glyph mean one thing

The most useful test is the blind label test: show someone a glyph with no context and ask what it means. If a shield reads as “durable”, “secure”, “guaranteed” or “protected” depending on who is looking, it is doing too many jobs.

Common collisions worth checking:

• A target and concentric circles both meaning “goal” and “focus”
• A magnifier meaning both “search” and “zoom”
• A gear meaning both “settings” and “processing”

Pick one meaning per glyph and find a different metaphor for the other.

Export properly

SVG, optimised. Strip the editor metadata, collapse the transforms, and round the path values sensibly. An unoptimised icon export is frequently ten times larger than it needs to be.

Use currentColor for strokes and fills so the icon inherits from CSS rather than needing a variant per colour. This single decision removes an entire category of maintenance.

Consistent naming. Kebab-case, describing the thing rather than the use: arrow-right, not next-button-icon. Uses change; the shape does not.

A single component, not a folder of files. One icon component taking a name prop keeps sizing, stroke and accessibility attributes consistent everywhere and makes the whole set swappable.

Accessibility, briefly

• Decorative icons — the ones beside a visible text label — get aria-hidden="true". Otherwise screen readers announce the same thing twice.
• Meaningful icons — icon-only buttons — need an accessible name on the button, not the SVG.
• Never rely on colour alone to distinguish two icons.

The review that catches everything

Render the whole set on one sheet, three times: at 44px, 22px and 16px, in a single colour on the real background.

Every problem shows up on that sheet. Weight inconsistencies become obvious side by side, glyphs that dissolve at 16px are immediately visible, and two icons that look too similar end up next to each other.

It takes ten minutes to generate and saves the slow drift that otherwise takes a year to notice.

Icon systems, illustration and the rest of the visual layer are what our UI graphics service delivers — organised, exportable and developer-ready.