On a labeled button the icon aids recognition; it does not carry meaning alone

What it is

When icon and type share a button, the type is the name and the icon is a redundant pictorial cue. A magnifying glass no longer has to mean “this is Search” by itself; it helps the eye land on that control in a row of words. Treating the icon as independent meaning that could drop the words leads to the wrong metaphor, or to vague copy because “there is a picture.” The contract of coexistence is dual coding, not two names.

Why it happens

Dual coding aims the graphic and verbal channels at the same action: search can take the faster graphic, verification takes the words. The graphic’s job is to speed locating, not to supply a second meaning. If the icon says something else (a download arrow on Share), the channels fight and speed becomes interference. If the icon is a decorative dot or a brand mark, it does not speed locating and it still costs width. Auxiliary means: cover the icon and the button should still be understandable; cover the type and failure on the icon alone is allowed—the words catch it. That is the opposite demand of an unlabeled icon button.

Studying it

Visual search: find Export in a row of icon-plus-text buttons, with a relevant icon, an irrelevant icon, or type only. Then identify with type covered.

Independent variables: whether icon and type co-refer, whether the icon is decoration, familiarity with the icon. Dependent variables: search time, first hit, identification with type covered (expected to be weaker).

If identification with type covered is treated as the success criterion, the test turns a labeled button back into an unlabeled icon. That is the wrong contract.

Where it stops holding

Some traffic and industrial UIs are legally graphic-first, with type as backup—the contract flips. For children who cannot yet read, the icon is the name. On a large empty-state button, the icon also carries mood and brand, not only locating, but it still must not fight the words. In a very narrow toolbar the icon may briefly carry meaning alone; that is a degradation, not the labeled default.

Applying it

• Write the type first, then pair a conventional icon that co-refers; do not draw the icon and then squeeze copy to fit it.
• Read the button with the icon removed: meaning should still be complete. Removing type may weaken it.
• Do not give every button a unique complex illustration; scanning wants a small symbol.
• Verify by timing a search for a named action in a row. An irrelevant icon should slow or err; removing the icon and leaving type should still complete the task.

Related

• Within the group: E1.13.2 When icon and type conflict, people follow the type · E1.13.3 In a narrow space keep the type, not the icon alone · E1.13.4 Icon-plus-text spacing and alignment need one consistent system
• Adjacent: F6.02 Icon plus text · E1.04 Icon-button ambiguity · E1.06 Button labels
• Search terms: dual coding · icon plus text · pictorial cue