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.
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:
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.
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."
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.
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:
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 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.
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:
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:
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.
Instead of chemistry-based categorization:
Use semantic, contextual names:
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.
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:
For example, when building a dashboard interface, you might combine:
This hierarchical approach, combined with semantic naming, creates a system that's both powerful and intuitive for teams to use.
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.
Raw values with descriptive names
Reference primitive tokens
Modern design systems typically include tokens for:
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.
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:
Benefits:
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.
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.
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:
Benefits:
In your design tool (whether Figma, Sketch, or Qt Design Studio):
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.
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.
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:
What Hasn't Changed:
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.
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:
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.