Iconography

For a long time icons were drawn one at a time, whenever a screen happened to need one. Someone building the settings page drew a gear. A few days later someone building a different page drew another gear. The two looked similar, but one used a 1.5-pixel stroke and the other a 2-pixel stroke, one had rounded corners and the other sharp ones. Nobody noticed inside a single screen. The moment the two sat in the same row, the screen looked sloppy.

Meaning drifted too, and that caused more trouble than style. If one screen marks "save" with a floppy disk and another marks it with a downward arrow, people read the two buttons as two different actions and hesitate before clicking either.

Fixing it was hard because nobody could argue from anything except taste. "Mine looks better" is not a reason, so the discussion went in circles and whatever got decided fell apart on the next screen. Iconography is the answer to that: treat an icon not as a drawing but as a set of rules a drawing has to obey.

You decide the values every icon must share before drawing anything, then hold each new icon to those values. Five decisions cover most of it.

1. Grid and size — fix the box an icon is drawn inside, commonly 24 pixels. Inside it, let the artwork occupy about 20 pixels and leave the outer 2 pixels empty. Without that margin, a wide icon looks noticeably larger than a tall one sitting next to it.
2. Stroke weight — if the answer is 1.5 pixels, then all thirty icons are 1.5 pixels. Mixed weights make icons in the same row look different in density, and people read the darker one as the more important button.
3. Corners and line ends — decide whether a stroke ends flat or rounded, and how much to round an interior corner. This matches the corner radius, the amount by which a shape's corners are rounded, that the product's buttons and cards already use.
4. Fill style — outlined or solid. If you use both, write down the rule for switching between them. The common pattern is outlined by default, with the one currently open menu item switching to solid.
5. Meaning-to-shape pairs — one action gets one drawing, and one drawing never covers two actions. Keep that pairing in a list. Once a set passes thirty icons, an unlisted pair quietly turns into the same shape carrying two meanings.

Written values don't enforce themselves, so a finished icon set ships as a part of the design system — the documents and code that hold a product's colors, type sizes, and reusable parts to one standard. Designers pull an icon from the shared file and engineers pull it from code under the same name, and correcting one drawing corrects every screen that uses it.

The last rule is about words. Icons whose meaning isn't obvious get a short label beside or beneath them. Fall back to a tooltip on hover only when there is genuinely no room for the label.

Icons collect in the places where long text doesn't fit: the top toolbar, the left navigation, the end of each row in a list. Anywhere the width is fixed and one action has to live inside 24 pixels, an icon is doing the work.

They also sort things at a glance. In a document list, a small mark in front of each row separating spreadsheets from text documents lets someone scan the column without reading the titles. The dot on an unread notification and the padlock on a restricted file belong to the same category — state, shown as a shape.

An empty state, the screen shown when there is nothing to display yet, uses icons differently. There the drawing isn't a button; it softens a blank page. When that drawing grows large, it stops being an icon and becomes an illustration.

Every one of those placements carries an accessibility obligation. Software that reads a screen aloud cannot read a picture, so an icon-only button needs a name that exists for the screen reader without appearing on screen. Without one, the control is announced as "button" and the person pressing it has no idea what will happen.

"Where did this icon come from? It's not in our set."

Meaning the drawing came from outside the rules, so its stroke weight or size will be off from everything around it.

"Share and export are using the same arrow."

One shape is carrying two actions, and one of them needs a different drawing.

"If the meaning isn't landing, let's put a label under it."

A judgment that not many people will identify the function from the drawing alone.

When Pagedeck rebuilt its document list, Noa redrew twenty-six icons as a single set. The work didn't start with drawing. She collected every icon already in the product and wrote down which action each one was attached to. The same trash can turned out to exist in three shapes, and a single arrow was doing duty for share, export, and move.

Noa split the overlapping meanings first, then redrew everything else on one grid. Theo bundled the result so it could be pulled from code by name. Since then, anyone who needs an icon for a new screen checks the list first, and anything genuinely missing gets drawn under the same conditions: a 24-pixel grid and a 1.5-pixel stroke.

The most common belief is that an icon reads faster than a word. A picture does catch the eye before text does, so the assumption is easy to make. But catching the eye and conveying meaning are separate things. Outside a handful of shapes that have meant the same thing for decades — a magnifying glass, a house — far fewer people correctly guess what an unfamiliar icon does than teams expect. Strip the labels off a toolbar and users work out the meanings by pressing buttons one by one, and support hears about it when the one they pressed was delete.

The other common assumption is that buying an icon set ends the problem. A finished set does make the first few months easier. But no purchased set covers a feature that only your product has, so eventually someone draws that one icon in-house. If nobody recorded which grid and which stroke weight the purchased set was built on, that single icon will stand out. Buying a set doesn't remove the need to write the rules down on your side.