Atomic Design Systems: Why the Labels Don’t Matter

Atomic design systems have emerged as a methodology for creating scalable and maintainable user interfaces. This comprehensive guide explores what atomic design is, examines whether atomic design is still relevant in 2025, and reveals how atomic design principles can be adapted beyond their original chemistry metaphor. Drawing from a decade of industry experience and direct insights from Brad Frost himself, this article provides practical guidance for implementing modern design systems that prioritize clarity, maintainability, and production readiness over rigid categorization.

What is Atomic Design? Understanding the Core Concept

To answer the fundamental question "what is atomic design?", we need to look beyond the surface-level chemistry metaphor. Atomic design, introduced by Brad Frost in 2013, is a methodology for creating design systems that emphasizes hierarchical composition: the practice of building complex user interfaces from smaller, reusable components.

The atomic design principles originally proposed five distinct levels:

• Atoms: Basic elements like buttons, inputs, labels
• Molecules: Simple components combining atoms
• Organisms: Complex components combining molecules and atoms
• Templates: Page-level layout structures
• Pages: Specific instances of templates with real content

While these categories provide a useful mental model, as we'll explore throughout this article, the specific labels have become less important than the underlying principle they represent: systematic, hierarchical thinking about interface construction.

For those wondering: "Is atomic design still relevant in 2025?", the answer is a definite yes. But not in the way you might expect. Modern implementations have advanced beyond strict categories to adopt more flexible, semantic approaches that better support contemporary development workflows.

The Categorization Trap: A Personal Journey

When I first started building UIs and Design Systems, like many designers before me, I’m sure I searched the internet for “How to build a design system”.  This led me to find Brad Frost’s blog and E-Book on Atomic Design. However, I made a mistake that I have seen countless other designers make throughout industries.  I tried to follow Atomic Design literally.

This literal interpretation is the reason for endless debates about categorization. Was a card component a molecule or an organism? Did a button group qualify as a molecule? These discussions, while intellectually engaging, often detracted from the real work of building effective design systems. As I would later discover, this focus on rigid categorization was missing the forest for the trees.

Why do I know it is a mistake?

The answer came directly from the source. I emailed Brad Frost and asked him: "10 or so years later, do you still think Atomic Design is the right approach?  I often find myself struggling to find a need for Atoms and often end up creating a system of controls and tokens."

Brad Frost’s revelation: Labels Were Never the Point

His response was enlightening: "The specific labels (atoms, molecules, organisms, templates, and pages) have never been the point, and we don’t really use them in our work.  But they’re still useful as a mental model."

This revelation sent me back to his original book, where I found this crucial passage in the final section:

"Atomic design" as a buzzword encapsulates the concepts of modular design and development, which becomes a useful shorthand for convincing stakeholders and talking with colleagues. But atomic design is not rigid dogma. Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system. - Brad Frost

This statement fundamentally reframes how we should approach atomic design systems. Rather than getting caught up in whether something is an atom or a molecule, we should focus on creating a taxonomy that serves our team's specific needs and enhances communication. This flexibility is what makes atomic design principles enduringly valuable, even as our tools and workflows continue to evolve.

What Atomic Design Principles Actually Teach Us

Beyond the chemistry metaphor, Atomic Design teaches us several fundamental principles that remain crucial for modern design system development.

The point isn’t about categorizing components into atoms, molecules, and organisms. It’s about understanding hierarchical composition – how smaller building blocks combine to create larger, more complex structures.

The real lesson: nest components in other components. That’s it. That’s the core idea. But this simple concept has profound implications for how we structure our design systems:

1. Modularity: Every component should function independently while also being able to combine with others.
2. Reusability: Build once, use everywhere, reducing technical debt and maintenance burden.
3. Consistency: Single source of truth for every pattern ensures visual and behavioral consistency.
4. Scalability: New features can be built from existing components, accelerating development.

The above diagram illustrates hierarchical composition in atomic design systems, showing how smaller components nest within larger ones to create complex interfaces. Source: Brad Frost - Extending Atomic Design.

Understanding these principles leads us to a more practical question: if not chemistry labels, then what naming convention should we use?

The Solution: Semantic Systems Over Atomic Design Labels

The evolution from abstract chemistry categories to semantic systems represents a maturation of the atomic design methodology. Instead of forcing components into abstract chemistry categories, modern design systems use purpose-driven, semantic names that reflect what components do and where they’re used.

What is a Semantic System in Design?

