A travel-expense tool's design system lists sixty atoms, including a labelled amount field with error text and a separate border atom. What went wrong, and how do you fix it?
answer
- atom as a badge of basicness
- too big and too small
- re-run the indivisibility test
- properties back to foundations
- decide the fuzzy cases once
basics
~20 sThe label was used as a badge rather than a granularity rule: compositions were promoted to atoms and properties were split into atoms. Re-run the indivisibility test, move compositions up, move properties into foundations, and record rulings for genuinely fuzzy cases.
solid answer
~50 sTwo opposite errors have happened. Compositions such as the labelled amount field were called atoms, usually because 'atom' came to mean 'basic building block we trust', and properties such as a border were split out as atoms because they are small. Both break the definition: an atom is a functional element that cannot be split without ceasing to work. I would re-run the indivisibility test on every entry. Anything whose parts work on their own moves up and is rebuilt from the real atoms it contains; anything that is not a placeable element moves into the foundations as a value. For genuinely debatable cases, such as an input with a built-in clear control, the team makes one ruling, writes down the reason, and applies it consistently. The goal is not perfect taxonomy but a list people can trust when they look for a part.
go deeper
Recall the two directions an atom list can drift: compositions promoted to atoms, and properties split out as atoms.
Explain how the indivisibility test sorts each entry into atom, composition or foundation value, and why variants are not separate atoms.
Walk through the clean-up on a real system: rebuilding compositions from atoms, moving values, writing rulings for fuzzy cases, and communicating moves to consumers.
Discuss how much classification rigour a system needs and how to keep the vocabulary consistent without turning it into dogma.
## Diagnosing an inflated atom list In Brad Frost's atomic design, **atoms** are basic interface elements, such as labels, inputs, buttons and icons, that cannot be broken down further without ceasing to be functional. A travel-expense tool with sixty atoms is not necessarily wrong, but the two examples in the scenario show the list has drifted in **both directions**: | Entry | Error | Why it happens | |---|---|---| | Labelled amount field with error text | **Too big**: a composition called an atom | "Atom" has come to mean "trusted basic building block" rather than "indivisible element" | | Border atom | **Too small**: a property called an atom (a divider placed as its own element is a different case) | Teams equate "smallest visible thing" with "atom" | Other common signs of the same drift: atoms that contain other atoms (a receipt row with a thumbnail and a delete button), atoms that differ only by a colour (four "status atoms" that are one element with a variant), and atoms nobody can explain. ## Why it matters - **Duplication.** If the labelled field is an atom, the label and input inside it are often re-implemented rather than reused, so the standalone label and the one inside the field drift apart. - **Unclear change impact.** Changing the "border atom" appears to affect one thing but actually touches every element that uses a border. - **Loss of trust.** When the list mixes elements, compositions and values, people stop using it to find parts and build their own. ## The fix, step by step 1. **Re-run the indivisibility test on every entry.** For each, ask whether any part works as an interface element on its own. 2. **Move compositions up.** The labelled amount field becomes a composition of a label atom, an input atom and an error-text atom. Rebuild it from those atoms so that a fix to the input fixes every field. 3. **Move properties into foundations.** The border, along with any colours, radii or spacing listed as atoms, becomes a value that atoms consume, documented with the other foundations. 4. **Merge near-duplicates into one atom with variants.** Four status tags that differ only in colour and wording are one element with a variant, not four atoms. 5. **Rule on the fuzzy cases.** Some elements genuinely sit on the line: an input with a built-in clear control, a button with an icon and text. The team decides once, writes down the reason (for example, "a control that never appears outside its host stays part of the host atom") and applies it everywhere. 6. **Communicate the change.** Teams that consumed the old "atoms" need to know where things moved; classification changes are cheap in a document and expensive in code, so sequence them with the work of rebuilding compositions. ## How to keep it from drifting again - Add the indivisibility test to the **review of new atoms**: a proposal states which parts it contains and why none can be used alone. - Keep **values out of the atom list** by design, with foundations documented separately. - **Revisit classifications** when usage changes. If the receipt icon starts appearing on its own, the component that contained it becomes a composition. ## Where the method bends This scenario is also where interviewers probe whether a candidate treats atomic design as dogma. Frost himself calls it a mental model rather than a rigid process. A mature answer admits that classification has fuzzy edges, that the value lies in a **shared, consistent vocabulary**, and that a team's written rulings matter more than finding the one true answer for each element. What must not happen is inconsistency: the same kind of element classified two ways in the same system. ## Common mistakes in the clean-up - Renaming entries in documentation without rebuilding compositions from real atoms, so the duplication stays in code. - Deleting the border atom without giving its value a home in the foundations. - Debating every fuzzy case endlessly instead of making a written ruling. - Reclassifying everything at once and breaking consumers without notice.
- A button with both an icon and a text label: atom or composition?It depends on the team's ruling, which is why it should be written down. If the icon is also an atom used elsewhere, a strict reading makes the button a small composition containing it. Many teams still treat the button as one atom with an optional icon slot, because the icon is part of the button's anatomy. Either is fine if applied consistently.
- Why rebuild the labelled amount field from atoms rather than just relabel it as a composition?Relabelling fixes the documentation but not the duplication. If the field still carries its own copy of the label and input, a fix to the input atom will not reach it and the two will drift. Rebuilding it from the real atoms is what makes the hierarchy pay off: one change flows into every field.
saying these in an interview costs you the question
- Calls a labelled field an atom because it is the basic form element.
- Treats every small visual property, like a border, as its own atom.
- Fixes the classification in documentation but leaves duplicated code.
- Insists every fuzzy case has one objectively correct classification.
- Deletes the border atom without giving its value a home in the foundations.