Atomic Design Is Decomposition
Brad Frost parallel.
Brad Frost’s Atomic Design breaks interfaces into atoms, molecules, organisms, templates, and pages. Designers who use it think of it as a methodology for building component libraries. It is. But underneath the taxonomy, the actual operation is decomposition: breaking a complex whole into independent parts that can be built, tested, and composed without coupling.
I’ve been running that operation across every material I’ve touched since before Frost named it. In a self-contained classroom in Sunset Park, I decomposed compound instructions into single steps because a student couldn’t hold all four at once. On the Encore platform, I decomposed a monolithic Windows Forms application into a modular front-end: namespaced JS framework, SCSS design system, each layer independently testable. In the kitchen, I decompose a meal into components. Three bags in the sous vide, rice in the cooker, vegetables prepped separately. Each one firewalled from the others so a failure in one doesn’t cascade.
The Atomic Design vocabulary (atoms, molecules, organisms) gives people a way to talk about decomposition in the context of UI. That’s valuable. But the vocabulary also limits where people see the pattern. Decomposition isn’t a design system methodology. It’s a structural operation that applies to anything too complex to build or evaluate as a single unit.
When I evaluate work through the Formwork Protocol, each evaluation lens runs independently. The Vignelli-derived restraint lens doesn’t know what the Victore-derived identity lens scored. They measure different dimensions against different criteria. The coordinator collects the verdicts and maps where they agree and disagree. That’s decomposition applied to evaluation: break the assessment into independent layers, run each one on its own terms, then read the results together.
The pattern is the same at every scale. An IEP decomposes a student’s needs into individual goals, each with its own criteria and accommodations. A batch cook decomposes dinner into components that can fail independently. A print job decomposes an image into color plates, each screened and registered separately. The whole only exists when the layers come back together.
What Frost got right is that decomposition isn’t just about building small pieces. It’s about the composition rules: how atoms combine into molecules, how molecules form organisms. The interfaces between the parts matter as much as the parts themselves. My father knew this on construction sites. Fifty trades, each good at their piece. The joints are where the structure holds or fails.
Twelve years on Encore taught me the same thing. I could build any individual module cleanly. The hard part was the architecture that held them in relation: naming conventions that stayed consistent across hundreds of files, an SCSS system where component styles didn’t leak, a JS framework where modules could load and unload without side effects. The decomposition was the starting move. The composition rules were the actual work.
Anyone building a design system is already decomposing. The question worth asking is whether you recognize the operation when it shows up outside a component library: in your prompt architecture, your project management, your kitchen, your teaching. The pattern is older than Atomic Design. Frost gave it a vocabulary for interfaces. The operation itself is how I survive complexity in every room I walk into.