Atomic design helps developers think of UIs as a collection of components and allows them to break entire interfaces down into fundamental building blocks and build up more consistent UIs.

So, in this article, I will help you understand atomic design concepts and adapt them to modern-day development.

A quick intro to Atomic Design

The primary usage of atomic design is for design systems. It brings the 5 simple ideas from chemistry to web development: atoms, molecules, organisms, templates, and pages. The advantage here is that the terminology is self-explanatory.

1. Atoms:

Atoms are the basic building block of anything. So, in web development, primary elements like HTML tags, labels, buttons can be considered atoms.

The important thing here is, you have to analyze the context of your product and come up with Atoms. For example, you might define an Atom for Aviator with variant property supporting square and circle images.

2. Molecules:

They are more tangible and can identify as a group of Atoms bonded together. Thus, molecules serve as the backbone of the design system. And a composition of a search box and a button can be considered as a Molecule.

And, whenever we need to use a search, we can reuse this component keeping a consistent look and feel across the application.

3. Organisms:

An organism is a combination of Molecules and Atoms to build a little complex, distinct component. For example, a header or a footer with buttons and a logo can be considered an organism.

The difference with a Molecule is that it will also manage the state and become fully functional as a unit.

4. Templates:

Templates as the name suggests, are reusable collections of Organisms, Molecules, and Atoms put together. Therefore, they are more concrete.

For, example if you are building a blogging website, you will probably build a template for blog articles with a header, post, comments, and footer which is uniform across blog articles.

5. Pages:

They are the highest level of fidelity since users recognize them with distinction. Typically the URL also might change, when moving from one page to another.

And, the page might contain, one or more templates depending on how you arrange the layout.

Building Components from Scratch?

But, as you all know, we hardly use pure HTML elements with custom CSS these days. Instead, UI libraries and CSS frameworks give the essential elements that act as the foundation.

Besides, these UI libraries provide theming support that cuts across the entire design system.

So, when adopting Atomic Design terminology, we need to consider how it will co-exist with these Libraries and Frameworks.

Evolving the Atomic Design into Modern Context

Let’s start with a question that comes up quite often. Are the following elements Atoms? The example is from Material UI.

Some of you might argue that they are Atoms, but it is too generic to call it like that. Furthermore, using these generic components will defy the purpose of keeping the UI consistent.

So, what can we do to make it more tailored for your design system?

• We can start by identifying the variants we are supposed to allow in our Design system for Atoms (e.g., Button). Maybe, we will pick two variants like “Filled” and “Outlined” and two sizes. That’s all.
• And, it’s also essential that there is only one Atom called Button with variants and properties (like size). Otherwise, if we have XButton, YButton, RoundButton, and there will be too many Atoms, developers have to spend more time figuring out their names and searching for them. So, having a single Atom for Button will help developers use it and peek into the properties to understand its different configurations.

More into Theming

We are talking about a consistent visual design that cuts across all the application components when it comes to theming. Therefore, these configuration needs to be handled centrally.

Does the challenge come in defining them at Atoms, Molecules, Organisms, or a different level? The answer is straightforward, where we determine the theming outside these components. Modern UI libraries like MaterialUI also support it.

<ThemeProvider theme={theme}>
  <CustomCheckbox />
</ThemeProvider>

We can customize the properties of the theme at a higher level.

import { createTheme } from '@material-ui/core/styles';
import purple from '@material-ui/core/colors/purple';
import green from '@material-ui/core/colors/green';

const theme = createTheme({
  palette: {
    primary: {
      main: purple[500],
    },
    secondary: {
      main: green[500],
    },
  },
});

Since each component inherits the theme, if we want to customize it unique to our application (e.g., Button), we can override the properties that come from the theme at the Atom level.

What about the naming of Components?

The next question comes in, should we rename the components available in UI libraries to have the naming convention of Atoms, Molecules &, etc.

For example, you can define your ButtonAtom with limited properties by wrapping the Button component that comes with MaterialUI as follows;

Though it will limit the Button’s properties, in my opinion, it will make things more complex since you have to wrap the original components by your component writing more code. Better to stay away from this approach.

So, far so good? What’s next after creating your design system?. How should we share it across projects?

Sharing the Design System

One of the common challenges after creating your design system is to make it sharable across projects. For example, building a large NPM package to share the design system code becomes challenging to see the modifications at lower levels. Besides, whether you use it or not, you have to install the entire design system to your project without having the ability to pick and choose components from the design system.

You can argue that when using TypeScript with Webpack, tree-shaking will remove the unused code. But, in practice, it’s not always perfect. So, we need tools that are built on sharing design systems across projects.

Using Bit instead of NPM

Bit fills this void by allowing you to source control components at a granular level like Atoms individually. And, it offers a feature called ‘Compositions’ where you can visualize how your Atoms, Molecules, Organisms look like to test them manually.

You can write automated testing and evaluate the tests at each component level. That way, you can test your component in future integrations before combining it with your application code.

Conclusion

As I explained throughout this article, component libraries and Atomic design can work hand in hand.

It’s also essential to understand the terminology and use them in your design system. As long as you have the proper abstraction levels, it becomes easier to communicate across design and development teams, building consistent UI across projects.

And Atomic design gives an excellent example of terminology to structure your design system with a purpose.

Thank you for reading !!!