AtomicDesignで見落としがちなこと

2019-10-08

コンポーネントのデザインシステムとして有名な AtomicDesign ですが。

ここ最近かなり流行ってきてるなぁと感じてます、こことか、理想的なプロジェクト進行をしてるなと。

日本語の記事も充実してきていて、相変わらずとんちんかんな記事も散見されつつも、的を得た記事も増えてきたなと。

そんな AtomicDesign ですが、日本語の記事ではここが足りていないなーという思想もちらほら気づいてきました。

なので、今回はそれをだらだら書き記しておこうと思います。


静的なデータと動的なデータは分ける

しょっぱなから今回一番伝えたいことです。

公式が認めてるサンプル、Pattern Labを見てもらうとわかるのですが。

ORGANISMS の The Grid とかわかりやすくて、ここの背景には山の画像が流し込んであります。

にも関わらず、その上の Media List Section には各サムネイルには画像が流し込まれていません。

で、Media List Section に画像が流し込まれるのは、PAGES の粒度になってからです。

これはつまりどういうことかというと、

  • The Grid  の背景は不変なため、ORGANISMS の段階で確定している静的なデータである
  • Media List Section の各サムネイルは可変なため、ORGANISMS の段階で確定していない動的なデータである

ということになります。

つまり、ATOMS から TEMPLATES までの範囲における、他のあらゆる要素にも同じことが言えます。

ATOMS であろうと TEMPLATES であろうと、その要素が確定したら、その段階で静的なデータとして定めることが重要です。

また、このことを意識すると、AtomicDesign で悩むケースがぐっと減ります。

静的なスタイルと動的なスタイルを意識する

上記の例は画像なので静的か動的かの違いがわかりやすいですが。

サイズ感やフォントサイズ、余白などのスタイルも実は同様で、確定した時点で静的なスタイルとなります。

なので、たまに「ATOMS の段階で余白を持たせてはいけない」という記事がありますが、あれは半分正解です。

正しくは、「余白はその ATOMS を使用する場所ごとに異なるため、ATOMS の段階では余白を持たせることができない」となります。

また、Pattern Labではスタイルを上から流し込むということをしていません。

これはつまり、子の要素に対して親からスタイルを流し込んではいけないということなのかなーと。

React 的に言うなれば、style や styleName はもちろんのこと、スタイリング目的で props に className を渡してはいけないということなんでしょうね。

AtomicDesign を理解するには、ペーパープロトタイピングが一番の近道

Web デザイナーにせよフロントエンドエンジニアにせよ、AtomicDesign を理解するのは、意外と難儀します。

なぜ理解が難しいかというと、具体的なイメージが思いついていないからに他ならないと思っています。

なので、開発を行う前に、一度実在するサイトを紙に書き出して、実際に作ってみるとわかりやすいと思います。

このとき大切なのは、ATOMS からちゃんと要素ごとにハサミで切り出すこと!

ATOMS を切り出して、それを MOLECULES に組み合わせようとしたとき、必然的に、紙の上に紙を重ねることになります。

これが AtomicDesign を理解する上でとても大切なポイントで、個人的に AtomicDesign の真髄なのかなーと思っています。

ただ、ペーパープロトタイピングだと、動的なスタイルが意外と見落としがちになります。

そこはきちんと文字で補足しておくことが重要です。

React や Vue などの FW と相性が抜群に良いわけではないことを理解しておく

個人的に、AtomicDesign はむしろレガシーな手法だと思っています。

特に昨今流行っている JavaScript 製の FW は、本当に便利な機能が多く、AtomicDesign では、その機能を使いこなせないこともしばしばあります。

わかりやすい例としては、React では children という props が扱えますが、AtomicDesign ではこれが逆に悩ませてきます。

極端な話、AtomicDesign では children を使わないようなデザインシステムが採用されているので、むしろ使わないほうがすんなり落とし込めます。

ただ、React 的には children を使ったほうがすんなり実装できるケースのほうが多いです。

そのため、こういった自体においては、何らかの妥協点を設ける必要があるのかなーと思います。

ちなみに、AtomicDesign を完全に踏襲した場合、Pattern Labのように、TEMPLATES と PAGES が 1 対 1 の関係になることがほとんどです。

これでも実装自体は可能ですが、この場合、PAGES がものすごく肥大化してしまい、UI が複雑なサイトによっては破綻してしまいます。

特に、フォームがあるケースなどは、かなり悲惨なことになります。

また、props のバケツリレーも多発しますので、そういった意味での恩恵は少ないかもです。

なので、特に上位レイヤー(ORGANISMS から PAGES あたり)については、ある程度柔軟な設計と、さらに厳格な独自のルールが求められると思います。


AtomicDesign 自体は本当にシンプルなもので、それを独自解釈しなければ、どんなサイトであってもある程度は落とし込めます。

ただし、決して銀の弾丸ではないため、サイトのデザインによっては、そもそも AtomicDesign の思想に合わせれないケースもありますし、そもそも導入しない方が良いケースも間違いなくあります。

どちらかといえば結構おかたい思想ですが、あまり柔軟性を持ち込むべきではなく、まずは思想に忠実に従うのが、効率化につながるのかなーと。

© 2018 kk-web