skip to content

In atomic design, what is a molecule, and why does a support tool's ticket-search field of label, input and button qualify as one?

level: juniorimportance: must knowfreq 48%

answer

  1. second level of five
  2. atoms gain a purpose together
  3. one job you can name
  4. label names input, button submits
  5. single responsibility, portable

basics

~20 s

A molecule is a small group of atoms working as one unit with one focused job. A ticket-search field qualifies because the combination links the parts: the label names the input and the button submits its query.

solid answer

~40 s

In Brad Frost's atomic design, a molecule is a *relatively simple group of UI elements functioning together as a unit*. The atoms gain a purpose from the combination: in a ticket-search field, the label now names the input and activating the button submits what the agent typed. The group does one job — find tickets — so it can be dropped anywhere that job is needed: the queue header, a sidebar, a native app's top bar. It stays small: it does not decide where results appear or how the screen is laid out. Frost ties the level to the single responsibility principle, which makes molecules easier to test, reuse and keep consistent.

go deeper

for a junior

Recall Frost's definition — a relatively simple group of atoms functioning as a unit — and the search-form example of label, input and button.

for a middle

Explain what the combination adds: the label now names the input, the button now submits. Tie the level to the single responsibility principle and what that buys in testing and reuse.

for a senior

Show you can place real components from a product at the right level, spot groups that do several jobs, and explain why keeping molecules focused pays off across web and native.

for a principal

Weigh the value of a shared granularity vocabulary across design and engineering against the cost of teams arguing classification instead of shipping.

## Where the name comes from Brad Frost's **atomic design** borrows its vocabulary from chemistry. In chemistry, a **molecule** is a group of atoms bonded together that takes on properties of its own: water and hydrogen peroxide are both made of hydrogen and oxygen, yet they behave very differently. The interface version keeps that idea. A molecule is not just several atoms sitting near each other; the combination gives the atoms a purpose they did not have alone. The five levels of the method are atoms, molecules, organisms, templates and pages. This answer is about the second level: the smallest level at which parts start working together. ## The definition in interface terms Frost defines molecules as **relatively simple groups of UI elements functioning together as a unit**. Unpacked, that gives four properties you can check: - **Small.** A handful of atoms, not a whole section of a screen. - **One focused purpose.** The group does one job a person can name in a short phrase, such as 'search tickets' or 'set priority'. - **A relationship between the parts.** The combination creates behaviour: a label now names a particular input, a button now submits that input's value. - **Portable.** Because it does one job and does not depend on the screen around it, it can be dropped anywhere that job is needed. ## Worked example: the ticket-search field Frost's own example is a search form made of a label atom, an input atom and a button atom. In a customer-support ticketing tool the same shape appears as the field agents use to find tickets: 1. The **label atom** on its own is just text. Inside the molecule it names the input, so assistive technology announces 'Search tickets' when focus lands on the field. 2. The **input atom** on its own accepts any text. Inside the molecule, its value is what gets searched. 3. The **button atom** on its own has no particular action. Inside the molecule, activating it submits the query. The molecule adds exactly those links. It does not decide where results appear, how the queue is laid out or which tickets the agent may see; those concerns belong to the larger parts of the interface that use the field. ## Other candidates in a support tool | Candidate | Atoms involved | The one job | Verdict | |---|---|---|---| | Ticket-search field | label, input, button | find tickets | molecule | | Labelled priority selector | label, select control | set a ticket's priority | molecule | | Reply actions bar | send button, attach button | act on a drafted reply | molecule | | Single send button | only itself | send | atom | | Ticket header with title, requester, status and actions | several molecules | present and manage one ticket | above the molecule level | The last row is the usual mistake in reverse: a group that combines several jobs has outgrown the molecule level, even if each of its parts is simple. ## Why a separate level is worth having People assembled elements into small groups long before atomic design had a name for it. Frost's argument for naming the level is the **single responsibility principle** — do one thing and do it well: - **Testing is easier**, because a molecule has one behaviour to verify: type, submit, receive the query. - **Reuse is easier**, because a focused group fits many contexts. - **Consistency improves**, because every screen that needs ticket search gets the same label, keyboard behaviour and spacing instead of a local reinvention. Burdening one pattern with too much complexity makes it unwieldy, so the pressure to keep molecules simple is the point of the level, not a side effect. ## Not a web-only idea Atomic design is about user interfaces, not one technology. Frost applies it to a native mobile photo app, where a bottom navigation bar built from several icons is a molecule, and so is the row of actions under each photo. A native support app has the same ticket-search field in its top bar; a design editor's library holds the same group as a reusable component with nested parts. The level describes how parts relate, not which platform renders them. ## Common misreadings - Treating any component bigger than one element as a molecule, however many jobs it does. - Believing every atom must be finished before any molecule is designed. Frost is explicit that the method is not a linear sequence; the levels are a mental model used while designing the whole interface. - Assuming a molecule must mix different atom types. A navigation bar of repeated icon-and-label items is still one unit with one purpose. - Assuming the atoms stay unchanged in meaning. Inside the molecule they gain a role — the label is now *this input's* label.

  • Does a molecule have to combine different kinds of atoms?
    No. Frost's native-app example treats a bottom navigation bar made of several icons as a molecule: the atoms repeat, but together they do one job — move between the app's main sections — and function as one unit. What makes a molecule is a shared purpose and a relationship among the parts, not variety in the atom types.
  • Why did Frost use chemistry names instead of words like element, module and component?
    Because the chemistry names imply an order. Nobody can tell from 'module' and 'component' which one contains the other, while most people know atoms form molecules and molecules form organisms. Frost also warns against pushing the metaphor too far with stakeholders; the names are a shorthand for granularity, not a science lesson.

saying these in an interview costs you the question

  • Any component with more than one element is a molecule, however many jobs it does.
  • Atoms keep exactly the same meaning inside a molecule; combining them adds nothing.
  • Every atom must be finished before the team may design any molecule.
  • Molecules are a web styling concept that does not apply to native apps.
  • A molecule must always mix different kinds of atoms.