Open any mature product and find the toolbar. There will be somewhere between eight and twenty icons in a row, each one a small abstract glyph, none of them labeled.
Now watch someone use it. They will hover over the icons one at a time, waiting for tooltips, reading the words that the icons were supposed to replace. They are, in effect, using a text menu with an extra step — one that requires a mouse, a pause, and a guess about which glyph to investigate first.
This is the most common failure of icon design, and it isn't a failure of drawing. The icons are usually well-drawn. It's a failure of the assumption underneath them: that a picture communicates faster than a word, to everyone, without instruction. For a small number of icons this is true. For most of the icons in most products, it isn't, and the cost of pretending otherwise is paid by every user who has to hunt.
Three Kinds of Icons, Treated as One
The confusion starts with treating all icons as the same type of thing. They aren't. There are three distinct categories, and they have wildly different comprehension rates.
Genuinely universal icons are the small set that virtually everyone recognizes without instruction: the magnifying glass for search, the house for home, the X for close, the plus for add, the trash can for delete. These have been standardized across enough products for long enough that recognition is close to automatic. There are perhaps a dozen of them. They earn their place, and they can be used alone.
Category conventions are icons that a specific type of user has learned from a specific type of product. The floppy disk for save. The gear for settings. The three-line hamburger for menu. The paper airplane for send. These are widely understood by people who use software regularly, and less reliably understood by everyone else. They work, but they work because of exposure rather than because the picture explains anything — which means they work better for your experienced users than your new ones, and better in some markets and demographics than others.
Invented icons are the ones a product creates for its own concepts. A glyph for "sync," a glyph for "workflow," a glyph for "segment," a glyph for whatever your product does that no other product does. These communicate essentially nothing on first encounter. They cannot, because there is no shared referent — the user has never seen this symbol attached to this meaning before, and no amount of drawing skill creates a convention that doesn't exist yet.
The failure mode is using invented icons as if they were universal ones: putting them in a toolbar, unlabeled, and expecting recognition. The icon isn't bad. It's just being asked to do a job that only a learned symbol can do.
The Skeuomorph Problem
A subset of category-convention icons carry a specific liability: they depict physical objects that a growing share of users have never encountered.
The save icon is a floppy disk. Nobody under thirty has used one. It still works — not because the picture is meaningful, but because the association between that shape and "save" has been learned independently of what the shape depicts. It has become an abstract symbol that happens to look like an obsolete object.
This is fine as long as the learning holds. But it reveals something important about how these icons work: their comprehension comes entirely from convention, not from depiction. Which means the same is true for the telephone handset that represents calling, the newspaper that represents news, the envelope that represents email, the bookmark ribbon, the shopping cart, the film clapperboard. Each of these was once a depiction and is now a symbol, and each one is comprehensible only to people who have learned the association.
The practical implication isn't that these icons should be replaced — replacing established conventions creates more confusion than it solves. It's that if the recognition comes from convention rather than depiction, then the quality of the drawing is close to irrelevant to whether the icon works. Teams spend real design time refining icons whose comprehension is determined entirely by whether the user has seen that association before. The refinement is worth doing for consistency and craft. It does nothing for comprehension.
Icon Plus Label Beats Icon Alone, Almost Always
Usability testing produces a consistent finding across product types: an icon accompanied by a text label is found faster and more accurately than the same icon alone. This holds even for icons the team considers obvious, and it holds even for users who are familiar with the product.
The reason is that the label removes the guessing step. A user scanning a labeled toolbar reads and locates. A user scanning an unlabeled toolbar must recognize, and where recognition fails, must hover, wait, read, and repeat. The label makes the action findable by the word the user is thinking of, which is how people search for things — they think "I want to export this," and they look for "export."
The icon still adds value alongside the label. It gives the eye a distinctive shape to target on repeat visits, which speeds up recognition once the user knows where things are. It creates visual rhythm and makes a list of actions easier to scan than a wall of text. It helps with recall across sessions. These benefits are real and are the actual case for icons — as an accelerant for people who already know, not as an explanation for people who don't.
So the default should be inverted from how most products treat it. Icon plus label is the standard. Icon alone is the exception that has to justify itself.
When Icon-Only Is Defensible
There are legitimate cases for unlabeled icons, and they're narrower than common practice suggests.
The icon is genuinely universal. Search, close, add, delete, home. These are safe alone. The list is short and you should be suspicious of any argument that your particular icon belongs on it.
Space is genuinely constrained. A mobile toolbar with five actions has no room for labels. This is a real constraint and unlabeled icons are the reasonable response — combined with keeping the set small and using the most conventional icons available.
The action is performed constantly by the same people. In a tool used for hours daily, users learn the toolbar quickly and then benefit from the density that unlabeled icons allow. The cost is paid once, during learning, and the benefit accrues over thousands of uses. This is the strongest argument for icon-only interfaces and it applies specifically to professional tools with high-frequency users — not to products people use occasionally.
The icon is redundant with adjacent context. An icon inside a clearly labeled section, or attached to a row whose meaning is already established, is doing decoration and orientation rather than explanation, and doesn't need its own label.
Outside these cases, the icon is probably costing more in findability than it's saving in space.
The Tooltip Is Not a Solution
The standard defense of unlabeled icons is that tooltips explain them. This defense has two problems.
The first is that tooltips require hovering, and hovering requires a pointer. On touch devices — phones, tablets, and increasingly touchscreen laptops — there is no hover state. A tooltip-dependent interface is a desktop-only interface, and if the product has any mobile presence at all, the mobile users get the icons without the explanation.
The second is that a tooltip is a delayed, single-item explanation. To scan a toolbar of twelve icons via tooltips, a user must hover twelve times, waiting for each delay. This is dramatically slower than reading twelve labels at once. The tooltip converts a parallel task — scanning — into a serial one, which is exactly backwards from what the icon was supposed to accomplish.
Tooltips are a useful supplement. They're a reasonable place for additional detail, keyboard shortcut hints, or clarification. They are not a substitute for the label, and treating them as one produces an interface that's slower for everyone and unusable for anyone without a mouse.
The Ambiguity Multiplier
Icons degrade further in the presence of other icons, in ways that a single-icon evaluation misses.
The first failure is collision: two different icons in the same product that plausibly mean the same thing. A downward arrow could be download, or export, or collapse, or sort descending. If a product uses similar glyphs for several of these, users can't distinguish them by shape and have to rely on position — which means the icon is contributing nothing and the position is doing all the work.
The second is inconsistent meaning: the same icon meaning different things in different parts of the product. A three-dot menu that opens different kinds of options depending on context, a star that means "favorite" in one place and "featured" in another, a plus that adds an item here and creates a new document there. Each usage is individually defensible and the combination teaches users that the icons don't reliably mean anything.
The third is visual inconsistency across sets. Products frequently accumulate icons from multiple sources — some from an icon library, some custom, some inherited from a component kit — with different stroke weights, corner radii, optical sizes, and levels of detail. The mismatch is immediately visible even to people who can't articulate it, and it reads as the same carelessness that mismatched typography does.
An icon system is a system: one source or one set of drawing rules, consistent stroke weight, consistent optical sizing, consistent metaphor logic, and a documented meaning for each glyph that's enforced across the product. Products that treat icons as individual assets rather than as a system end up with a collection rather than a language.
You Are Already Writing the Label
There's an argument for labels that has nothing to do with usability testing and that most teams overlook.
An icon-only button is inaccessible without a text alternative. Screen readers cannot interpret a glyph; they announce whatever accessible name the button carries. So every icon-only button in a properly built product already has a label written for it — in an aria-label, in visually hidden text, in the accessibility layer.
Which means the word already exists. Someone already decided what this button is called. The only decision remaining is whether sighted users get to see it or not.
Framed that way, hiding the label is a strange choice. The team has done the work of naming the action, and then deliberately withheld that name from most of their users in exchange for a small amount of horizontal space. Sometimes that trade is worth it. It's worth making consciously rather than by default, and worth noticing that the label wasn't saved by hiding it — it was just concealed.
The Test That Settles It
The argument about whether an icon is clear is unresolvable in a room full of people who built the product. It's trivially resolvable with users.
The first test: show the icon alone, with no surrounding context, and ask what it does. If several people give several different answers, the icon isn't communicating — it's a shape the team has assigned meaning to internally. This test is harsh and fast and tends to end debates.
The second test is more realistic: show a full screen and ask the user to perform a specific action. Watch where they look and how long it takes. This captures how icons actually function, which is in context, alongside other elements, where position and grouping contribute as much as the glyph. An icon that fails the first test but passes the second is doing acceptable work — its meaning is carried by placement, and that's a legitimate way for an interface to communicate.
Both tests take minutes and require no special tooling. The reason they're rarely run is that icons feel like an aesthetic decision rather than a functional one, and aesthetic decisions get resolved by opinion.
The Discipline of Deleting
The conclusion most teams resist is that a lot of icons should simply be removed.
Decorative icons in feature lists, where each bullet gets a little symbol that illustrates nothing. Icons next to text labels in navigation, where the label is already clear and the icon adds visual noise without aiding recognition. Icon systems built because a page looked too plain. In each of these cases the icon is doing ornamental work, and ornamental work has a cost: it competes for attention, it adds visual complexity, and it creates the maintenance burden of keeping a system consistent.
The useful question for any icon in a product is what would be lost if it were deleted. If the answer is "the page would look less designed," that's not a function — that's decoration, and it should be evaluated as decoration, against the cost it imposes. If the answer is "users would find this action more slowly," the icon is earning its place and should stay.
Most products have some of each, and have never separated them. Doing that separation once — auditing every icon against what it actually does — usually results in fewer icons, clearer labels, and an interface that's faster to use than the one that was trying harder to look designed.