string(4) "blog"

CONTENTS

2020.10.11

Atomic Design for a UI/UX design and programming workflow (アトミックデザインによるUI/UXデザインとプログラミングのワークフロー)

written by Jacobo

English version is below. 

サマリー

アトミックデザインとは、化学に由来する用語を用いて画面上のUIデザイン要素を以下の名称で階層化して整理する方法です。

原子 < 分子 < 生命体< テンプレート < ページ(Atoms < Molecules < Organisms < Templates < Pages)

原子が最も小さい要素で、小さい要素を組み合わせてより上の階層の大きい画面要素を作ることになります。本記事では、この概念をUIのデザインとプログラミングのプロセスをつなぐワークフローの中でどのように活用できるかについて書きます。

デザイナーはアプリケーション全体をデザインしてから細かい部分を調整して行きます。先ずは生命体を作り、それを原子までに分割して調整しているような作業です。一方、プログラマーはデザインされた画面から再利用できる部品を作り、それらを組み合わせることで動くアプリケーションを構築して行きます。原子を組み合わせて、生命体を作っていくような作業です。全体から細かい部分に精度を上げながら設計して行き、また細かい部分から作り始め、徐々に全体に組み合わせて行く、一連の流れのようなプロセスと捉えることができます。

本記事では上記のプロセスの例として、デザイナーがワイヤーフレームを作り、画面の各要素を分割します。次にプログラマーは各要素を部品として作り始めるます。見た目を左右するビジュアルデザインに対してはスタイルを簡単に変更できるようにして、デザインの変更を適用しやすくなります。このようなプロセスを実現するには、Figmaなどのデザインファイルは、デザイナーとプログラマーが共通の用語で理解できるマップのようなものになるべきです。これにより、コミュニケーションと作業の効率を向上させることができます。

Atomic Design for a UI/UX design and programming workflow

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.

atomicworkflow

Design and Programming workflow

For better illustration, I will present below some parts of a fake UI. Let’s imagine a very basic workflow for a design process:

wireframe→mockup→iteration

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.

atomic_design_01

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.

Divide (then build up again) and conquer

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.

一覧に戻る
お問合わせ