The hamburger is not the problem
Arguments about menu icons often collapse into a verdict on three horizontal lines. The hamburger is called universal, lazy, clean, obscure, or inevitable. None of those labels is useful without context. The symbol can be entirely appropriate and still produce a bad navigation experience because an icon never acts alone.
Meaning comes from a system: where the icon sits, what surrounds it, whether a label is present, what opens after activation, how that surface behaves, and whether the same action works consistently across the product. Treating the glyph as an isolated design object is like reviewing punctuation without reading the sentence.
The practical question is not “is this a good icon?” It is “what promise does this control make, and does the interface keep it?”
Icons are compressed verbs
Most interface icons are not pictures of things. They are instructions: go back, save this, reveal navigation, move, share, filter, search. Even a noun-like symbol such as a heart usually means an action or state: mark as favorite, remove from favorites, or show that somebody liked this.
That makes icon design a problem of grammar. The shape is the verb, placement supplies context, motion expresses the transition, and state shows whether the action has already happened. If any part contradicts another, the control becomes ambiguous.
A magnifying glass in a header can mean search. The same shape over an image may mean zoom. Put it beside a plus and it may mean zoom in. Familiarity helps, but context finishes the sentence.
An icon does not save space if the user spends that space in hesitation.
Recognition is earned by systems
Designers sometimes invoke universality as if every user arrives with the same symbol vocabulary. In practice, people learn icons through repeated encounters with operating systems, browsers, applications, and physical objects. That knowledge is powerful but uneven. It also changes.
Apple’s guidance emphasizes recognizable forms, simplicity, and visual consistency across an icon family. Those are not stylistic preferences. Consistent weight, perspective, detail, and size help a user classify controls before reading each one. The family teaches the grammar.
Custom icons therefore carry a tax. They can express a product’s identity, but each unfamiliar form asks the user to stop and decode. The tax may be worth paying for a central concept. It is rarely worth paying for routine navigation.
Labels are not an admission of failure
A text label is often removed in the name of visual cleanliness. The screen becomes quieter for the designer and less certain for the user. This is a bad trade when the destination is important, the action is infrequent, or the symbol has plausible alternatives.
The right standard is not icon-only versus icon-plus-label. It is decision speed. If a label turns hesitation into recognition, it is doing product work. A compact word such as Menu, Filters, Archive, or Share can cost fewer pixels than the downstream confusion created by a mysterious glyph.
Navigation is especially sensitive because its purpose is orientation. An unlabeled control that hides the information architecture may save visible space while increasing cognitive distance from every destination inside it.
State is part of the drawing
A control has more than one visual job. It must look actionable before activation, communicate focus to keyboard users, acknowledge press or tap, and make persistent state legible when the result remains active. Drawing the resting glyph is only the beginning.
Consider a bookmark. An outline may invite saving, while a filled shape may indicate saved state. If color alone carries that difference, some users will miss it. If the fill changes but the accessible name remains “bookmark,” screen-reader users receive no state. If tapping again removes the item without warning, the control’s grammar changes from a command into a toggle without sufficient explanation.
Good icon work includes labels, focus treatment, pressed state, accessible names, and undo behavior. The asset file is the smallest part of the design.
Touch size and visual size are different
A delicate 18-pixel icon can sit inside a generous interactive area. A large-looking symbol can still be difficult to activate if its actual hit target is tight. Conflating visual scale with target scale produces either clumsy drawings or inaccessible controls.
WCAG 2.2 includes a target-size criterion because precision cannot be assumed. A menu icon should be easy to hit with a thumb, discover with a pointer, reach by keyboard, and distinguish at zoom. The invisible geometry around it is part of the product experience.
This is also why spacing between adjacent icons matters. Two adequate targets placed too close together can create the practical equivalent of one ambiguous control.
A five-question review
I review an icon as a complete control, not an illustration. First, what exact action or state does it represent? Second, would a user recognize that meaning here without relying on a tooltip? Third, does the result match what the shape and placement promised? Fourth, are focus, active, disabled, and error states distinguishable? Fifth, is the target forgiving across touch, pointer, keyboard, and zoom?
If the answers are weak, polishing the curves will not fix the product. The control may need a label, a more familiar symbol, a different location, or a different interaction entirely.
The art of menu icon design is restraint with accountability. Draw less, but make every line participate in a promise the interface can keep.
- Name the verb.
- Respect learned conventions.
- Use labels when they reduce uncertainty.
- Design every state.
- Separate glyph size from target size.