skip to content

In atomic design, is a support tool's ticket-priority indicator of flag icon plus text an atom or a molecule, and how do you decide?

level: middleimportance: should knowfreq 42%

answer

  1. no lookup table in the book
  2. split into shipped atoms?
  3. does the combination add a relationship
  4. do parts vary independently
  5. write the rule down, apply consistently

basics

~20 s

Apply a written boundary test: does it split into atoms the system ships, does combining them add a new relationship, do callers vary the parts separately? A fixed icon-and-text signal is defensibly either; consistency matters more than purity.

solid answer

~50 s

Frost's book gives examples, not a ruling for every component, so a team needs its own test. I ask four things: does it **decompose** into atoms the system already ships and uses elsewhere; does combining them create a **new relationship**, the way a label names an input; do callers need to **vary the parts independently**; and do we want the parts **recombined** elsewhere? A search field passes clearly. The priority indicator is borderline: an icon and text exist as atoms, but together they state one fixed value, so many teams ship it as an atom with a single 'priority' input, while others call it a molecule built from icon and text atoms. Either is defensible. What matters is that the rule is written down, applied the same way every time, and revisited when the facts change.

go deeper

for a junior

Recall that atoms cannot be split without losing function and molecules are small working groups; be ready to place a search field correctly.

for a middle

Apply a boundary test out loud — decomposition, new relationship, independent variation, recombination — and admit when a case is defensible either way.

for a senior

Explain what the classification changes in practice: the contract callers see, ownership, documentation and how changes ripple, and when evidence justifies reclassifying.

for a principal

Weigh how much classification rigour a system needs against the review time it costs, and how to encode the rule so many teams decide alike.

## Why the boundary is argued about In **atomic design**, an **atom** is a basic element that cannot be broken down further without ceasing to be functional — a label, an input, a button. A **molecule** is a relatively simple group of atoms functioning together as a unit with one focused purpose. The definitions are clear at the extremes and fuzzy in the middle, and the middle is where real components live. In a customer-support ticketing tool, the **ticket-priority indicator** — a small flag icon next to the word 'Urgent' — sits exactly there. It contains two parts the system already ships (an icon and a text style), yet everyone perceives it as one thing. Brad Frost's book gives examples of each level, not a lookup table of every component, so the team needs its own test. ## A four-question boundary test Ask these in order about the candidate: 1. **Decomposition.** Is it built from parts the system already ships as atoms, and are those parts useful on their own elsewhere? The flag icon and the text style are; a button's internal focus indicator is not. 2. **Relationship.** Does combining the parts create a behaviour or meaning neither has alone — a label now naming an input, a button now submitting a query? A search field passes this clearly. 3. **Independent variation.** Do callers need to change the parts separately — a different icon with the same text, or the text without the icon? If the parts always travel together in a fixed pairing, the group behaves like one element. 4. **Recombination.** Does the system want other groups to reuse these parts in new arrangements? If yes, keeping them as separate atoms, and the group as a molecule, preserves that. ## Applying it in the support tool | Candidate | Shipped atoms inside? | New relationship? | Parts vary independently? | Likely verdict | |---|---|---|---|---| | Ticket-search field | yes: label, input, button | yes: label names input, button submits | yes: label text, hint | molecule | | Labelled priority selector | yes: label, select control | yes: label names the control | yes | molecule | | Priority indicator (flag + text) | yes, loosely | weak: both state one value | no: fixed per priority | defensible either way; often an atom | | Icon button with a text label | icon shared; button not split | no: one control, one action | rarely | usually an atom | The priority indicator shows the honest outcome. Some teams call it an atom because its parts form one fixed signal with a single meaning and callers set only the priority. Others call it a molecule because it is literally assembled from an icon atom and a text atom. Both readings survive scrutiny. ## What the decision actually changes If both answers are defensible, why decide at all? Because the classification carries practical consequences: - **What callers can reach.** As an atom, the indicator exposes one input — the priority — and maps icon and text internally. As a molecule, it may let callers swap or omit a part. - **Where it is documented and who owns it.** Many teams file documentation, examples and ownership by level, so the call decides where people look. - **How changes ripple.** A change to the shared icon atom reaches every molecule that uses it; an atom with internal parts changes only when its owner edits it. Those consequences, not faithfulness to the chemistry metaphor, should drive the call. ## Making the decision stick - **Write the test down** in the system's contribution guidance so reviewers ask the same questions every time. - **Record borderline rulings** with a one-line reason, so the same debate does not reopen next quarter. - **Allow reclassification** when the facts change. If a dense table view later needs the priority text without the flag, the parts now vary independently, and the indicator has become a molecule. The same test works for a native mobile team: a native priority indicator faces the identical question of whether its icon and text are separately configurable, and the answer drives the same contract decision. ## Common traps - **Counting visual parts.** Two shapes on screen do not make a molecule; a checkbox with its check mark is still one atom. - **Measuring size.** A large illustration can be an atom and a small labelled checkbox a molecule. - **Treating the ruling as permanent**, when a new requirement can change the answer to question 3. - **Chasing the one true level** in review instead of settling on a consistent team rule and moving on.

  • Does the label-plus-checkbox pair count as a molecule even though it is tiny?
    By the relationship test, usually yes: the label names the checkbox and clicking it toggles the box, a behaviour neither part has alone. Size is not the criterion. Some teams still ship it as one control because the pairing is always fixed; either is defensible if applied consistently.
  • What evidence would make you reclassify an atom as a molecule later?
    A real caller needing to vary its parts independently, or a new group wanting to reuse one of its parts on its own. When that happens, split the parts into atoms and turn the old atom into a molecule composed from them, keeping its public input the same so existing callers do not notice.

saying these in an interview costs you the question

  • Anything with two visible parts is automatically a molecule.
  • Frost's book assigns the correct level to every kind of component.
  • A component's level is decided by its size on screen.
  • Once classified, a component's level must never change.
  • Finding the one true level matters more than a consistent team rule.