What comes first to your mind when you think of the word ‘website’? Probably, one from the category of the ‘biggest’ or ‘most popular’ – like a search engine or some social media. Such applications are extremely complex and it’s easy to get lost in their structure once you dive in – while they seem to be simple to use, they’re collections of immense numbers of pages. Creating such a website requires a great amount of organisation and self-discipline in order to facilitate any further changes, all whilst maintaining consistency.

This task may appear daunting at first sight but, fortunately, multiple ways of organising application structures have already been established. After reading this article, you will be familiarised with basic concepts and building blocks of the Atomic Design methodology for website component organisation and design system creation. Let’s dive right into it!

If you want to read my essay on the applicability of Atomic Design in 2023 instead, here it is.

Is Atomic Design still relevant in 2023?

In 2023 we’re celebrating the tenth anniversary of Atomic Design methodology – it’s like a century in terms of technology. It is still relevant?

Read more

The system

Let’s start from the end of this article’s title – the Atomic Design idea was created by Brad Frost (circa 2013) while searching for analogies in nature and design system creation. The creator found one in chemistry – all matter is built with atoms which are bound into molecules and, later on, bigger organisms. Therefore, five levels of abstraction were taken into consideration in this methodology.

As mentioned before, the base building block of all that exists is atoms. In terms of Atomic Design, it means these are the smallest interface elements like labels and buttons. Splitting an atom in real life might cause some inconveniences for everybody around and so they should not be broken down further (if the element can be easily broken down, then it’s probably not yet an atom). The atoms may also convey some information about the global application variables like spacings, fonts or colour palettes. Those elements, however, are a look into the website styling on their own rather than meaningful and independent components.

Next up on the list is molecules. These are composed of atoms and are the main components which are used to build our website later on. An example of such a component can be a control with an input, a label and a button. Molecules are meant to be built to convey some logic like a single functionality and meant to be easily reused.

The last chemical inspiration in this methodology is organisms. They are meant to convey even more complex logic and bigger elements like page headers & footers. They are mostly built with a bunch of molecules. Through these elements, we can finally see some shape of the application we’re building as we start to see some functionality and design in action. Building such organisms is another step to the creation of reusable and independent components.

The first non-chemical part of the Atomic Design is templates. These elements are mostly connected organisms which shape the layout of the page itself. With templates, we can see the final shape of the page but without the concrete data – a layout like this adds a lot of context to the organisms already mentioned. And lastly…

… the pages themselves. The last step here provides the final look of the application itself by filling the template with data. From here, we can get through all the building blocks of the website and modify them one by one if needed.

The bad

Going further with the title, let’s now go through some aspects connected with Atomic Design which I consider not to be that good (that could also be true for some other methodologies).

First of all, while it’s a good practice to use a methodology of some sort for project organisation, it may take some time for all team members to become accustomed to it. Even though the Atomic Design itself is rather a simple concept, switching from the old way of component creation might be found difficult. One such case may be any introduction of new components – we have to document them thoroughly and make sure the other team members know of their existence so that no duplicates are created and the existing elements are used. Another case can be found during the components’ structure organisation – we may indulge in building all the pieces in such a way that they’re globally available while, in reality, their use will be limited to the container element only. Last but not least, the elements might be hard to classify in some cases – this can be mainly seen in distinguishing the molecules from organisms as differences between them seem to be subtle at first.

Secondly, in order to create some pages in our applications, we have to create the required components first. As long as the components have not yet been created, there is no way of knowing what progress is being made on the project itself. Solutions like Storybook might solve this issue by introducing the demo of the created components without the surrounding page context (this may also be a good solution to present the appearance of the components to the UX/UI team and apply any required changes). However…

The good

…if we create the components one by one or in small batches, the development might be much faster. There’s less code for developers to review and fewer patches to apply for the developers assigned to their creation. If we already have the components in place, we can create the pages with ease by using the existing blocks, which is much faster than creating pages from scratch (with the proper templates, the only thing that would change would be the displayed data).

The separation of components (and proper naming of course) also allows us to easily find the spots which require some changes – finding a specific element in a gigantic component might be troublesome. This can also be a good start for creating styles local to the components themselves, which removes any chances of globally conflicting CSS styles.

With the use of Atomic Design methodology, we create collections of reusable components tailored to our own needs – building new & fresh applications would only require some changes applied to their theming. Creating such a set would also remove the need for using any external ones (which possibly include more components than we really need).

Laying out the components afterwards can also show the progress to both clients and all the members of the team. If any changes are required, the feedback loop is also shorter in such cases and the development team can also progress faster.

The summary

Many other analogies between webpage creation and the surrounding world can be found (for instance, one thing that came to my mind was the word – paragraph – page analogy) and Atomic Design is one that is succinct and easy to comprehend. It not only allows the faster creation of the applications, but it also supports the progress supervision by the clients and team members. Like any methodology, it has its drawbacks and a learning curve, but the benefits of using it greatly outweigh them.

If you want to dive deeper into the subject, check the Atomic Design book written by the methodology’s creator Brad Frost (https://atomicdesign.bradfrost.com/).

Take care!

Olek Krawiel

Aleksander Krawiel, the audacious Frontend Developer at Makimo, is a provocateur in the tech realm, continuously pushing boundaries with functional and system programming. A tireless explorer, he crafts articles that delve into the intricacies of DevOps, building developer environments, and mastering CSS & JS. Outside work, he morphs into a polyglot programmer, nimbly shifting between JavaScript, Godot, and Blender. Aleksander's multifaceted persona promises a riveting journey in the world of code.