Atomic Design for Design Systems

For any Design System, either is targeting web apps, native mobile apps or both, a well organized component structure is the primary reason to build a scalable, easy to communicate and adaptable product. The main output of a Design System is a pattern library, which is a collection of reusable components; To create highly reusable components requires that these are always well organized and documented.

Since Brad Frost introduced the Atomic Design concept back in 2013, I immediately adapt it for the components structure of pattern libraries and Design Systems. While soon after, I started evangelizing the adaption and usage of Atomic Design on Design Systems for multiple clients.

Recent years, I used the Atomic Design structure on custom‐built CSS frameworks and Design Systems for clients such as CASIO , Rakuten , and on the core of the architecture design of the Design Language System for Fast Retailing .

How Atomic Design benefits Design Systems

Communication

First and foremost Atomic Design solved a communication mainly problem. Using wording that is understandable to everybody —from product managers to back‐end developers— making clear what are the hierarchies and relationships of components, both on design and development.

Easy to understand

The simplicity of Atomic Design terminology is the secondary obvious benefit. Everybody understands what are “Atoms”, “Molecules”, and “Organisms”; not only native English speakers, but also foreigners with limited English capabilities. I am working in Japan for almost 7 years now, and for people here too, Atoms, Molecules, and Organisms are terms that are clearly understood and easy to communicate.

Before the Atomic Design, I remember that I was often struggling to clarify the different types of UI elements, using occasionally some “sketching” terms —such as widgets— that hardly helped on communicating the relations of them.

Focus on the core

A blocker on starting building a new Design System, is that both designers and developers are occasionally struggling on braking down wireframes or template‐based UIs, to create highly reusable components.

By defining the rules of what exactly is an Atom, what a Molecule, and an Organism, is a necessity to start creating any pattern library or Design System.

Scheduling and meeting goals

Having a clear map of all —or at least most— of the components and their relations, is the primary source to create a realistic project schedule that can be tracked at any point of the product roadmap.

Teams collaboration

All teams has to be aligned on a modular structure for any modern project. While today’s developing frameworks and libraries, such as React, are literally forcing a modular structure, UI (and UX) design structure is not always aligned. Atomic design is a well understood structure from most designers, making much easier the alignment and overall communication between different teams.

Amount of components

Less is more, and by focusing on the Atom components, defining them on early stages —such as during wireframing— results to minimize the effect of having a massive amount of Molecules and especially Organisms.

Personally I faced a situation in the past, where most of the components of a pattern library, where Organisms. Resulting to a massive amount of components and —most importantly— on having multiple variations of Organism components with very similar UIs or functions, becoming hard to understand which to use, and where.

Freedom on mixing components

Agile practices requires to be able to efficiently reuse and mix pieces of UIs, from both designers and developers; without the fear that will result a problematic UX and things are going to be broken.

That requires that we have to make clear which components can be mixed and matched. Declaring the hierarchy and inheritance of them with Atomic Design, is making much easier to understand which components can be mixed , replaced , or combined .

Consistency

Consistency of design and coding structure, is not exactly a benefit gained directly from Atomic Design. But Atoms, Molecules, and Organisms are helping a lot to clarify relations and avoid inconsistent outputs in a lot of cases.

Scaling and growing

A common issue of underperforming pattern libraries or Design Systems, is that while initially are providing obvious benefits, on the long term can become difficult to adapt, maintain, and often cannot scale as expected.

The primary reason for this issue is a too complex structure of components, without clear hierarchies and information of their inheritance; becoming difficult on how or when they should be used. Atomic Design is making much easier to understand relations , hierarchies , and inheritance , therefore creating more scalable systems.

Not only for CSS frameworks

Atomic Design is beneficial not only for web apps. Is also equally valuable for native mobile apps.

Recently Apple introduced the SwiftUI which is focusing on declarative syntax and is based on even more component‐type UIs, grouped and arranged within stacks (i.e.: HStack , VStack , or ZStack ) creating a somewhat similar component structure with React or Vue.js.

Using Atomic Design

Brad Frost wrote even a book for the Atomic Design concept. Also there are out there, quite a few articles on the usage of Atomic Design.

Personally, I used Atomic Design for over 10 Design Systems and pattern libraries. But for every single product, I approached the adaption of Atomic Design slightly different; While in some cases, I followed a quite radical approach from the original concept that Brad Frost introduced.

The reasons that I’m always adapting the Atomic Design usage, is that different business goals, different teams, and different design or development stacks are requiring different structure on the component level. Atomic Design simplicity as a concept, allow us to easily adapt it for almost any type of Design System without loosing its benefits.

Components relations

To gain all the above benefits, we need firstly to understand the most important parts of the Atomic Design; which are the components hierarchy , inheritance , and their overall relations .

From the frontend development point of view, Atomic Design serves very well the “C” on CSS ( Cascading Style Sheets), so that even for people who are struggling to understand the cascading feature of CSS, Atomic Design can serve as a very useful tool to help frontend developers take advantage of the cascading benefits and always align with the design approach.

As a side note, cascading styles is a very important feature that affects performance, scalability and maintenance of components; Also can enable us to adapt easier all the new features we are getting the recent years, such as CSS grids and subgrids, CSS variables, @support and other @media queries.

From the design point of view —UI design, UX design, even UX research— Atomic Design can be also become the epic center on how we define components’ relations. It is possible to adapt Atomic Design whatever tools we are using — both with modern tools, such as Sketch; but also with traditional tools, such as Photoshop.

Defining what is an Atom, a Molecule, and an Organism

The rules that defines when and why components are Atoms, Molecules, and Organisms does not have to be always the same for every single product. Different tools, development stacks, also different teams and people requires different rules on what is each component.

When a product is on its early stages, it is possible and usually easy to adapt these rules and shift components e.g. from being Molecules to become Atoms. But what definitely we have always to take care, is to communicate these rules loud and clear to everybody that is contributing on components; Also to avoid these type of changes after the product is starting to grow.

Visibility of Atomic Design terms

For the users of Design Systems, the Atomic Design structure is not the primary information that they are seeking for. When people want to use components, they need firstly to be able to quickly and easily find a component.

By having components underneath atoms , molecules , and organisms directories, does not help at all on finding components, creating an unnecessary additional step on navigating any type of pattern library. That is true for all touch points of a Design System, either is the guideline pages, either a Sketch library, or a CSS framework.

I had experienced a case, where a Sketch library had all the components within a top level menu of Atoms, Molecules, and Organisms; So that every time users seek for a component, to spend additional time on navigating these categories, trying to guess where a component is. Resulting to a hit and miss more often than I also was expecting.

That doesn’t mean that Atomic Design has to be a hidden information. Users of Design Systems need occasionally the Atomic Design information, and is highly recommended to make it visible within each component documentation.

On the other hand, for people who are building Design Systems, the Atomic Design information is recommended to be always highlighted, since is playing an important role when building components.

What’s next

Though Atomic Design provides important benefits for the modern development of digital applications, I believe that something is missing…

Stay tuned for the next article, where I will introduce an “extension” on the Atomic Design.