skip to content

In a design system's icon library, why are icons usually named for what they depict rather than for what they mean?

level: juniorimportance: should knowfreq 32%

answer

  1. the picture is stable, the use is not
  2. one clock, many meanings
  3. meaning lives at the point of use
  4. keywords carry the meanings
  5. base name plus ordered suffixes

basics

~20 s

An icon's picture stays the same while its meaning depends on where it is used, so a depiction name like 'clock' survives reuse while a meaning name like 'opening-hours' turns wrong. Meanings belong in keywords and at the point of use.

solid answer

~40 s

The drawing is the one stable fact about an icon; its meaning changes with context. In a museum ticketing kiosk the same clock appears for opening hours, timed-entry slots and tour length, and the same ticket for buying admission and viewing bookings. A meaning name like `opening-hours` becomes misleading the moment the icon is reused, so the next team either uses an icon whose name contradicts their code or draws a duplicate. A depiction name like `clock` stays true everywhere. The meanings still matter: they go into **search keywords and aliases**, and into each usage's label. The exception is a small set of **reserved icons**, such as close or back, whose meaning is the contract and which some systems name for it. Variants then add suffixes to the depiction base in one documented order.

go deeper

for a junior

Recall the rule: name the icon for the picture, such as clock or ticket, and put the meanings in keywords and in the label where it is used.

for a middle

Explain how meaning names break on reuse, producing misleading code or duplicate drawings, and how a base-plus-suffix scheme keeps variant names predictable.

for a senior

Show you would apply the reuse test to every proposed name and treat reserved icons as the deliberate, documented exception to depiction naming.

for a principal

Weigh the cost of changing an established naming scheme against the drift and duplication a meaning-based scheme keeps producing.

## Two ways to name an icon Every icon in a design system's library needs a name that designers search for, that engineers reference in code, and that appears in the documentation. There are two basic strategies: | Strategy | Example | Strength | Weakness | |---|---|---|---| | **By depiction** (what it shows) | `clock`, `ticket`, `headphones` | Stays true however the icon is reused | Searching for a meaning needs keywords | | **By meaning** (what it is for) | `opening-hours`, `buy-ticket`, `audio-guide` | Obvious for the first use | Turns wrong or misleading as soon as the icon is reused | Most icon libraries name by **depiction**, and the reason becomes clear as soon as an icon is used twice. ## Why meaning names break on reuse Take a museum ticketing kiosk. The first screen built is the visitor information screen, and its clock icon is named `opening-hours`. Then: 1. The booking flow needs a clock for **timed-entry slots**. The team either references an icon called `opening-hours` in a component that has nothing to do with opening hours, or decides it needs its own icon. 2. If it draws its own, the library now holds **two clocks** that drift apart in style, and a third team has to guess which one to use. 3. If it reuses the original, anyone reading the code or the design file sees a name that **contradicts the screen**, and a later rename of `opening-hours` for the information screen silently changes the booking flow. A depiction name avoids all three: `clock` is correct on every screen, because it describes the only thing all its uses share. ## Where meaning lives instead Naming by depiction does not throw meaning away; it moves it to places that can hold many meanings at once: - **Search keywords and aliases** attach every meaning in use (opening hours, timed entry, tour length) to the one `clock` icon, so a search for any of them finds it. - **The point of use** carries the specific meaning for that screen: the visible label, and the accessible name the control exposes. - **Usage guidance** in the icon's documentation page lists the approved meanings and any it must not be used for. ## The exception: reserved icons A few icons are deliberately locked to **one meaning** across every product, typically controls users act on without reading: close, back, help, warning. For these, the meaning *is* the contract, and some systems name them by meaning (`close` rather than `x-mark`) precisely to signal 'use only for this'. Others keep depiction names and mark the reservation in metadata. Either works; what matters is that the reservation is explicit. ## Building the full name Most icons exist in several **variants**, for example outlined and filled, and several sizes. A consistent scheme builds each name from the depiction base plus suffixes in **one documented order**: - the **base** is the depiction: `ticket`; - a **fill suffix** marks the variant: `ticket-filled`; - a **size suffix**, where sizes are separate drawings, comes last: `ticket-filled-16`. The exact order and separator are a local convention; the rule is that every icon follows the same one, so names are predictable, sort together and autocomplete. Two things do not belong in the name: the **state** a variant is used for (`ticket-active`), because the filled variant may serve other purposes, and the **meaning**, for the reasons above. Some libraries expose fill and size as parameters of one icon instead of separate names; the same principle applies to the parameter values. ## One name across every platform A design system ships the same icon to several places: the design editor library designers draw from, the web package, and native mobile asset catalogues. The name is what ties those copies together, so a designer's handoff that says `clock` means the same drawing to the web engineer and the mobile engineer. Depiction names help here too: - they are **neutral about ownership**, so teams in different products do not argue about whose feature the icon belongs to; - they rarely need to change, so the copies on each platform stay in sync with fewer renames; - they read the same in every naming convention a platform imposes, whether it prefers dashes, underscores or camel case, because the words themselves do not change. A meaning name, by contrast, invites each platform team to 'fix' it for their own use, and the copies drift apart. ## A quick test for any proposed name Ask: *if another team reused this icon for a different purpose tomorrow, would its name still be true?* If yes, the name describes the picture. If no, the name describes one use, and it belongs in the keywords.

  • What should the name of a filled, 16-unit ticket variant look like?
    The depiction base followed by suffixes in the library's one documented order, for example ticket, then ticket-filled, then ticket-filled-16 where sizes are separate drawings. The separator and order are local choices; the rule is that every icon uses the same scheme and that no suffix encodes a state or meaning.
  • Is naming an icon by meaning ever the right choice?
    For a small set of reserved icons whose single meaning is the contract, such as close or back, some systems name them by meaning to signal 'use only for this'. For every icon that can legitimately be reused, a depiction name is safer, with meanings carried in keywords.

saying these in an interview costs you the question

  • Name each icon after the feature that first needed it.
  • A meaning-based name makes an icon easier to reuse elsewhere.
  • If the name doesn't fit a new use, draw a new icon.
  • Variant suffixes can come in whatever order each contributor prefers.
  • The state a variant signals, such as active, belongs in its name.