skip to content

In a design system, what alternatives to atomic design's five-level taxonomy do teams use, and how do you choose between them?

level: middleimportance: should knowfreq 35%

answer

  1. naming is hard, Frost admits
  2. not rigid dogma
  3. hierarchy, ownership or purpose
  4. component-driven without level names
  5. whatever helps the team communicate

basics

~20 s

Teams use renamed levels, three tiers such as foundations, components and patterns, ownership tiers, purpose groups, or plain component-driven practice with no level names. Choose by what the organisation most needs to communicate: scale, ownership or purpose.

solid answer

~40 s

Frost himself says naming is hard and atomic design is not rigid dogma; he quotes a company's design team that replaced the chemistry words with Principles, Basics, Components, Templates, Features and Applications because colleagues found them confusing. Common alternatives are a **three-tier** split such as foundations, components and patterns; **ownership tiers** (core shared, extended, product-local); **purpose groups** (inputs, navigation, feedback); and **plain component-driven practice**, which builds and documents components in isolation and composes them into screens without naming levels at all. I choose by what the organisation most needs to communicate: atomic levels when the team needs a shared sense of scale, ownership tiers when many teams contribute and the key question is who maintains what, and purpose groups when discovery is the pain. Mixing them is normal.

go deeper

for a junior

Recall that atomic design's names are one option and that Frost himself accepts renamed levels if they help the team communicate.

for a middle

Compare the main alternatives by what each emphasises: scale, ownership or purpose, and explain how component-driven practice relates to atomic design.

for a senior

Show how you chose or changed a taxonomy for a real system, what problem drove the change and how you kept screen-level testing afterwards.

for a principal

Weigh taxonomy as an organisational tool: which vocabulary aligns many teams and platforms, and what it costs to change it once adopted.

## Frost's own position Brad Frost's **atomic design** names five levels: atoms, molecules, organisms, templates and pages. He is candid that the names are a choice, not a law. He writes that "naming things is hard and imperfect", that atomic design "is not rigid dogma", and that whatever taxonomy a team chooses should help it "communicate more effectively". He even quotes one company's design team whose colleagues met the chemistry words with confused looks; that team settled on Principles, Basics, Components, Templates, Features and Applications. The principle survived; the vocabulary changed. An interviewer asking about alternatives is testing whether you treat the method as a tool or a creed. ## Common alternatives | Taxonomy | Typical levels | What it emphasises | Trade-off | |---|---|---|---| | **Atomic levels** | Atoms, molecules, organisms, templates, pages | Scale and composition | Middle boundaries are fuzzy; metaphor can confuse stakeholders | | **Renamed levels** | Plain words chosen by the organisation | Same hierarchy, local language | Loses the shared industry shorthand | | **Three tiers** | Foundations, components, patterns | Separating raw design decisions from parts and multi-part solutions | Coarser; less guidance within the middle tier | | **Ownership tiers** | Core shared, extended, product-local | Who maintains what and how stable it is | Says little about scale | | **Purpose groups** | Inputs, navigation, feedback, data display, layout | Discovery by job | No composition hierarchy | | **Plain component-driven** | Components only, no level names | Minimal ceremony | No shared vocabulary for scale; screen-level testing is easy to skip | ## Atomic design versus plain component-driven practice The two are often confused because they share a core: - **Shared:** both build interfaces bottom-up from components, develop and document each component in isolation, and combine them into screens. - **Atomic adds** named granularity, so a team can talk about scale precisely, and two explicit screen levels. Templates capture content structure and pages test the parts against real content. - **Component-driven practice** is a process more than a taxonomy. It does not prescribe levels, which keeps it light, but nothing in it forces anyone to look at a whole screen with real content. Many teams practise component-driven development day to day and borrow atomic words only when they need to argue about scale. ## How to choose 1. **Name the audience.** Engineers, designers, product managers and executives read the taxonomy differently; stakeholders rarely warm to chemistry. 2. **Decide what most needs communicating.** Scale and composition favour atomic levels; ownership and stability favour tiers; findability favours purpose groups. 3. **Consider the contribution model.** When many product teams contribute to a shared system, the question "who maintains this?" usually matters more than "is this a molecule?". 4. **Check every platform.** A taxonomy has to work for the web team, the native mobile team and the design-editor library alike. A warehouse scanner app's native team should recognise its own parts in it. 5. **Reuse existing words.** If the organisation already says "patterns" and "components", building on that beats teaching a new vocabulary. ## What changing taxonomy costs Switching vocabulary in the middle of a system's life is not free: - documentation, design-editor libraries and training guides must be renamed together, or two vocabularies coexist - people keep using the old words for months, so a glossary mapping old terms to new ones helps - if level names leaked into component names or import paths, renaming reaches consumers' code The cheapest time to choose is before the vocabulary spreads; the next cheapest is as soon as the current one causes friction. ## Mixing taxonomies is normal - Atomic words in design critique, where scale is the question. - Ownership tiers in governance and contribution rules. - Purpose groups in the documentation site's navigation. Each answers a different question, so using several is not inconsistency. The failure mode is forcing one taxonomy to answer all three. ## Common misreadings - **"Renaming the levels means abandoning atomic design."** Frost endorses it when it helps communication. - **"Component-driven and atomic are opposites."** Atomic design is one way of naming what component-driven teams already do. - **"More levels resolve fuzzy boundaries."** Extra levels add more borders to argue over; they do not remove the judgement.

  • What does a team lose if it drops level names entirely?
    A shared vocabulary for scale and, often, the habit of testing whole screens. Without words like organism or template, discussions fall back on vague terms like big component, and without an explicit page level nobody is prompted to pour real content into the composed screen. Teams that drop the names usually need another routine to keep that screen-level check.
  • Would adding a sixth level between molecules and organisms reduce classification arguments?
    Usually not. Each new level adds another fuzzy boundary to argue over. The arguments come from the judgement involved in placing a growing component, not from too few buckets. A written heuristic and a decision log reduce them more reliably than finer categories.

saying these in an interview costs you the question

  • Renaming the atomic levels means the team is not doing atomic design.
  • Component-driven development and atomic design are opposing methods.
  • The chemistry names are the only valid vocabulary for component scale.
  • Adding more levels removes the fuzziness between molecules and organisms.
  • One taxonomy must serve design critique, governance and navigation alike.