Is a button with an icon an atom or a molecule? If you've worked on a design system for more than a week, you've probably heard some version of this debate. It can eat a whole meeting. And when it's over, nobody finds anything in the library any faster.

Atomic Design is one of the most useful ideas in interface design, and also one of the most over-applied. Here's what it is, how it maps onto Figma, and where it's worth letting the metaphor go.

Where it comes from

Brad Frost introduced Atomic Design in a 2013 blog post and expanded it into a book, Atomic Design, in 2016. The whole book is free to read online. The core move is borrowed from chemistry: matter is made of atoms that combine into molecules and then into larger organisms, and interfaces are made of small parts that combine into larger ones.

Frost proposed five levels:

• Atom: What it is: Can't be broken down further without losing its function; Example: label, input, icon, button
• Molecule: What it is: Two or more atoms working together for one purpose; Example: search field = label + input + button
• Organism: What it is: A complete, functional section of an interface; Example: header = logo + navigation + search + avatar
• Template: What it is: The skeleton of a page, without real content; Example: an article layout
• Page: What it is: The template filled with real content; Example: the published article

Notice that only the first three are chemistry. When Frost gets to templates, he writes, "Now, friends, it's time to say goodbye to our chemistry analogy." The author himself treats the metaphor as a tool that runs out at some point, not as a law of nature. That's a good attitude to borrow.

Where the metaphor helps

The best part of Atomic Design isn't the five labels. It's the direction: you build from the bottom up, and you never duplicate downward.

In practice, a bigger piece should be assembled entirely from smaller pieces that already exist. When an organism seems to need a slightly different button, the question isn't "should I make another button?" It's "is the button I already have missing a variant?"

That one habit is what keeps a component library from turning into five nearly identical buttons, each with its own corner radius and its own shade of blue.

It also gives a team a shared sense of scale. Saying "that's an organism-level change" tells everyone the change touches a whole section, not a single input. That's handy in design reviews and even handier in handoff.

Where it breaks

Atomic Design is often taught as if it were an exact classification system. It isn't, and knowing that saves you a lot of pointless arguments.

The atom-or-molecule question has no useful answer. Is an icon button an atom (it's one clickable thing) or a molecule (it's an icon plus a button)? You can make a good case for either. Settling it doesn't make anything easier to find or maintain, so the debate is pure cost.

Templates and pages rarely separate in Figma. In code, a template and a page can be genuinely different things. In a Figma file, a "template" is usually a frame with sample content, and the "page" is the same frame with slightly more realistic sample content. Keeping two separate levels for that tends to add bookkeeping without adding clarity.

The level says nothing about function. If your library is organized as atom/badge, atom/avatar and atom/checkbox, those three things sit together only because they're small. A designer looking for a checkbox has to already know that you filed it as an atom. Grouping components by size is a bit like shelving a library's books by page count.

Think in levels, name by function

What many teams do, and what I'd suggest, is to use the hierarchy to think and to name by function in the file. Your assets panel ends up looking like this:

btn/primary

btn/secondary

input/text

input/search

card/product

nav/header

Anyone can find the search input without knowing which level it lives on. Meanwhile, the bottom-up discipline stays exactly the same: the header is still built only from pieces that already exist.

This is a legitimate choice, not a watered-down version of Atomic Design. The value was always in the order of construction, not in the folder names.

Building bottom-up, step by step

Here's the order for building a header in Figma. It's worth sticking to it instead of jumping straight to the end.

1 · atoms logo · icon · label · input · avatar

2 · molecules search field · navigation item · user menu

3 · organism header (horizontal auto layout, gap Auto, padding from variables)

4 · template a page frame with the header and a content placeholder

The point is this: when you reach step 3, you shouldn't need to draw anything new. The header should be nothing but instances of components you already have, arranged with auto layout. If you catch yourself drawing a shape, an atom is missing. Go back, make it a component, and continue from there.

This is also where Figma's newer component features help. Variants and component properties let one button cover its sizes, states and icon options, so "I need a slightly different button" almost always has an answer that isn't a new component.

The system test

Here's a simple way to check whether you've built a system or a collection of drawings.

Open the main component for your text input and change its corner radius from 4 to 12.

• If the search field, the header, and every screen that uses them update on their own, you have a system.
• If you have to go screen by screen fixing corners, you have a folder of drawings that happen to look alike.

It takes ten seconds and it's more honest than any audit spreadsheet. Run it on a real project, write down every place that didn't update, and you've got your to-do list for the week.

Further reading

• Brad Frost, Atomic Design (2016), free online at atomicdesign.bradfrost.com. Chapter 2 covers the methodology.
• Hugo Villarreal, "Understanding 'Design Systems'" (2025), a historical introduction to design systems for UI designers who are just starting.