The overall journey of interacting with and building design systems has been one of the most valuable learning experiences for me as a Designer. Over the past few years, I’ve worked on and used multiple design systems, right from the more popular ones like Material UI, IBM Carbon, and Ant Design to custom component libraries. In the past, I’ve mainly used UI audits to guide me through the process of building design systems. Recently, however, while working on a large-scale product, I stumbled across the Atomic Design methodology. It’s safe to say that it changed how I approach Design systems. Here’s everything you need to know to adopt Atomic design for your next project.

What is Atomic Design?

The Atomic Design methodology created by Brad Frost is a design methodology for crafting robust design systems with an explicit order and hierarchy. As the name suggests, it’s derived from a basic chemistry concept; the composition of all matter. To understand atomic design better, we’ll need to brush up on some basic chemistry concepts quickly.

Something we’ve all learned in our high school chemistry class is that,

All matter is made up of tiny particles called Atoms.

If we want to dive one step deeper, an atom itself is made up of subatomic particles: protons, neutrons, and electrons holding positive, negative, and neutral charges, respectively. But overall, we can break down all matter to its lowest level, an atom.

To explain this better, let’s take the example of Water or H2O. The chemical equation suggests that it contains 2 atoms of Hydrogen and 1 atom of Oxygen; both are independent by themselves. But, when combined together, we get a single molecule of H2O, or what we refer to as ‘water.’

Brad Frost’s atomic design methodology is based on this exact chemistry principle and is applied to design systems. The Atomic Design principle focuses on breaking down interfaces into smaller components called atoms. These atoms then act as building blocks for all the other components throughout the design system. While it may seem like an easy task, it can get complicated pretty quickly, depending on the size of the project you’re working on.

Elements of Atomic Design

Just like matter, we can hierarchically organize components in a design system into various levels depending on their construction and complexity. While the standard Atomic Design principle by Brad Frost has five layers, I prefer using the modified version with an additional layer as it makes formulating design decisions better.

The levels of atomic design are as follows:

1. Subatomic particles
2. Atoms
3. Molecules
4. Organisms
5. Templates
6. Pages

Let’s discuss them in detail

To better understand each of them, I’ll use some screenshots of the Spotify iOS application and break them down.

Subatomic particles

The subatomic particles would be the bare-minimum foundational elements you’d need for all your components. These consists of elements like your color palette, typography, shadows, and spacing. If you’re familiar with the Lightning design system by Salesforce, you can think of these as design tokens created by Jina. I reference her quote here in which she explains these tokens, sub-atomic particles, style guides, or whatever you prefer.

“Design Tokens are the visual atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard–coded values in order to maintain a scalable and consistent visual system.”

Spend a good amount of time with this because these will heavily influence your design system and, subsequently, your products. Ideally, you’d want to define these even before you start working on the actual components themselves. Doing so would pave a well-defined path for your entire design team to follow. I’ll have detailed articles on these coming up soon, so watch out for that.

Atoms

Now that you’ve laid down the foundation, it’s time to focus on the Lego blocks of your interfaces. Like chemistry, atoms in design systems are the smallest elements that cannot be broken down further. These include things like buttons, input fields, switches, etc. Like legos, you can combine these components to build bigger, better things. Atoms take in all the properties defined in the previous step with very little to no customization on top of it to ensure consistency. So, if you’re using a tool like Figma, you’d choose the colors from the styles panel instead of the color picker.

Molecules

Climbing one level above, we get molecules that are combinations of multiple atoms. A great example I can think of in this case would be the card element; it usually would consist of an image block, some text, and a call-to-action button. The atoms that these cards consist of, exist independently, but when combined, we get a molecule that is slightly more advanced and has more layers of complexity.

Organisms

These are the highest complexity levels of any given interface component. Organisms can be tricky to identify because they consist of multiple molecules; sometimes, these are entirely different, and sometimes the same molecules are repeated multiple times. The header, menu bar, data grids, etc., are the commonly defined organisms in most design systems I’ve interacted with. In the case of Spotify, we can see how the popular section consists of multiple music title molecules.

Templates

Now that we’ve defined all our components, it’s time to specify the structural layout of the interface itself. Templates in design systems help define a standard page layout across multiple pages with similar functionality. Put simply, templates are standardized layouts for organizing atoms, molecules, and organisms across your product.

Taking the time to standardize your page layouts goes a long way toward improving product consistency and reducing code redundancy. If we look at the product page for any eCommerce website or any artist’s profile on Spotify, we can see they all have a similar structure. This is great because users don’t need to familiarize themselves with new layouts every time, and developers can dynamically generate page content without having to rewrite code repeatedly. It’s a win-win situation for everyone involved and is worth spending time on.

Pages

I like to think of templates as the skeletal structure and pages as the flesh on top. Pages in atomic design are instances of templates in your user interface but in high fidelity. Pages are what your users will see in the finished product. Pages take on multiple template forms and help designers think about the different states our base atoms and molecules would acquire. Using Spotify’s example again, let me illustrate how that happens.

The image above compares two different artist profiles on Spotify. Based on the user selections, the molecules and atoms take on different states; some acquire the hidden state, while others render the empty states. Pages can also have some organisms hidden or missing, but the page’s overall structure remains the same for the most part.

Defining pages is one of the most critical steps in constructing a robust design system, as it helps us evaluate the construction of the design system itself. If you find yourself constantly ‘customizing’ at the page state, it’s time to go back to your base atoms and molecules to fill in the gaps.

Answering some common questions

How do I apply Atomic design principles to an existing product?

• The underlying approach stays the same; however, you’d need to build an inventory of all the components in your existing application. Building an inventory usually starts by conducting a UI audit with multiple stakeholders involved. I plan on elaborating on this in a future article. But to briefly explain, once you have a list of components, you can start by combining multiple variants and using the guiding principles above to navigate the process of building your design system.

I’m not currently building a design system; how do I apply what I’ve learned here?

• Atomic design principles at its core is a mental model. It’s a lens through which you start observing and evaluating the interfaces you interact with daily. It’s a skill you need to develop as a designer to collaborate better with developers. Modern applications are built using a component-based approach, and chances are your developers will start to get frustrated if your designs have a new component for every different page. Even if your organization isn’t at a stage where they need a design system, you could start evaluating your designs through the atomic design lens. Doing so would greatly help reduce the design debt your team would need to tackle when they start building a design system.

What software/tools would I need to learn to apply Atomic Design to my next project?

• Figma is what I personally use but even Sketch or Adobe XD all support building components. If you’re a designer, chances are that you’re already familiar with these tools. The primary skills you’d need to learn here are to create Figma components, add properties and create component variants. These are relatively easy to learn using guides on Figma’s website. However, something that will take time to master is mapping out all the possible variants for your components. You’ll improve at this over time as you collaborate more with your developers. Additionally, there are plugins in Figma, like the Design system manager, which simplify the task of maintaining an atomic design-based design system.

Read full article here on:
https://blog.kamathrohan.com/atomic-design-methodology-for-building-design-systems-f912cf714f53