skip to content

In a design system's icon library, how do search keywords and aliases help people find icons, and what should they contain?

level: middleimportance: should knowfreq 27%

answer

  1. people search for meanings
  2. search terms versus alternate names
  3. synonyms, uses, former names
  4. curated, not exhaustive
  5. failed searches breed duplicates

basics

~20 s

Keywords attach the meanings, synonyms and related terms people search for to a depiction-named icon, and aliases are alternate names that resolve to the same icon, often former names. Together they let 'audio guide' find 'headphones'.

solid answer

~40 s

Icons are named for their picture, but people search for what they need, so a designer on a museum kiosk types 'audio guide', not 'headphones'. **Search keywords** bridge that gap: each icon carries the meanings it is actually used for, common synonyms and related terms, so 'cloakroom' finds `hanger` and 'timed entry' finds `clock`. An **alias** is different: an alternate name that resolves to the same icon, typically a former name kept after a rename, so it works in search and, where the library supports it, in code. Keywords must be **curated**: tagging every icon with everything makes searches return noise. They stay current by adding a keyword whenever a new use appears and by mining failed searches, because an icon nobody can find gets drawn again.

go deeper

for a junior

Recall that icons are found through keywords because people search for meanings, and that an alias is another name for the same icon.

for a middle

Explain the difference between a keyword and an alias, what belongs in keywords, and why over-tagging hurts search as much as missing tags.

for a senior

Show a process that keeps keywords current: add on new use, mine failed searches, alias on rename and prune noise, framed as a control on duplication.

for a principal

Weigh how much the library promises through aliases against the maintenance cost of every name consumers may depend on.

## The findability problem A mature icon library holds hundreds of icons, named by what they depict. The people using it rarely think in pictures; they think in needs. A designer building a museum ticketing kiosk's visitor services screen searches for 'audio guide', 'cloakroom' and 'family ticket'. If the library only matches names, those searches return nothing, and the designer does one of two expensive things: browses hundreds of icons, or draws a new one. The second is how libraries end up with three slightly different headphones. ## Keywords versus aliases | | **Search keyword** | **Alias** | |---|---|---| | What it is | A term attached to an icon for search | An alternate name that resolves to the same icon | | Where it works | Search in the documentation site and design library | Search, and in code where the library supports it | | Typical content | Meanings, synonyms, related concepts | Former names after a rename; a widely used alternative name | | Cost of adding one | Low | Higher: it becomes part of what consumers can depend on | The distinction matters because an alias is a **promise**: code or design files can reference it, so removing it later is a change consumers notice. A keyword is only a search aid and can be pruned freely. ## What goes into keywords Good keywords come from how the icon is really used and how people really search: - **Meanings in use**: every purpose the icon serves across products, such as opening hours, timed entry and tour length for `clock`. - **Synonyms**: bin, trash and delete; cloakroom and coat check. - **Related concepts** people reach for: donation for a heart-in-hand icon, admission for `ticket`. - **Former names**, when a rename left no alias, so memory of the old name still finds the icon. - **Terms in the working languages** of the teams using the library, where those differ. ## What stays out - **Everything that loosely relates.** Tagging `ticket` with purchase, money, event, museum, entry, visit and more makes it appear in half of all searches, and noisy results push people back to drawing their own. - **Variant words** such as filled or small; those are handled by the naming scheme, not search. - **Meanings the icon must not be used for.** If an icon is reserved for one meaning, tagging it with a tempting near-miss invites misuse. ## Keeping keywords current Keywords decay as products add uses. A light process keeps them honest: 1. **Add on new use.** When a team uses an icon for a new meaning, the contribution or review step adds that meaning as a keyword. 2. **Mine failed searches.** Searches with no results, or with results nobody picked, show missing keywords directly. 3. **Alias on rename.** When an icon is renamed, the former name becomes an alias or at least a keyword, so nothing that remembers it fails. 4. **Prune periodically.** Remove keywords that produce noise or reflect uses that no longer exist. ## A worked example The kiosk team's searches, and how a well-kept library answers them: | Search term | Icon found | Found through | |---|---|---| | audio guide | `headphones` | Keyword (a meaning in use) | | coat check | `hanger` | Keyword (a synonym of cloakroom) | | timed entry | `clock` | Keyword (a meaning in use) | | buy-ticket | `ticket` | Alias (a former name, still resolvable) | | exhibition | several | Keyword shared by a small, relevant group | The last row is the healthy case of a broad term: it returns a handful of plausible icons, not the whole library. If 'exhibition' returned two hundred results, the keyword would be doing harm and should be pruned from the icons it only loosely fits. ## Why it matters beyond convenience Findability is how a library prevents duplication. Every icon that cannot be found is a candidate to be redrawn, and every redraw is a future inconsistency that someone must audit. Keywords and aliases are the cheapest control a library has on its own growth, and they work the same whether the icon ends up in a web product, a native app or a kiosk.

  • Why not tag every icon with as many keywords as possible?
    Because search precision drops: an over-tagged icon shows up in unrelated searches, results get long and noisy, and people stop trusting search and draw their own icons instead. Keywords should reflect real uses and real search terms, and be pruned when they cause noise.
  • Where do good keywords come from in practice?
    From actual usages across products, from failed or abandoned searches in the documentation site and design library, and from questions teams ask when they cannot find an icon. Each new approved use adds its meaning as a keyword during review.

saying these in an interview costs you the question

  • A good depiction name makes search keywords unnecessary.
  • More keywords always make an icon easier to find.
  • Aliases and keywords are the same thing under two names.
  • Keywords should use only the design team's internal jargon.
  • Aliases are free to add and free to remove later.