Atomic Design methodology

In this post, I will discuss Atomic Design – a methodology for creating ‘systems’ (views). This is not a CSS methodology. However, it presents a very interesting approach to the issue of application development. Furthermore – it can be transferred directly to the world of CSS. The author of the Atomic Design approach is Brad Frost, whose blog you can find at this link, while his book you can read (or buy) here.


In this method, we divide the view into five components: atoms, molecules, organisms, templates and pages. Each next one consists of the previous ones, grouping them or completing them. We see that according to this method, we create complex structures. Starting from the simplest, indivisible fragments. Hence the names derived from physics – atoms, molecules, organisms.

Thanks to this division, we get the code, which is a set of blocks from which we can choose, building the final shape of the application.


They are the smallest fragments of the view and at the same time the only undivided. They form the basic building blocks of the application. This group includes basic HTML tags, such as buttons, links, inputs, labels, fonts, colours, animations. Atoms cannot exist alone. They become meaningful when used with other atoms, creating specific functionalities.

Atoms have their styles: default and modifications. As with most previous methodologies, we recommend using classes rather than tags for styling. This allows you to create modified appearances in specific name groups.

Let’s look at some examples:

.button {}
.button-primary {}
.button-primary:hover {}
.button-secondary {}
.button-disabled {}
.input {}
.label {}
.text-input {}
.checkbox {}
.radio-input {}

Atoms do not have to be physical objects in the view. They can be more abstract creations, such as the colour version, animation or size:

.navy-blue {}
.transition-open {}
.transition-rotate {}
.large {}

Having a basic building material, we can begin to create more complex structures.


Molecules are the basic group that creates the view, made of atoms only. As in nature, the use of different atoms produces different molecules. Let’s imagine that we have four different atoms:

.button {}
.label {}
.text-input {}
.email-input {}

We can build, for example, such molecules:

  • post search form

<form class="search">
    <label class="label">
        <input class="text-input" type="text" placeholder="Search post">
    <button class="button">Search</button>
  • contact form

<form class="contact-form">
    <label class="label">
        <input class="text-input" type="text" placeholder="Name">
    <label class="label">
        <input class="text-input" type="text" placeholder="Surname">
    <label class="label">
        <input class="email-input" type="email" placeholder="Email">
    <button class="button">Contact me</button>

We see that the molecules group individual UI elements. Together, they form a specific functional whole. The special properties of the molecule are:

  • regardless of the place in the application, it has the same task,
  • handles only one task,
  • is reusable.

If these properties are met, then we have a correctly built molecule.

At this level of complexity, we can see how reusable our code is. The same atoms are used in different configurations, leading to different functionalities.


Organisms can consist of atoms, molecules and even other organisms. So they can differ in their level of complexity. We can recognize them as separate, unbound pieces of view, giving our context to the elements inside. Good examples are:

  • navigation,
  • footer,
  • sidebar,
  • container with articles,
  • article.

Let’s look at the sample code

<div class="menu">                                                       
    <img src="..." class="logo logo-brand">             	             
    <nav class="nav">                                   	             
            <li class="nav-item"></li>                                   
            <li class="nav-item"></li>
    <article class="post">                             	                
        <header class="post-header">                    	            
            <h2 class="h2-heading">Post title</h2>                      
        <section class="post-body">                     	            
            <img src="..." class="logo">                	            
                <p class="paragraph"></p>                               
                <p class="paragraph"></p>
        <footer class="footer">                         	            
            Post footer
<footer class="page-footer">                           	                
   <address class="author-address">                    	                
        <span class="short-text"></span>                                
        <a href="..." class="link"></a>                                 
    <nav class="nav">                                                   
            <li class="nav-item"></li>                                  
            <li class="nav-item"></li>


The task of the templates is to create a grid, space for elements forming the functional layer of the page: organisms, molecules and atoms. Their scope applies to the entire view, not its parts (like previous groups), thanks to which it already gives the application fully functional context. At this stage, it can be determined if all the elements match and harmonize as intended by the developer. Importantly, the visual /colour aspect is not taken into account at this level. We are only interested in the structure and operation of view elements. Examples of CSS class names corresponding to this stage of application development are

.section {}
.article {}
.header {}
.footer {}
.aside {}
.main {}


Pages are an extension of templates with the specific content of the view – photos, videos, texts. This stage is the culmination of all work, after which the view is ready to be presented. At this stage, we can only see if all the elements look good together in the entire ecosystem. It is a place where we can create different versions of templates depending on the context. E.g. a user with admin rights will have a richer view than a regular interface client. For CSS pages, they could be named as follows:

.blog {}
.post {}
.home {}
.settings {}
.dashboard {}
.admin-dashboard {}

Class names

As this is not a CSS methodology, there are no rules for styling elements. This gives us complete freedom in implementing this approach on the code side. I suggest that in the case of molecules and organisms try to use semantic names for classes. It will help with the management of these groups and will determine what objects we are dealing with.


In this post, we learned the methodology for creating Atomic Design views: 5 stages of building an application and sample classes corresponding to these stages. The next post will concern the topic of combining CSS methodology with the currently popular component approach. If you want to delve deeper into the secrets of Atomic Design, take a look at the following link.

* In summaries of methodology entries, I skip their advantages and disadvantages. I want to leave each of you the opportunity to make an independent assessment.

If you want to know more about CSS Methodologies, read previous articles from the series:


Michał Wajer

Software Developer at Aspire Systems Poland. He began his adventure with Angular in the summer of 2018. In his free time, he learns the secrets of Vue, RxJS and TypeScript. Enthusiast of sport (most of all running) and speedway.