I think of modular design as a practice or a philosophy—with Atomic Design being just one way to do it.

I’ve found that I’m able to benefit from Atomic Design concepts without always adopting its classification metaphor.

A couple of years ago, Paravel was kicking off a fairly large-scale design system project utilizing Pattern Lab. It served as a great proof of concept, but the team struggled to map components to an atomic classification, which made collaboration within the project difficult. We’d pause to re-calculate proper classification before talking about a component. This struggle with atomic classification also made difficult the task of explaining elements of the project to stakeholders, who then became preoccupied with making the metaphor work when we really needed to be talking about resources for next steps.

We bailed on the atomic metaphor, opting for a two-tier classification (like styles and components) that fed into templates and pages. The decision reduced organizational friction, and made the styleguide easier to use (navigate) on a daily basis.

We did, however,continue to benefit from concepts Brad Frost includes in Atomic Design. I can’t overstate how beneficial Brad’s writings and resources have been to our work. For example, the interface inventory we created for the project proved to be the crucial step in illustrating why a design system was necessary in the first place.

Here, Brad outlines his method for tackling modern web projects starting with atomic classification:

For as long as I’ve been talking about atomic design, I’ve had people proffer alternate names for the stages of the methodology. Person One would suggest “Why not just name them ‘elements’, ‘modules’, and ‘components’?” while Person Two would suggest “Why not just name them ‘base’, ‘components’, and ‘modules’?” The issue with terms like “components” and “modules” is that a sense of hierarchy can’t be deduced from the names alone. “Atoms”, “molecules”, and “organisms” imply a hierarchy that anyone with a basic knowledge of chemistry can hopefully wrap their heads around.

It’s key to note that Brad isn’t prescribing this as the only classification metaphor that works. Brad continues:

That being said, naming things is hard and imperfect. The names I’ve chosen for the stages of atomic design have worked really well for me and the teams I’ve worked with. But maybe they don’t work for you. That’s more than OK.

This seems to be the case with Jono Herrington’s team:

[The team] totally bought into the core concepts of Atomic Design but when it came down to what each of those components were called, it didn’t make sense to them. […]it was too hard to relate these different terms to the overall big picture.

What I so respect about that particular team is that even though they couldn’t pick up on all the terminology, they didn’t throw the concept out the door.

Jono’s team, like many, could still find value by pushing an idea beyond its plug-and-play state. If the atoms-molecules-organisms metaphor isn’t working for your organization, you don’t have to force it. Mandy Brown on a good metaphor:

No analogy holds when followed to the ends of the earth; it’s a tool whose power lies in suggestion—a fleeting kiss instead of a lifelong partnership.

⁂

Design systems and pattern libraries should be designed the way we design anything else—the content itself (patterns, components and the like) should inform the classification and organization of the system as a whole. Considerations should be made for how easily an organization might adopt, understand, and iterate upon a given system.

Choose names and classifications that make the most sense for the most people. It can be counter-productive if a team spends more time struggling with the analogy than designing and building the tool itself.

Alla Kholmatova wrote about FutureLearn’s challenges in differentiating molecules from organisms within the context of their content/patterns:

we’ve been struggling to understand exactly when a molecule is complex enough to become an organism, the defining difference between the two types, and even why we need both types in the first place.

Even after a year of working with atomic design there is still no clarity and shared understanding in our team about how interface elements should be classified. But maybe it’s OK. There isn’t always a “right” way to classify and organize things.

In situations like these, I’d imagine naming components could be included as part of the overall process early on. I love the naming exercise Charlotte Jackson outlines for A List Apart:

Generating ideas for component names as a team is a fantastic way to start developing a shared vocabulary.

Getting everybody involved makes the challenging tasks of naming things a little easier and encourages the team to continue using the same terminology after the exercise is done.

Atomic Design, like any valuable tool, resource, or concept, doesn’t have to be an all-or-nothing proposition. It’d be a shame to dismiss Atomic Design because every part didn’t instantly fit your situation. Likewise, it’d be a shame to blindly adopt all parts without taking on the task of working through what works best for the team.

Thanks to Dave, Reagan, Bonnie, and Ethan for feedback on this post.