Atomic design is widely referenced when discussing design system organization, but is it the ideal solution for every modern system?
Brad Frost introduced atomic design all the way back in 2013, and I was an instant fan. You wouldn’t know it from how I talk about atomic design today, but I am still a fan. When I’m planning design systems work and defining how we organize our many components, you will hear me firmly say, “no atomic design.” That doesn’t mean I dislike it—atomic design gave us a framework for building and organizing reusable components for websites and applications. I just don’t think it’s practical as-is for modern applications and design systems.
Where Atomic Design Falls Short
I do appreciate all of the benefits that this shift in thinking has brought to the industry, but it does feel like a one-size-fits-all solution that doesn’t quite work for all projects. The lines between what is an atom, molecule, etc. are too fuzzy, leading to confusion about how to categorize design system components. Every time I have worked on a design system that uses an atomic design structure, there are always a handful of components that straddle the line between two categories.
Take icon buttons, for example. Are they atoms because they are a button variant or are they molecules because they contain an icon component, which is itself an atom? There is always confusion about where to place these components, and when there are multiple items in question, they often end up being categorized inconsistently. The icon button that contains an icon atom is also classified as an atom, while a card component that contains only a button atom is categorized as a molecule. The rules for categorizing are subjective, which means everyone is going to have a different definition.
A Better Approach: Start with a Flat Hierarchy
The reason I think atomic design falls apart in practice is because we are trying to abstract things too soon. There is no telling how components will need to be structured until we start using them and allowing the system to evolve. My suggestion is to start with a flat hierarchy, where all components are treated equally—no atoms, no molecules, just components.
That flat hierarchy isn’t permanent, though. The code we write is never set in stone and it should be iterated on. The same goes for the way in which we architect our code. When we start to experience pain points working with the flat hierarchy, that’s when it’s time to evolve our system. Evaluate what you have and what your pain points are, and start getting creative in how you organize things.
If you find you have some very clear foundational components that have regularly been used to build more complex components, then you have two clear categories of components. These categories just need clear rules defined to allow new components to be organized within them. And when that structure starts feeling too rigid, it’s time to reevaluate and adapt again.
Conclusion: Iteration is Key
Like I said before, I do like the idea of atomic design. It gave us an important starting point for thinking about component-based systems, but it’s not the end-all solution. Instead of forcing your components into a premade, one-size-fits-all architecture, you should instead start simply, with a flat hierarchy that allows for more flexibility and gives you room to iterate based on real-world use. The key to building an effective design system isn’t to adhere to a rigid framework, but to continuously evolve your structure as your needs change.
