In a design system using atomic design, is a colour, a type style or a spacing value an atom, and why does the answer matter?

## The question behind the question When interviewers ask whether a colour is an atom, they are checking whether a candidate understands what an atom **is**. In Brad Frost's atomic design, atoms are basic interface elements, such as labels, inputs and buttons, that cannot be broken down further without ceasing to be **functional**. The key word is functional: an atom is something you can put on a screen and use. ## Elements versus properties There are two different kinds of thing in a design system: | | Interface element | Property value | |---|---|---| | Examples in a travel-expense tool | Amount input, category label, submit-report button, receipt icon | The brand's accent colour, the body text style, the standard gap between form rows | | Can a user see or use it alone? | Yes | No, only as applied to an element | | Has states such as focus or error? | Often | No | | Passes the indivisibility test? | It is either an atom or a composition | The test does not apply; it is not an element | | Where it usually lives | Component catalogue | Foundations or style guidelines | Frost's own description supports this split. He writes that each interface atom has its own properties, giving examples such as the dimensions of an image or the font size of a primary heading. The heading is the atom; its font size is a **property** of it. ## Why some teams list values as atoms anyway It is common to see colour palettes, typefaces and even animations listed among atoms in team documentation. The intuition is reasonable: they are the most basic ingredients of the interface. As a teaching device it does little harm. In a working system, though, it creates problems: - **The indivisibility test breaks.** You cannot ask whether a colour can be split into working elements, because it is not an element to begin with. - **The atom list becomes two lists in one.** Designers looking for the amount input have to scroll past swatches, and engineers looking for the accent colour look in the wrong place. - **Ownership blurs.** A change to the accent colour is a decision that affects every atom; a change to the input atom affects every place the input appears. Treating them as the same kind of thing hides that difference. - **Reviews get muddled.** A value review is about brand and accessibility; an atom review is about behaviour, states and anatomy. ## Where values go instead Most systems keep a separate **foundations** layer (colour, type, spacing, elevation, motion) that sits beneath atoms. Atoms consume those values; they do not contain or redefine them. How those values are structured, named and aliased is a separate part of the system. The practical rule is: 1. If you can place it on a screen and a user can perceive or operate it on its own, it is an **element**, and the indivisibility test decides whether it is an atom. 2. If it only exists as an attribute of an element, it is a **value**, and it belongs in the foundations. ## Edge cases - **A divider line.** It is visible and can be placed on its own, so many systems treat it as an atom, even though it does little. The test is whether the team places it as an element; if it is only ever part of a list's styling, it is a property. - **An icon.** An icon is an element, not a value, even though an icon set feels like a foundation. It can be placed, it has meaning, and it is an atom. - **A text style.** "Heading, level 2" as a style is a value; a heading element that applies it is an atom. ## Why it matters in an interview The strongest answers do not just say "no". They explain the element-versus-property distinction, show how it keeps the atom list and the indivisibility test useful, and acknowledge that some teams draw the line differently for teaching purposes.