Extended Atomic Design structure

Introduction

Atomic design is a methodology originally composed of five distinct design stages working together to create interface design systems in a more thoughtful and hierarchical way. According to Brad Frosts, author of the atomic approach concept, the five stages of atomic design are: atoms, molecules organisms, templates and pages.

Atomic design is not a linear process, but rather a mental model that helps us think of our user interfaces as both a cohesive whole and a collection of independent parts. Each of the five stages plays a key role in the hierarchy of our interface design systems.

In 2019, he published an update in which he notes that, in practice, the whole concept still needs additional elements because each organization implementing the design system needs to adapt the approaches used to its needs.

General challenge

The project team will face many technical, communication and decision-making challenges. I will focus below only on component programming challenges. In this context, it is most important to understand that the design of a system created in an atomic design approach will evolve a lot at the beginning, and the development and UX team should be very open to a large number of changes and discussions about all, sometimes even obvious things.

The result of the practice may be, for example, the desire to extend the classic structure and below proposes 3 additional groups of components with a discussion of the purpose of their use in the project. Note - if you are not familiar with the atomic design approach, be sure to visit this page first - Atomic Design Methodology.

Proton - smaller atom for atom

Let's start with a simple example:

<Btn variant="primary">
  Some text <Icon name="home" />
</Btn>

Above we used two components. The Btn is an atom and displays as a classic button that has text inside and can have an icon. Icon is also a classic component and is also.... atom. Two questions are always asked at this point:

• can an atom contain another atom?
• if Btn contains another atom should it be a molecule?

For both questions, the answer is no.

Atoms are components that can no longer be divided into smaller ones. Buttons with an icon is a kind of variant, but further - it is just a button whose functionality will not change without an icon. Therefore, it is clear that it should not be a molecule. The icon will not have any other component in it, so we can treat it as a smaller atom - let's call it proton.

In this approach, we need to define for ourselves that:

• an atom can contain a proton;
• an atom cannot contain an atom;
• a proton cannot contain an atom or a proton;

The above approach is crucial for reasonable component granulation, because we do not create senseless small molecules.

Quark - when you need logic

Sometimes the common part of some components is not the presentation layer, but the business logic. Then we create a quark that does not have a presentation layer, but only a part responsible for performing some operation. In Vue, quarks are composable components.

Quarks significantly affect what will be displayed in the presentation layer, so they should be described in the documentation, although we can see the result of their action in other components. Quarks should not be used in a proton, but can be used in an atom, molecule or organism.

Bosons - variables, tokens, variants

Bosons are variables or groups of variables. They can be used any atomic design element, but they should not know about each other. We should not refer in one boson to another. For example, if we want to manage a color palette then it should contain all the colors that are possible to use within the system design.

With bosons there is an interesting case in general, because you can consider that variables in the Tailwind configuration file are bosons, but variables imported into the component containing Tailwind class sets can also be considered bosons. Such sets form variants.

When using preprocessors such as sass, it is worth mentioning that variables should definitely not be organized as they are in Bootstrap, because it is anti-pattern. In general, it is not worth keeping variables in one file, but in many small files and importing into the component only what will be used. What is the value of this approach? You will be able to check for each change of value in a variable or group of variables how many components will be affected by the change.

Sensible granularity

When extending the atomic design structure, one thing needs to be focused on - we need to approach the granularity of components sensibly. You should not create separate components for absolutely everything. On the other hand, one should not consider all the use cases of a component every time and create one component that supports a great many variants. If a team creates two similar components, it should accept the fact that it can think about merging them, or allow for redundancy, which is not necessarily a bad thing.