Atomic Design

When screens were the unit of design, every new feature meant drawing a screen from scratch. Draw it fresh each time and a button 40 pixels tall ends up sitting beside one that's 44 in the same product. Nobody notices at two screens. At sixty screens, one thing called a button exists in seventeen shapes.

Engineers hit the problem first. Theo would get a mockup and ask why the button on this screen is 40 tall while the one next door is 44, and whether both are correct — and the designer couldn't explain it either, because the difference wasn't intended. It came from the two screens being drawn on different days.

Atomic design reverses the drawing order to remove that. Start from screens and the pieces are a byproduct, reinvented each time. Settle the pieces first and building a screen becomes a matter of choosing from what already exists. Of the three parts of a design system — the elements, the method, and the governance — this word occupies the middle one. It says nothing about what to build; it says what order to build it in.

The names are borrowed from chemistry. Atoms combine into molecules and molecules into organisms; small pieces combine into large ones. There are five layers and the work climbs through them in order.

1. Collect what's already in use. Screenshot every existing screen and group the buttons with the buttons, the inputs with the inputs. This is where seventeen kinds of button become visible.
2. Settle the atoms. These are pieces that can't be broken down further — one button, one input field, one label. The color and spacing values those atoms use get named as design tokens and are referred to only by name after that.
3. Combine atoms into molecules. This is the layer where pieces that did nothing alone acquire a job. An input with a button attached becomes a search box; a label, an input, and an error message become one form field.
4. Assemble molecules and atoms into organisms. These occupy a whole region of a screen — a header with a logo, search box, and menu, or a list area filled with document cards.
5. Lay out a template. A frame that fixes what goes where without any real content in it. Repeating layouts like the document list and the settings page get their skeleton here.
6. Fill in real content to finish the screen. Real titles and real data arrive for the first time, which is where problems like a title over 40 characters breaking the line surface.

The six steps aren't a single pass. Something found at step 6 sends you back to step 2 or 3 to change a piece, and the changed piece lands in every screen using it at once. Fixing one piece and watching twelve screens change with it is the payoff the method is arranged around.

It fits products where the same shapes repeat. If there are dozens of screens and most of them are variations on a list, a detail view, and a settings page, the reuse rate after tidying the pieces is high enough to earn back the time. It also helps when several designers and engineers build different screens at once, because it gives them a shared name for the same object.

It fits poorly on an early product with five screens, or on promotional pages that look different every time. Two days spent organizing pieces that will never be reused are two days gone. The same goes for one person doing both the design and the code, since half the reason to name layers at all is to get several people calling the same object by the same word.

The friction usually shows up around the layer names. Whether a search box is a molecule or an organism, which layer an avatar-plus-name chunk belongs to — these arguments run long. The question has no correct answer, so the discussion never closes while the output stays identical. Plenty of teams cut the layers to three or rename them in their own words. Call them pieces, groups, and regions and the chemistry metaphor disappears while the build order survives intact.

Trying to climb strictly bottom-up is the other common snag. Decide on pieces without ever looking at a real screen and you find, at assembly time, that something needed is missing and half of what you built goes unused. Most teams start by roughly sketching two or three representative screens and pulling the pieces out of those.

"This doesn't need to go all the way to an organism. Leave it as a molecule, we'll use it elsewhere."

A proposal to cut the chunk at a reusable size rather than building it for one screen.

"I've blocked two weeks to sort out the atoms. New screens keep going the old way until then."

Separating the cleanup work from product work already in flight.

"Let's just use our own names for the layers. We've had two meetings this week about which layer something is."

The naming scheme has started costing more than it saves, so the team will hold it loosely.

At Pagedeck, Noa used this sequence for the first time while rebuilding the document editor. Pasting every existing screen onto one board turned up seventeen kinds of button and nine kinds of input. Filtering for the ones with an actual reason to look different left three buttons and two inputs.

Theo moved the tidied pieces into components and matched the names as he went. Once the names in the mockups matched the names in the code, Noa could say she had changed a molecule and Theo knew which file to open.

The most common misreading is that sorting things into the correct layer is the point. There are five names and the chemistry metaphor is vivid, so classification starts to look like the assignment. But the layers are a mnemonic for the build order, not a test to pass. Whether the search box is filed as a molecule or an organism, what reaches the screen is the same. Make classification the goal and every new part adds one more meeting, and the method takes back the time it promised to save.

The other frequent mistake is thinking that adopting atomic design produces a design system. The two come up in the same conversations, so one sounds like it contains the other. This is only a build order, though. Who may change a finished part, and when an exception is allowed, is nowhere inside it. Import the sequence without setting governance and the buttons are back up to ten kinds within six months. The only difference is that this time, thanks to the neat layering, all ten are filed as atoms.