Table of Contents
Creating scalable and maintainable CSS is hard. On the other hand, it is very easy to create bloated stylesheets nobody can understand. Atomic design might be one way we can deal with it. In this article, we will take a look at this methodology, its benefits and basic structure. My goal for this article is to provide you with sufficient amount of information so you can implement atomic design methodology into your own project and workflow. Give it a try and see it for yourself.
Why you should start using atomic design
One of the arguments against atomic design is that it is too complex. A number of web designers are hesitant to try this approach because it simply looks too time-consuming. For this reason, it will be better if we start this discussion by talking about the pros of atomic design. The strongest argument for implementing atomic design is that it provides you with a clear and consistent methodology for building robust design systems. It doesn’t matter who your clients is or how many team members you have to work with on the project.
When you start using atomic design, you will be able to present your client and team with something that is more concrete and tangible. Common design concepts are often too vague and hard to understand for people outside the design industry. How often have we heard about communication issues between designers and developers? This is one of the biggest issues we as web designers have to deal with. Our clients and other project stakeholders often see our work as some kind of magic or creative exercise. Atomic design makes our work more concrete.
Focus on re-usability
Atomic design allows us to take complex design systems and break them down into smaller components called atoms. Then, it is much easier for everyone involved in the project to see what parts of the site can be reused. It is also much easier to see how these atoms can be mixed together to form molecules, organisms and so on. Then, we can create complex and scalable systems just by duplicating and combining these elements.
What’s more, it doesn’t matter how complex the system will become, we will sill be able to keep track of what is being used and where. This reusable nature of atomic design elements helps us create systems that promote consistency while positively impacting the degree of its scalability. As a result, we can start building the system from the ground up instead of trying to deconstruct the system and look for underlying patterns.
Creating style guides is much easier
Let’s say you’ve just built new website. Now, your client or employer will ask you to create style guide for it. If you used atomic design, you can use all the atoms, molecules you created during the building process as a basic style guide. This will save you a lot of time because you will only have to put all the elements into one document and hand it over to your client or employer. If you didn’t build the website with this atomic approach, creating style guide will be much more difficult.
You will have to deconstruct the website into smallest components. Then, you will have to find out where and how are these components reused. Finally, you will have to put them together again to construct more pages for the website. As you can see, it is much better to build design system using atomic approach right from the beginning than to try to adapt the website to it later.
Clearer and more consistent code
One of the ways to reduce performance of the website and the development itself is by duplicating the code. When we use common approach, it is quite easy to use the same snippets of code thorough the project. It is no wonder that the code is bloated and website is slow. What’s more, it is also sometimes hard to make changes because there is some CSS or JavaScript code somewhere that’s constantly overriding our changes. Then, refactoring or debugging becomes a nightmare.
Use atomic design and everything changes in an instant. Building of a site with atomic approach involves the use of predefined components such as atoms and molecules. Direct results of this is that it is much easier for you to see which component is used and where. This significantly reduces the probability that you will accidentally duplicate some code. Also, code created atomically helps you make changes in the global scope easier because you are reusing the same component.
Let me give you one simple example. Imagine you’ve built a website without using atomic design. One day, your employer or client will ask you to add one green button to specific page. Sounds simple right? Actually, it might be a little bit more difficult. Why? You will have to look through the whole website to see if there is already such a button. If so, you can just copy and paste the code. Otherwise, you will have to create new one. With Atomic Design however, it is easy to go back through the list of atoms and find that exact red button.
More efficient and faster workflow
One of the great benefits of atomic design is that it helps you prototype design concepts quickly. Instead of thinking about how could the design look like, you can pick the elements you need for the page and put them together to see it. What’s more, when you enhance your workflow with atomic approach you will be able to deliver to your clients concepts they will understand. Then, it will be much easier for you to explain individual parts of the design and also make adjustments.
The ability to make quick adjustments is probably one of the best things on atomic design. The fact is that design process is something that’s highly iterative. Personally, I’ve never worked on design project that would start with just one wireframe, continued to one design concept that would be later coded. Design process is never a straight line. It is often more like a network full of many branches, dead ends and sudden sparks of inspiration. In this sense, design process looks like playing a pinball. It is full of trials, errors and adjusting the concept along the way.
This is why it is important to say when you work with these atoms, molecules or organisms, it is much easier to make smaller or bigger updates and adjustments. Atomic design makes it is easy to update any component across the whole site. The same is true for situations when you decide to delete the component. When you create component atomically, you know where the code is stored. Therefore, it is much easier for you to remove it.
Atomic design and the question of complexity
The biggest downside of adopting atomic design is that it may look too complex. This will be probably major issue for web designers who lack experience with more complex CSS and Sass systems or architectures. Let’s say that until now you’ve been working with one, two or three stylesheets at max. Now, I will show you Sass folder with twenty or more files. You are not used to something like this. Feeling very uncomfortable or overwhelmed is completely normal.
My experience of adopting atomic workflow
This is at least how I felt the first time I tried atomic design. Before that, I worked with about twelve Sass stylesheets. This workflow was based on SMACSS architecture and I was generally using base, layout and module stylesheets. That was all. Now, I was supposed to split these stylesheets into even smaller components such as atoms. As a result, I often ended up with more than twenty or even thirty sass files. It took me a couple of days to get used to it.
I have to admit that in the first moment, my resistance was quite strong. Fortunately, I am a little bit of a control freak and I used this need for control to motivate myself atomic design. On one hand, working with dozens of components can seem overwhelming. On the other hand, it gives you significant amount of control over the project. The key is to orient yourself in the structure of the project. Then, it is actually incredibly easy to find anything you need.
Let me give you one simple example. You need to make some adjustments and remove some styles from buttons. Then, the only thing you need to now is that button by itself is atom. When you know this, you will simple go to atoms folder and there you will quickly find stylesheet for buttons. The same applies to any other component. If you want to restyle forms, you will go to molecule folder. In case of header or footer, the organisms folder will be the right place to go.
So, is atomic design complex? Yes it is. You can quickly get into situation where you will have to manage more files than you could imagine. However, the upside is that it gives you significant control over the project.
Atomic design and its structure
You know the pros and you also know about the problem with complexity. It is only up to you to decide if you try to implement atomic design into your project workflow and management. Before you make your final decision, let’s take a look at the structure atomic design promotes. I have to mention one thing. The structure outlined on the following lines is not the “default” version as Brad Frost created it and promotes it.
I made a couple of adjustments in the form of adding two new layers. The purpose of these changes was to make this architecture a better fit for my style of work and also for using Sass. The first layer is dedicated to sass. The second layer is called base and we will discuss them as first. One last thing I want to mention is that when we will discuss the layers of atomic design, please keep in mind that we are talking about folders or directories for storing individual Sass or CSS files.
Sassy config, functions, mixins and placeholders
One of the main reasons why I started to use Sass was the ability to use variables. When you are working with plain CSS, making changes in global scope can be a pain. Imagine that in the middle of the project you would decide to change one of the main colors in your color palette. In that case, you would have to find every instance of that color and rewrite it. In smaller projects, this may not be so tiresome. However, it is still unnecessary waste of time.
For this reason, I decided to extend my atomic design workflow with a couple of folders dedicated to project configuration files and settings. The first folder called settings usually contains one sass file for a wide spectrum of colors I’ve gathered to this moment. The second sass file called config contains variables such as values for border-radius, box-shadows, typography settings, and so on. If I work on a bigger project, I will divide the config file into smaller chunks which are related.
Settings folder example:
_settings/ _colors.scss _config.scss
Another sass-related folder is called tools. This folder serves as place to store all functions, mixins and placeholder selectors I will be using in the project. When you will structure your project, beware of the right order of files. For example, I like to use simple function to convert pixels to rem units. Problem may arise when I use this function (it’s called remy) to convert some variables in config file and then import function file after this file. The result is log full of errors. You can’t use function before you define it. So, pay attention to the order of file imports in the main Sass file.
Tools folder example:
_tools/ _functions.scss _mixins.scss _placeholders.scss
Main Sass file example:
@import ‘_settings/_colors’,
‘_settings/_config’;
@import ‘_tools/_functions’,
‘_tools/_mixins’,
‘_tools/_placeholders’;
Base and preparing the ground
The second custom-made layer of my atomic workflow is called base. I took this layer from previously mentioned SMACSS architecture and customized it. Now, this folder contains the basic resets for html and body elements, proper box-sizing, possible font imports and also typography settings. The reason behind this was that I couldn’t decide where else should I put these styles. Atoms, molecules or organisms folders didn’t make sense. Neither of these layers or folders were appropriate for html and body styles, fonts or typography.
The problem is that atoms are basic building you can’t break down. Body and html don’t pass this requirement, at least not in my opinion. Molecules are basically groups of atoms and molecules are components composed of molecules (don’t worry, we will discuss all these layers). Again, html and body don’t pass either of these conditions. I was also thinking about putting these styles into templates. Unfortunately, as we will discuss, neither this is the best solution.
Since I didn’t want to spend half of my life thinking about this, I decided to take the base layer from SMACSS and add it to atomic design architecture. Problem solved. So, when you have to make some changes to these two elements, import custom fonts or set typography, I suggest that you use base layer. One principle I adopted from SMACSS as well is that CSS styles defined in base layer are using only element selector, descendent selector, child selector and pseudo-classes. There are no classes or ID selectors (I don’t use IDs in CSS at all).
Base folder example:
_base/ _base.scss _fonts.scss _typography.scss
Atoms
Now, when we defined the custom-made layers, we can move to the “official” components of atomic design created by Brad Frost. The first layer of atomic design are atoms. Atoms are the basic building blocks. They can’t be broken down into any smaller components. Examples of atoms can be links, lists, paragraphs, buttons, inputs, labels, headings and other basic HTML elements. Aside from these elements, atoms can be also more abstract. For example, color palettes and fonts. We can assume that Sass variables, functions and mixins could be also defined as atoms.
Therefore, if you want you may use atoms layer as a storage for project configuration files and settings instead of the first custom-made layer. It depends on what approach will be more comfortable for you. The question is, what is the main purpose of atom layer? These elements are often not useful on their own. For example, think about when you used label on its own? Probably never. It was always in conjunction with other element such as input. The main reason for having this layer is that it can help you define global styles for your project.
Atoms work great as individual rugs of the ladder and help you build up your pattern library. Atoms make it also easier for you to control the styles. This is also why I don’t use normalize stylesheet right off the bat I download it. Instead, I will disassemble the whole stylesheet it into individual elements and then move the styles to appropriate atoms. In other words, resets for anchor tags will go to anchor tag “atom”. The same for lists, inputs, etc. Then, instead of scrolling through the whole stylesheet, you just take a look at the right atom.
Atoms folder example:
_atoms/ _buttons.scss _dividers.scss _inputs.scss _labels.scss _links.scss _lists.scss
Molecules
As we discussed, atoms are not so useful on their own. However, everything starts to change and get much more interesting when we start mixing and combining atoms. This is how we will create molecules. Molecules are the second layer of atomic design architecture right above atoms. We can think about molecules in many ways. However, in the terms of UI and web design, molecule is a group of UI elements, or atoms, working together. We use molecules as backbone of the system.
Let’s quickly return the previously mentioned label. As said, form label on its own is basically useless. We can say the same thing about inputs and also buttons. However, we can combine these elements inside a form. In this way, we can give these elements some purpose and functionality. Label will help you describe the input and button will cause the form to be submitted. The question is, how complex should molecules be? They should be the simplest combinations of few atoms you can reuse across the project. For example, forms, navigation and maybe modals.
Molecules folder example:
_molecules/ _cards.scss _dropdowns.scss _forms.scss _modals.scss _navigation.scss
Organisms
The third layer of atomic design are organisms. We can create organisms by combining two or more molecules or molecule(s) with atom(s). Again, in the simplest terms, organisms are relatively complex UI components that form individual sections of the interface. Few examples of organisms include common UI components such as header, footer and sidebar. Let’s do a more in-depth analysis of header organism. This organism is composed of atomic components such as logo and molecules like navigation, search form and commonly used list of social networks.
Another example of organism can be product listing on some e-commerce website. If we go one level deeper, this organism is composed of product card molecules. These molecules usually contain title of the product, some thumbnail or image, short info and the price. This molecule is then repeated over and over again across the product listing organism. It is almost the same as an online blog. Blog feed is organism and every post is one molecule repeated over and over again. Combining molecules to build organisms allows us to create bigger reusable components.
Organisms folder example:
_organisms/ _blog-listing.scss _footer.scss _grid.scss _header.scss _product-lising.scss _sidebar.scss
Templates
The fourth layer of atomic design are templates. This page-level layer allows us to place previously mentioned components such as atoms, molecules and organisms into a layout. The result is clear and concise structure for the content. We can also think about templates as a way to establish concrete design direction or design language for our project. In a short, take header and footer organisms, add another organism such as blog post feed and you have basic template for a blog. Or, you can replace blog post feed with gallery and you have template for portfolio. In the same way, you can create templates for landing page, about page or whatever you wish.
In the vast majority of cases, templates consist a number of organisms mixed together. As a result, we will be able to form basic pages. When we reach this layer of atomic design, we start to see that our design concept is finally getting concrete shape. In other words, we start to see the layout. This is also when it is relatively safe to present our work to our clients because templates are more concrete than other previous components of atomic design. Therefore, templates make more sense to our clients as they can relatively easy see how will the final output look like.
Organisms folder example:
_templates/ _about-template.scss _blog-post-template.scss _home-template.scss _portfolio-template.scss
Pages
The fifth and final layer of atomic design are pages. In the terms of specificity, pages are on the top of food chain. Meaning, we no longer use any placeholder content. Instead, this temporary content is replaced with the content that will be used on the real version of the design. In the terms of web design and development, this means that pages are basically what will users see and also interact with on production.
One use case of page layer is also to test the effectiveness of our design architecture. When we reach this layer, we can see all the smaller components of our atomic design in specific context. This allows us to see whether of the pieces play well with each other or whether we have to go back and modify some atom, molecule, organism, or template.
Another possible use of pages is also to test variations in templates, method also known as A/B testing. Let me give you a couple of examples you may or may not encounter in your web design career. First, let’s say you design a blog. It is possible that some posts will have longer headlines while some less. For this reason, you can use page layer to create variations of blog posts to test headlines of different lengths. Or, you may work on a design for e-commerce website.
In that situation, you may want to know how will the layout look when listing is empty and when it’s full of products. Using page layer to create and test these specific scenarios you can find potential flaws or weaker spots of your design. Then, you can use this feedback to make necessary adjustments before you ship the design to your client. This may help you avoid a lot of potential problems and increase the chance that your client will want to work with you again.
Pages folder example:
_pages/ _about-page.scss _blog-post-page.scss _home-page.scss _portfolio-page.scss
Utilities – when you need some hacks
I know that I said that page is the last layer of atomic design. However, there will be moments when you will either need or want to make some small changes or adjustments. To make this possible, I added another layer on top of default atomic design architecture called utilities. This layer contains helper classes that will allow you to override anything that was defined in previous layers and also various browser hacks. Again, you can put these styles in atoms folder if you want.
Utilities folder example:
_utilities/ _browser-hacks.scss _helper-classes.scss
Closing thoughts on atomic design
Congratulations! You’ve just finished this article on how to use atomic approach to take complete control over your projects. I hope that this article provided you with amount of information that was both, sufficient and clear. Now, it is up to you to decide if you try this approach or not. If you are interested in atomic design and want to dive deeper than we did today, I suggest that you take a look at its official website. There, you will find a lot of additional information to study.
If you liked this article, please subscribe so you don't miss any future post.
If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂
Become a Patron
