会社でアトミックデザインをここ3年ほど導入していますので、そもそもそれはなんなのか、誤解しやすい点、重要なポイントなどを、あくまで一個人の意見としてご紹介します。
アトミックデザインとは
Brad Frostさんが2013年に記事で公開したUIの設計システムです。
公式のドキュメントはBradさんのアトミックデザインの記事を見てください。
アトム(原子)、モレキュール(分子)、オーガニズム(生物)、テンプレート、ページという定義があり、UIをそれぞれに分類します。
ちなみに、情報が確かかはわかりませんが、こちらの記事によると、1998年に同様の考えをMark Rolstonさんが提唱していたようです。
Mark RolstonさんはAppleのインターフェースなどをデザインしたことで有名なFrogDesignに所属されていたそう。
デザイン手法ではない
A lot has been said about creating design systems, and much of it focuses on establishing foundations for color, typography, grids, texture and the like. This type of thinking is certainly important, but I’m slightly less interested in these aspects of design because ultimately they are and will always be subjective.
作者のBradさんは、色、テクスチャ、などの表現で設計システムを語ることにあまり興味がないと言っています。
そして、インスピレーションとして、化学(原子、分子、生物など)に着目した設計手法として提案されています。
なので、デザイン手法ではなく、化学から着想したコンポーネントの考え方となります。
エンジニアとデザイナーのフローは真逆
実際にアトミックデザインを導入しようとすると、エンジニアは導入していこうと意欲的ですが、デザイナーはいまいち感覚がつかめなかったりします。
というのもデザインとアトミックデザインはその作業フローが全く逆です。
デザイナーのフロー
デザインをするときは、いきなりコンポーネントの細部からデザインし始めません。
アイデアスケッチもしていないのに、いきなり図面を引き始めるようなものです。
まずはページ全体を捉えながら、あくまで全体として絵を考え、仕上げていきます。
アトミックデザインで例えると、Pages -> Organism -> Molecule -> Atoms というようにデザインしていきます。
どのコンポーネントがどこと共通化でき、どのようなくくりになるのかは、使い勝手なども考慮して複数画面デザインてはじめて見えてきます。
エンジニアのフロー
逆にエンジニアは、おそらく部品からおいていく人が多いでしょう。
そして、グルーピングする必要があればdiv要素で囲んでいきますよね。
このようにデザイナーはマクロからミクロ、エンジニアはミクロからマクロと作業をする傾向があるので、なかなか足並みを揃えて進めていくのが難しいです。
コンポーネントの分け方として他チームに共有
大事な考え方として、 アトミックデザインはあくまでエンジニアが使うもの として共有することです。
デザイナーには、
「このように分類しています。」
「再利用するときはここから使うか、なければ新しく作ってください。」
などと伝えましょう。
やってはいけないこととして、無理やりアトミックデザインの分け方を強要することです。
エンジニアリングの考え方を他チームに強要してはいけません。
アトミックデザインの本質はUIの再利用
ここからは少し実践的な内容も入れていきます。
アトミックデザインを導入するときに、いちばん大事な考え方は 再利用 することです。
再利用しないのであれば、そもそもアトム、モレキュールなどに分類することに意味がないので。
なので、再利用するUIのみコンポーネント化していきます。
一度しか登場しないUIはコンポーネント化しません。
全ページのデザインが完成してから導入する
再利用するくらいなので、できるだけ多くのページのデザインができていることが好ましいです。
すでにサービスがスタートしており、デザインも含めてリファクタリングするのであれば絶好のタイミングです。
もし、スタートアップ時で全体像がまだ無い場合は、 おそらく使い回すだろう という単位でUIを分けていきます。
実際には以下の手順で分類していきます。
- 全ページが完成したら、プリントアウトし、同じUIに丸と連番をつけていく
- 連番をつけたものに``button-default``などと命名し、Atom, Molecule, Organismに分類する
- 必要であれば分担し、コンポーネントを実装していく
では、どこにグルーピングするかの判断基準をご紹介します。
Atom
- 再利用する単位で分けていく、ただし、子にさらに再利用するUIがあってはいけない
- 再利用しないものはいくら大きくても一枚画像のように、アトムでいい
Organism
- ページ直下のレイアウトを除くUI
Organismは作者のサイトをみても抽象的なことが書かれており、捉え方が千差万別です。 なので、使用しないか、プロジェクト、チームごとに再定義することをおすすめします。
私は、*ページ直下のレイアウトを除くUI* と定義しました。
ヘッダー、ページコンテンツ、ナビ、フッターなどが該当します。
Molecule
- AtomやMoleculeを組み合わせたもの
AtomとOrganismに当てはまらないすべてのコンポーネントがここに分類されます。
Atomのみで構成すべきと主張する意見もありますが、作者が提唱しているスタイルガイドのページでもMoleculeの中にMoleculeがあります。
新たなルールが増えるのであまりおすすめはしません。
もし、肥大化する場合は、HTMLのsection要素のように、完全に独立して使用できるものはOrganismにするか、別のグルーピング種別を用意し間引くのも手だと思います。
Template
使用していません。
意見が分かれるところですが、ページテンプレートを共通化する意味があまり見当たりません。
Pages
これは、実際に動くページですね。なので、再利用化、コンポーネント化の時点でこの考えは不要です。
ページごとに実装するタイミングで、Atom, Organism, Moleculeなどの共通コンポーネントとは別のディレクトリで実装していきます。
アトミックデザインに該当しない、そのページ固有のスタイルなどはすべてこの個別ページに作成していきます。
ディレクトリに関しては、別途別記事でご紹介します。
最後にスタイルガイドを作成する
実際にコードを書き始めたら、
コンポーネントを作成した時点で、FEとデザイナー双方への共有のためにスタイルガイドを作成しましょう。
- デザイナー、エンジニアともに人が入れ替わった際に、どのようなコンポーネントがあるのか把握できる
- 実装する際に同じコンポーネントを作ってしまうことを防止する、コードを再利用する
実際はStorybookを導入するか、最短工数でやるなら、コンポーネント専用の開発用Pageを追加し、アトム、モレキュール、オーガニズムを配置しましょう。
まとめ
以上を実践すると、アトミックデザインは、UIを分類し、再利用する際に非常に有効な方法です。
アトミックデザインは銀の弾丸ではなく、そしてデザイン手法でもなく、
実態はコンポーネントのグルーピング、再利用の話です。
特に、エンジニアの観点では、コンポーネントを探すときにある程度どのグループにあるか予測でき、発見しやすくなります。
コンポーネントを探すという行為は、1日になんども発生するのでとても重要です。
また、CSSの設計手法であるSMACCSやBEMなどのように、
すでにあるていど広まっている設計手法だと、
ドキュメントを作成する必要がなく、チーム内で使用しやすいです。
アトミックデザインを通して、コンポーネントの付き合い方を今一度考えてみましょう。