skip to content

In a design system's icon set, why keep one metaphor per concept, and what breaks when a funnel icon means both filter and conversion report?

level: middleimportance: should knowfreq 32%

answer

  1. icons are learned, not innate
  2. homonyms versus synonyms
  3. which meaning keeps the picture
  4. modifiers mean one thing everywhere
  5. a concept map in the guide

basics

~20 s

Users learn each icon's picture-to-meaning mapping, so one concept needs one picture everywhere. A funnel meaning both filter and conversion report misleads users; the more common meaning keeps it and the other gets its own picture.

solid answer

~40 s

An icon's **metaphor** is the picture that stands for a concept, and users **learn** it by repetition. Consistency breaks two ways: **one picture, two meanings** (a homonym, like a funnel for both the filter panel and the conversion report) makes users unable to predict what a click does; **one meaning, two pictures** (a synonym, like two different export icons) makes them relearn and wonder whether the actions differ. The homonym is worse because it misleads. The fix is a decision: the more frequent, conventional meaning (filter, in a dashboard) keeps the funnel, the report gets a picture of what it shows, and the choice goes into a **concept map** in the icon guide. The same rule applies to **modifiers**: a plus means create on every base icon.

go deeper

for a junior

Recall the rule: one concept, one picture, everywhere, and that a modifier such as a plus keeps one meaning on every base icon.

for a middle

Explain homonyms versus synonyms and why a picture with two meanings misleads, while two pictures for one meaning only slows users down.

for a senior

Show how you would resolve an overloaded picture: decide which meaning keeps it by frequency and convention, redraw the other, and record it in a concept map with a review step.

for a principal

Weigh the cost of changing an established but dated metaphor against the relearning it forces on every existing user.

## What an icon metaphor is An icon rarely depicts an action itself; nobody can draw 'export'. It depicts an **object or gesture that stands for** the concept: an arrow leaving a tray for export, a funnel for filtering, a gear for settings. That mapping from picture to meaning is the icon's **metaphor**. Users are not born knowing it. They **learn** it from repeated exposure, and a design system's icon set is where that learning is either reinforced or undermined. ## Two ways consistency breaks | Break | Shape | Example in an analytics dashboard | Effect on users | |---|---|---|---| | **One picture, two meanings** | A homonym | A funnel opens the filter panel in the toolbar and also marks the conversion-funnel report | Users cannot predict what a click will do | | **One meaning, two pictures** | A synonym | Export is a tray-and-arrow in tables and a box-with-arrow in charts | Users relearn the action per screen and may assume the two differ | Both are costly, but the homonym is worse: a synonym slows users down, whereas a homonym actively **misleads** them into the wrong action. WCAG 2.2 makes a related demand at the level of identification: **3.2.4 Consistent Identification** (Level AA) asks that components with the same functionality within a set of web pages be identified consistently. One metaphor per concept is the visual side of the same idea. ## Fixing the funnel case The funnel scenario needs a decision, not a compromise: 1. **Decide which meaning keeps the picture.** In data-heavy products the funnel is a widely learned picture for *filter*, and filter appears on far more screens than one report, so filter keeps it. 2. **Give the other concept its own metaphor.** The conversion report can use a picture of what it shows, for example descending stepped bars, rather than borrowing the filter's funnel. 3. **Record the decision** in the icon guide's concept map so the next contributor does not reintroduce the clash. The same reasoning applies whenever a picture is overloaded: the more frequent, more conventional meaning usually keeps it, because moving it costs more users a relearning. ## Consistency in modifiers too Many sets compose icons from a base picture plus a small **modifier**: a plus for create, a slash for off, a small arrow for export, a clock for scheduled. Metaphor consistency applies to these as well: - A modifier should mean **the same thing on every base**: a plus on a report means new report, a plus on a dashboard means new dashboard. - Modifiers should sit in a **consistent position** and follow the same stroke and corner rules as the base, or the composite looks pasted together. - A modifier learned once lets users read **new composites instantly**, which is the payoff of having a system at all. ## Where good metaphors come from Good metaphors are **familiar to the audience** rather than clever. Some are conventions that outlived their origin (a floppy disk still reads as save to many users who never held one), and a system replaces them only with a strong reason, because relearning costs users more than an outdated picture does. Some metaphors are cultural: a mailbox shape, a hand gesture or a symbol can read differently across markets, so a product used internationally prefers widely shared or abstract pictures and checks new ones with users from its main markets. ## Keeping it consistent as the set grows A growing set drifts toward synonyms because each new contributor draws a concept the way they imagine it. Practices that prevent this: - A **concept map** in the icon guide: each concept, its one approved picture, and pictures explicitly *not* to be used for it. - A **review step** for new icon requests that checks the concept map before drawing starts, not after. - **Reuse before drawing**: when a product team asks for an icon, the first question is whether an existing metaphor already covers the concept. These keep the visual vocabulary small and stable, which is what lets users recognise an icon at a glance, on the web, on native mobile and in any other product that draws from the same set.

  • When should a design system replace a dated metaphor, such as a floppy disk for save?
    Rarely and deliberately: only when research with the actual audience shows the old picture confuses them, because every replacement makes existing users relearn. If it is replaced, it is replaced everywhere in one step, so the set never shows two pictures for save at the same time.
  • How do you choose a metaphor for an abstract concept with no obvious picture, such as a detected anomaly?
    Combine a shape users already know with the domain's own picture, for example a chart line with a marked spike, then test recognition with users. Abstract concepts rarely get universal pictures, so the visible label carries the meaning while the picture is being learned.

Icons work like words in a language. A word that means two unrelated things mid-sentence trips the reader up, and two different words for one thing make the reader wonder whether they mean something different.

saying these in an interview costs you the question

  • Reusing one icon for two unrelated actions keeps the set small.
  • Each screen may choose its own icon for the same action.
  • Users read labels, so the metaphor chosen barely matters.
  • A more literal new metaphor should always replace an outdated one.
  • A plus or slash modifier may mean different things on different icons.