A semantic system in design is a methodology where every element's name directly communicates its meaning, purpose, and behavior within the interface. Unlike abstract categorization systems that focus on structural complexity (like atomic design's chemistry metaphor), semantic systems prioritize human understanding and practical application.

Think of it this way: when you encounter a component named Modal.Warning.SpeedLimit, you immediately understand three things:

1. What it is: A modal dialog
2. Its purpose: To display warnings
3. Its specific context: Related to speed limits

This instant comprehension is the power of semantic naming. Compare this to finding a component labeled Organism_7. You'd need to inspect the component or consult documentation to understand its purpose.

Semantic systems transform how teams collaborate:

• Developers can immediately identify which component to use without diving into documentation
• Designers can communicate their intentions clearly through component names alone
• QA teams can trace issues more effectively when component names reflect their function
• New team members onboard faster when the system is self-documenting
• Stakeholders can participate in discussions without learning abstract terminology

From an architectural standpoint, semantic systems create a direct mapping between user mental models and system implementation. When a designer thinks "I need a warning about speed limits," they look for exactly that, not for a "large molecule" or "complex organism." This alignment between thought and implementation reduces cognitive load and accelerates development.

Components Naming Examples

Instead of chemistry-based categorization:

• Atom: Button
• Molecule: Button Group
• Organism: Navigation Bar

Use semantic, contextual names:

• Button.Primary
• Button.Secondary
• Button.Disabled
• Navigation.Main
• Navigation.Settings
• Header.Global
• Modal.Warning
• Card.Status

This approach works especially well for specialized industries with safety-critical requirements. For instance, in automotive HMI development, when you need to trace component usage for regulatory compliance, Modal.Warning.SpeedLimit is far more useful than Organism_7.

Hierarchical Building Blocks in Practice

Here’s what hierarchical composition looks like.

Smaller components (on the left) are nested into a larger component (on the right). This is hierarchical composition in atomic design systems.

When we think about our design in terms of hierarchical building blocks, we:

• Design with intention - Consider where and how something will be used
• Create reusable components – Build once, use everywhere
• Maintain consistency – Single source of truth for every pattern
• Communicate clearly -  No time wasted on categorization debates

For example, when building a dashboard interface, you might combine:

• Base components (buttons, inputs, labels)
• Composite components (forms, cards, data tables)
• Layout components (grids, containers, navigation)
• Page templates (dashboard layout, detail view, list view)

This hierarchical approach, combined with semantic naming, creates a system that's both powerful and intuitive for teams to use.

Design Tokens: The Foundation of Modern Atomic Design Systems

Design tokens are named properties that define visual design attributes. When Frost created Atomic Design over ten years ago, tokens weren’t standardized. They’ve since become essential to modern atomic design systems, providing the foundational layer that makes components truly reusable and themeable.

Instead of hardcoding values like #3B82F6 or 16px throughout your designs and code, you create tokens like color.primary.active or padding.md that represent these values. This creates a single source of truth - just like your master component.

In programming terms, tokens are global variables used to define all colors, spacing, typography, and any building block property of a component. They form the foundation of any modern atomic system design, enabling consistency at scale.

Setting up a token system

Primitive Tokens (Foundation)

Raw values with descriptive names

• blue_500: #3B82F6
• neutral_800: #1F2937
• spacing_L: 16px
• spacing_XL: 24px

Semantic Tokens (Contextual)

Reference primitive tokens

• color.primary: blue_500
• color.text.default: neutral_800
• color.text.inverse: neutral_000
• spacing.button.padding: spacing_L
• spacing.card.gap: spacing_XL

Token Categories

Modern design systems typically include tokens for:

• Color – Brand, semantic, text, background, border
• Spacing – Padding, margin, gap
• Typography – Font family, size, weight, line height
• Layout – Grid, density, breakpoints
• Effects – Shadow, blur, opacity
• Motion – Duration, easing, delay
• Semantic names – Success, warning, error, info
• Theme modes – Light, dark, high contrast

The W3C community has been standardizing design tokens since 2019.

A graphical representation of the design system at Qt, showing how things come together with the use of tokens.

Why Primitive Tokens Matter

Primitive tokens provide an added layer of control. For color tokens, you’ll have primitives for Black and White that get assigned to multiple semantic tokens (Background Color, Text Color, Stroke Color).

Primitive tokens are essential for theming:

• Your primitive tokens remain constant across themes
• Your semantic tokens change to reference different primitives per theme
• When you adjust your neutral color tint, you update one primitive token
• All semantic tokens that reference it update automatically

Benefits:

