English version is below.
原子 < 分子 < 生命体< テンプレート < ページ（Atoms < Molecules < Organisms < Templates < Pages）
As mentioned in my previous post, React works like lego blocks: you move blocks around to build bigger things. When I started looking into Atomic Design, I immediately made the association to React and the way components are managed inside code. Atomic Design is about considering the parts in a categorized manner, not everything is an equal component, they have a hierarchy that needs to be considered in order to build different structures.
Atomic Design starts with Brad Frost; in this presentation, he explains the concept and how it can be used in a production workflow. To put it in very basic terms: Atomic Design is about defining a hierarchy for the different parts that form a user interface using a chemistry metaphor. Just as an Organism is made of Molecules and they are made of Atoms, the parts of the UI are made up of other parts that can be divided until they reach their cores.
Originally, Brad Frost proposes the following structure: Atoms < Molecules < Organisms < Templates < Pages, going from the smallest indivisible parts to the whole. In a different approach of the same concept, from GE’s implementation of Atomic Design, a different categorization is made: Applications > Features > Templates > Components > Basics | Principles. This proposal inverts the ordering, so as to start from the whole: the Applications, and divide it all the way the smallest parts: the Basics. Meanwhile, the “Principles” are concepts without code that designers have to keep in mind at all times. For a production workflow, the “whole to details” ordering may make more sense, as it starts envisioning the big picture of the application and gradually sorts out its parts.
My first encounter with Atomic Design was this video that presents an overview of the concept and examples of Frost’s structure. It also explains a workflow on how to approach implementing Atomic Design. Similar to GE’s example, it goes from the whole to the details: first, they design a couple of pages of the project, and then they start creating the divisions.
When I think about React, I think about managing components and folders, having them neatly organized in order to make them as readable and reusable as possible. In this way, something from Atomic Design could be used in between UI/UX design and front-end coding workflow, hopefully also bringing it closer to the original UI design, making it more approachable to designers, even inviting. Now, the design workflow makes sense starting from the whole, having the big picture first. On the contrary, in front end you could start from the smallest parts, as you need to have the blocks first before starting to put them together. So it would go in a sort of wave, first dividing the whole into its atoms, and then using the atoms to build up the whole.
For better illustration, I will present below some parts of a fake UI. Let’s imagine a very basic workflow for a design process:
We are missing fundamentals here: the whole research before even starting to sketch a screen, persona modeling, and other steps of the process. These are also important for the programmers to have a grasp of, but what probably they need to know immediately from the designers is what the UI will look like. The first time we have a sense of this is the wireframe.
In this example there are two basic screens: one for Login, and the other one for a Dashboard. There is a general layout defined, there are some hints of what components might be necessary. Now, Atomic Design can be put to practice here. Instead of only having the whole pages, we separate them in parts. Doing this in the design stage, could lead to a better understanding for both parties about the parts, even sharing naming conventions inside the design files and the code. From the example above, we can take the button, input field, and the article.
I’m using the Atoms/Molecules naming to separate some of the parts from the wireframe. However, I am grouping them all as Components. As for the frontend, we will use Component Oriented Programming, with either React, Vue or Angular.
With the wireframe ready and divided into parts, we can start to create the code for each component separately. Some default values might be used for the styles, but we make sure to configure the parameters so they can be changed easily, both for reusing and to attend design changes. Once the basic blocks are ready, programmers can start to build up the layout. Meanwhile, designers can work on the visual design, adding colors, changing shapes, refining any details. UI/UX design software offers tools to create components inside the design files, such as components in Figma. In this way, editing the basic button will affect all of its other copies.
In the example below, I changed the color to blue and added a drop-shadow to ActionButton, this changed all of its copies. Inside Article, I changed its color to red, and this affected only the ActionButton in the Dashboard.
Here, we have the programming concept of inheritance in action. This can be easily translated to code, as now the programmer knows they have to make a button. Inside this, it must have the option to change its title and color, while keeping common attributes like the round-edges and drop-shadow. This enables us to reuse the same components to become more efficient.
Once the mockup phase is ready, programmers can address the changes, as they will look into the Components neatly arranged in the design file, and re-adjust them individually so they keep the attributes defined by the designer. With a bit of programming knowledge, this cosmetic tasks could also be performed by the designers themselves. Finally, the iteration step has a similar process, by either modifying the already defined blocks or adding new ones and arranging them as necessary, in constant communication between design and programming.
Frameworks like Vue, encourage having styling contained inside each component because of its structure of <template>/<script>/<style>. This seems very appropriate to do for Atomic Design, however, there are advantages to having a collection of style files separate from the rest of the code and having them organized with Sass, for example, but this requires a different discussion.
In this article, we established how Atomic Design divides applications in parts composed by other parts in order to, ultimately, have a better common understanding and management over them. The main concept of dividing the whole to its indivisible parts can be used to prepare design files that can become a shared map both for designers and programmers. An agreement that maintains the designer’s intents but also enables the programmers to refer to the changes that have to be done.
Workflow approaches with this thinking can improve efficiency and understanding between design and development, these are the KISS (Keep It Simple Stupid) and DRY (Don’t Repeat Yourself) principles in action. Nothing new, just a different way of organizing their execution. In the end, it’s about having a common way for organization and logic that can be shared among the whole development team.
南米コロンビア出身、ハベリアナ大学（コロンビア）社会科学部文学科卒。2013年に来日し、九州大学芸術工学部の修士・博士を取得。 大学院の研究ではゲーム性を取り入れたデジタル教材をテーマに、ゲームエンジン、3DCG、モバイル開発など、プロトタイプを作成するための技術を習得し、コンセプトから実証実験まで行った。 卒業後、AIのスタートアップ企業でデザイナー及びフロントエンドエンジニアを経験。 UI/UXデザインのメソッドを身にづけ、Webアプリケーションの最新技術を使い、AIを取り入れたアプリケーションのUIデザイン及びフロントエンド実装などに従事。 2020年8月にエンジニア兼デザイナーとしてFixelに入社。