Atomic design: the basis of a design system
Back in 2013, Brad Frost wrote that Atomic Design should not be seen as an absolute and linear process, but as a mental model. This should help to consider a user interface as a complete whole and also as individual small parts. This is the reason why we always take the model as a basis in our demanding projects and adapt it to the project requirements.
Extension of the original concept
We have already talked about the original basis (2013) of Atomic Design and you can find all the information you need by clicking on this link: Atomic Design 1/2.
The constant growth of digital products brings new requirements for their development. More and more companies are tending to develop a design system in parallel with a product. This enables a sustainable approach to a constantly evolving product or a rapid expansion of applications in a product range.
In 2019, Brad Frost reflects on his concept published in 2013 and shows concepts that extend Atomic Design according to specific requirements in order to support the visual and semantic languages of the design system. This happens with the help of design tokens, which enable the independent consistency of design elements. Design tokens are now a worthy part of the Atomic Design methodology. They are referred to as "ions" and are considered as the smallest unit of the user interface.
On the other hand, our requirement to use the components of the design system on different platforms or product lines has further extended the Atomic Design methodology to the right (see picture below). We have decided that the largest unit of the system can be a product line or a specific operating system (e.g. iOS). We call these "products" and place them at the end of the Atomic Design model.
Why do we use the Atomic Design approach?
Convenience
By creating complex components from simpler components, Atomic Design makes it easy to customize even the smallest elements without spending a lot of time on it. Need to change rounded corners of the button? Apply it once to the main component and see how this change affects all other instances in the library.
Consistency
By defining a specific behavior and appearance for each element of a product, Atomic Design prevents individual patterns from being misused and affecting the aesthetics or usability.
Simplicity
The easier the design system is to work with, the more frequently it will be used. The customizable and interchangeable component library of "atomic" groups is easy to maintain, scale and customize.
When do we use the atomic design approach?
When developing a new product: The Atomic Design approach makes particular sense when we are developing more complex design systems for products, have completed the discovery phase and are ready for further development. During the discovery phase, worrying about design consistency will only slow you down.A good time to start building a design system, and accordingly the Atomic Design approach, is when the first wireframes are created and the visual language of the product is agreed with the stakeholders.
When business growth is planned: For customers who have decided to adapt existing products to new technologies and/or to develop a new product line, the longevity of a design system plays a major role. This can be realized extremely well with the Atomic Design approach. It strongly promotes growth through reusable elements.
How do we build our UI with the Atomic Design approach?
As mentioned above, we primarily decide as a team whether a design system with an Atomic Design approach can help us to achieve our goals in the project. If it does, then you can continue to work according to the following principles:
Structure
First, the structure of the design system is defined. Here we answer the questions: How do we use the Atomic Design approach? How do we want to name the individual components of the approach? Do we want to work with tokens or without tokens? We make these decisions together as a team. Every competence and opinion is important and everyone should understand how the system is structured and used. This is not only about the UI design, but also about different ways of implementing the design system, which is why it is important to discuss those decisions with developers.
Let's take a look at all the parts of a design system here:
Principles
Principles define the purpose and value of your organization's design system. They explain the decision-making process and determine how the team can use and develop the design system.
Accessibility
Accessibility is the concept of how a product or service can be used by everyone. Designers should therefore try to consider all potential users in different usage contexts. This brings clear benefits - but above all, better designs for everyone. Here we define which laws need to be considered and to what extent our system should be accessible based on user requirements.
Content Strategy
Just as products should look and act uniformly, they should also speak uniformly. We try to use a certain voice across the board and always speak to the user in the same tone. This also includes grammar and vocabulary. Every user of the product should recognize technical terms in order to be able to use the product correctly.
Design tokens
Design tokens are all the values that are required to build and maintain a design system - spacing, color, typography, object styles, animation, etc. - and are represented as data. They are used instead of hard-coded values to ensure flexibility and consistency across all product experiences.
Design tokens are directly integrated into our component library. They cover the different options of component states and more.
Primitives and Business Components
A primitive is a basic component from which you can create more complicated components, patterns or modules. A primitive cannot be used on its own and does not contain any business logic.
Business components contain business logic and are filled with business data.
Patterns
Patterns are best practice solutions for how a user achieves their goal. They show reusable combinations of components and templates that are tailored to the most common use cases.
Module
Each module carries a specific function of the product and business logic. All modules can be exchanged and omitted at the stakeholder's request.
Templates
A template is a collection of different modules that fit together according to their theme. The templates can be used by potential users of the system to quickly create the required views. Modules in a template can be removed, added or swapped.
Documentation
The next step is to decide whether the design system documentation should take place. In which language and in which tool is it most relevant to create it? This usually depends on the product team and the product type. In any case, such issues should be clarified as early as possible. Otherwise, there is a risk of important decisions being lost or irreversible processes being set in motion.
Consistency in files
The structure of the agreed design system structure is transferred to the design and documentation tool. This enables consistency in everything we build and everyone involved can easily find their way around the files.
Now you are ready to start designing tokens, components or patterns to ensure a good and sustainable design system for your customers.
Conclusion
Not all projects should be built using the Atomic Design approach. First discuss in your team whether the approach can contribute at all to achieving your project goal. In an MVP project, where the focus is strongly on testing ideas and evaluation, it may be more productive to build a UI kit. A UI kit can save you a lot of time compared to a design system. However, if there is a need for a complete design system, we recommend following the approach and expanding it according to product needs.
It is important to understand that each product is unique and should offer a unique solution.