• They save time – Change once, update everywhere across your entire design system
• They create consistency – No stray values or one-off colors breaking visual harmony
• They enable validation – Spot raw values that should be tokens
• They supports accessibility – Ensure color contrast ratios meet WCAG standards
• They facilitates white-labeling – Quickly rebrand applications by updating token values

Design token architecture diagram showing primitive neutral color tokens mapping to semantic tokens that switch values between Light Mode and Dark Mode themes, demonstrating how a semantic system references different primitives for theming.

Templates & Pages: Atomic Design Principles That Still Work

While the atomic labels may have become less relevant, templates and pages remain, in my opinion, the most valuable parts of Atomic Design’s original framework. These higher-level constructs bridge the gap between component libraries and actual product interfaces.

What is a Template in Atomic Design Systems?

Templates are page-level layout structures that lack actual content.  They show where components go and how they’re arranged, but use placeholder content (lorem ipsum, gray boxes and FPO images).

Template layout showing placeholder content areas and component positions without real data. Source: Brad Frost's Atomic Design.

Template Components contain:

• Header component (actual component)
• Navigation component (actual component)
• Content area with layout grid
• Placeholder content using text styles

Benefits:

• Templates ensure consistent layout properties throughout flows
• They maintain structural integrity when content changes
• They keep all components linked to your library
• They speed up page creation with proven layouts

Use Templates to Create Pages

In your design tool (whether Figma, Sketch, or Qt Design Studio):

1. Use an instance of the template component
2. Swap placeholder content for real data
3. Layout structure stays intact
4. Components remain linked to library

Pages are your full screens with real content. If you have 10 screens sharing the same header and footer component, create a page template as your base. This approach ensures consistency while dramatically reducing the time needed to create new screens.

The QML Advantage

This process can be difficult in design tools like Figma that restrict what you can do with component instances. In QML (Qt Meta-Object Language), I can expose any property or object needed for full customization, eliminating the need for complicated instance swaps.

For example, rather than componentizing every icon for instance swapping, a developer can expose (or “alias”) the image source property.  Designers can then change it on demand without creating dozens of component variants.

This flexibility matters for automotive HMI work where safety-critical components need extensive customization while maintaining their core behavior and validation status. When working with Qt for Embedded Devices or developing interfaces that must meet ISO 26262 standards, this level of control becomes essential.

The QML approach to atomic system design offers several advantages.

• Property exposure: Any property can be made configurable without breaking encapsulation.
• Type safety: Strong typing ensures components are used correctly.
• Performance: Compiled QML provides superior runtime performance.
• Debugging: Clear component hierarchy makes issues easier to trace.

Is Atomic Design Still Relevant?

To directly answer the question, "Is atomic design still relevant?" - absolutely, but its relevance has evolved.

The core principles of atomic design remain fundamental to building scalable design systems in 2025, even as the specific implementation details have matured.

What Has Changed:

• Labels are flexible: Teams use naming conventions that make sense for their context.
• Tokens are essential: Design tokens have become the foundation layer Frost's original concept lacked.
• Tools have evolved: Modern design tools better support component-based workflows.
• Automation has arrived: AI and automation tools can help generate and maintain atomic components.

What Hasn't Changed:

• Hierarchical thinking: Building complex interfaces from simple, reusable parts.
• Systematic approach: Consistency through centralized component management.
• Modular architecture: Components that can be mixed and matched.
• Clear communication: Shared vocabulary for discussing design decisions.

The question isn't whether atomic design is still relevant, but rather how to best adapt its principles to your team's specific needs and toolchain.

The Bottom Line

Atomic Design’s labels were never the point. The methodology teaches us to think in hierarchical building blocks and modular composition – that’s what matters. After years of implementation across various industries and platforms, this core insight remains the most valuable takeaway.

As design systems evolve, the tools we use must support modern workflows: semantic clarity over metaphorical categorization, token-driven consistency, and flexible component architectures that serve both designers and developers.

For your next design system:

• Skip the categorization debates, think instead about what makes sense for your team.
• Use semantic, purpose-driven naming, so that components are self-documenting.
• Build comprehensive token systems that put tokens as your foundation.
• Create flexible templates that balance structure with customization needs.
• Focus on what matters: building consistent, maintainable, production-ready interfaces.

The right question isn’t: “Is this an atom or a molecule?”

The right question is: “Does our system help our team build better products faster?”

In the end, atomic design systems succeed not because of their chemistry metaphors, but because they provide a systematic approach to managing complexity. Whether you call them atoms, components, or building blocks, the principle remains the same: thoughtful, hierarchical composition creates scalable, maintainable design systems that stand the test of time.