In a warehouse scanner app's design system, reviews stall on whether a scan field with a quantity stepper is a molecule or an organism. How do you resolve such boundary disputes?
answer
- the label is a communication aid
- organisms can hold organisms
- level depends on context
- reuse, ownership, stability
- decide, record, move on
basics
~20 sTreat the level as a communication aid, not a fact to prove. Decide with a written heuristic on reuse, ownership and whether it forms a screen section, record the call, and keep labels out of names and paths.
solid answer
~50 sAtomic design's middle boundaries are fuzzy by construction: Frost lets organisms contain atoms, molecules and other organisms, and the same scan field can be a small part in one screen and a whole section in another. So the label is not worth a stalled review. I would time-box the question and apply a written heuristic built on what actually matters: is it reused as a unit in several places, who owns and maintains it, does it do one focused job or form a distinct section of the screen, and how stable is its API. Then record the decision and its reason in a decision log and move on. If labels live only in documentation, not in component names or import paths, reclassifying later is cheap. If the disputes keep recurring, that is evidence the chemistry labels are not serving the team, and ownership tiers may serve better.
go deeper
Recall that molecules have one focused job and organisms form distinct screen sections, and that some components honestly sit between the two.
Explain why the boundary is fuzzy: organisms can contain organisms, level depends on context, and components grow across the line over time.
Show how you ended a recurring dispute on a real system: the heuristic you used, how decisions were recorded, and whether the team changed its taxonomy.
Consider whether the classification should carry any governance consequence at all, and what that choice does to review load across teams.
## Why the boundaries are fuzzy by design Brad Frost's **atomic design** gives crisp definitions at the ends of the hierarchy and judgement in the middle. A **molecule** is a relatively simple group of atoms with one focused job; an **organism** is a relatively complex component that forms a distinct section of an interface. "Relatively" is doing real work in both. Several things make the middle genuinely fuzzy: - **The hierarchy is not strict.** Frost defines organisms as groups of molecules and/or atoms and/or *other organisms*, so level is not simply "one step above what it contains". - **Level depends on context.** A scan field is a small part of a pick-item row, yet on a dedicated receiving screen the same component is the whole top section. - **Components grow.** A scan field that later gains a quantity stepper, a validation message and a history list has moved across the boundary without anyone deciding it should. - **The metaphor runs out.** Chemistry offers no rule for when a group of molecules becomes an organism; that call belongs to the team. An interviewer asking this wants to hear that you see the ambiguity as inherent rather than as a failure to read the definitions carefully. ## The dispute in the scanner app The component is a scan input (label, field, scan-trigger button) combined with a quantity stepper, used on the pick screen and the receiving screen. One reviewer argues it has one job, capturing an item and a count, so it is a molecule. Another argues it is a distinct section of the receiving screen and already contains a stepper molecule, so it is an organism. Both arguments are consistent with the method. That is the signal the label is the wrong thing to be arguing about. ## The questions that actually matter | Question | Why it matters | Answer for the scan field | |---|---|---| | Is it reused as a unit in several places? | Decides whether it belongs in the shared library or stays product-local | Yes: pick and receiving screens | | Does it do one focused job or form a distinct screen section? | The method's own distinction, applied to the typical use | One job in most uses | | Who owns and maintains it? | Decides review path and support | The system team | | How stable is its interface to consumers? | Decides how carefully changes are released | Stable after the stepper was added | These answers determine where the component lives, who reviews changes and how it is released. The level label follows from them, or can be left loose. ## A resolution process 1. **Time-box the classification**: a few minutes in review, not a recurring agenda item. 2. **Apply a written heuristic** the team agreed in advance, so the call is consistent across reviewers. 3. **Record the decision and its reason** in a decision log, so the same argument is not re-run next quarter. 4. **Keep labels out of component names and import paths**, so reclassifying later changes documentation, not consumers' code. 5. **Revisit only on evidence**, such as the component gaining a new responsibility or a new context. ## A sample heuristic One team's written rule, agreed once and applied in every review, might read: - one focused job, reused in several places: treat it as a molecule - forms a distinct section of at least one screen, or combines several focused jobs: treat it as an organism - used in only one product: keep it product-local, whatever its level The exact wording matters less than having one. ## Where the method breaks down, and what teams do instead - Teams whose reviews keep stalling often **collapse molecule and organism into one tier**, calling everything a component and reserving "pattern" for multi-component solutions. - Others **switch to ownership tiers** (core shared, extended, product-local), because who maintains a part turned out to matter more than its scale. - Some **keep atomic words only in the design-editor library**, where designers find them useful, and use plain names everywhere else. None of this rejects composition. It rejects spending review time on a label that changes nothing about how the component is built, owned or released. ## The same on every platform A native team building the handheld scanner screen faces the same ambiguity: whether its scan-and-count view is a small reusable view or a screen section. The resolution is identical, because the questions that matter — reuse, ownership, stability — do not depend on the platform.
- What would make you insist on a precise level for a component?When the level carries a real consequence in your system, for example if organisms are allowed to fetch data and molecules are not, or if the governance rules differ by tier. Then the classification changes behaviour and review, so it deserves a precise, documented answer. When it changes nothing, a loose label is fine.
- The disputes keep recurring every sprint. What do you conclude?That the taxonomy is not serving the team. Frost himself says the names should help communication; if they cause friction, change them. Many teams move to ownership tiers or merge molecule and organism into one component tier, keeping the atomic words only where designers still find them useful.
saying these in an interview costs you the question
- Every component has one objectively correct level if you read the definitions closely.
- An organism may only contain molecules, never atoms or other organisms.
- Boundary disputes mean the team has misunderstood atomic design.
- A component's level should be encoded in its name and import path.
- A component's level must be settled before anyone may build it.