Atomic Design ～堅牢で使いやすいUIを効率良く設計する 読了

design

Energy Book - Atomic Energy

昨今ではデザイナーの間でも、アプリやサービスに使われる色やテキストなどをまとめた「スタイルガイド」や、デザインコンポーネントをまとめた「パターンライブラリ」、さらにそれらを全てまとめてドキュメント・原則・思想なども含めた「デザインシステム」などを作りながら効率よくより良い体験を提供できるように開発できるようにしようという取り組みがよく見られます。

DropboxやAirbnbなどをはじめとして積極的に自社サービスの「デザインシステム」を公開している企業も多く見られるようになってきました。

それにともなって、自分たちでも作ってみよう・開発現場に取り入れてみようと取り組み始めているという話もよく聞くようになってきましたが、どんな風にどんなところから手を付けて良いか？というのは良く聞く質問です。

「デザインシステム」を考えていくにあたって、設計の手法・考え方の一つにAtomic Designという方法論があります。 今回読んだ「Atomic Design ~堅牢で使いやすいUIを効率良く設計する」という本は、フロントエンドエンジニアから見た（主にWebサービス開発における）Atomic Designでの設計方法・注意すべきこと・実務への実践的な取組方法をまとめた話という印象を受けました。

Atomic Designはユーザーの課題を解決するための体験などを設計する手法ではなく、開発コストを小さくしながら素早く改善できるように設計する手法です。ユーザーの課題解決などの大きく抽象的な部分に特に注目することの多いデザイナーにとっては、後回しにしがちなところもあるかなと思います。

しかし、開発の早い段階から変更可能性を考慮して作って置くことのメリットは大きいです。 また本書は、主にエンジニア目線で書かれた内容ではありますが、Atomic Designはエンジニアだけがコミットしてもなかなかうまくいかないと思います。デザイナー側も設計の意図やメリットをよく理解し、お互いが協力して取り組むことで最大限効果を発揮できるとも言えます。

最近ではSketch Appなどを始めとしたUI Design Toolで使いまわすStyleやUIコンポーネントをシンボル化して、ライブラリなどのようにして共有するということも普通になってきているので、Atomic Designの考え方自体は非常に役立つ部分だと思います。

それを実際のエンジニアの開発現場ではどのように活用して、デザイナーとしてそこにどのようにコミットしていけるのかというのを知っておいて損はないと思います。

本書の構成

本書では大まかに次のような内容で構成されています。

  • １章
    • 現状の開発現場の背景
    • 開発現場でよくある問題
  • ２章
    • なぜAtomic Design的な設計が必要なのか
    • そのメリット
  • ３章
    • Atomic Designとは何か？
    • Atoms, Molecules, Organisms, Templates, Pagesについてと、その分類の仕方
  • ４章
    • Atomic Designを用いた実装方法
    • React.js, Storybook, CSS Modules, Fluxなどを用いた実際の実装方法
    • Atomic Designにおける命名規則の考え方
  • ５章
    • UIコンポーネント開発における様々なテストの実装方法
    • 単体テスト、ロジックテスト、インタラクションテスト、レイアウトテスト…など
  • ６章
    • 導入時によくある開発現場の問題とポイント

１〜２章は前置き的な内容、３章はAtomic Designの考え方についてです。 ４〜５章では実際の開発現場でどのように取り組んでいくのかという具体的な内容が書かれているので、どちらかと言うとエンジニア向きの内容です。もちろんデザイナーでも理解しておくと良い内容ではありますが、ざっくりとどんな雰囲気なのか知っておくだけでも良いかと思います。

コンポーネントの分類

Atomic Designの導入時などに困っているとよく聞く話の一つとして、どこに分類したら良いのかという問題があります。 特に悩ましいのはAtomとMolecules、もしくはMoleculesとOrganismsの辺りでしょうか。

本書ではそれぞれの階層がもつ「関心事」に注目して分類する方法を説いていて、これは非常にわかりやすく明快であるなと思いました。

  • Atoms
    • 「どのように」の部分の機能を提供する要素
    • 「ユーザーが何をしたいか、ユーザーに何をさせたいかについては、一切関与しない」
      • ユーザーは「Button」をクリックしたいわけではない（クリックすることが目的ではない）
      • クリックできる「Button」という手段のみを機能として提供する
    • Atomを構成する要素にAtomは含まれない
  • Molecules
    • 「ユーザーが何をしたいか、ユーザーに何をさせたいか」という機能を提供する要素
      • ユーザーは「Button」をクリックしたいわけではない（クリックすることが目的ではない）
      • ユーザーはキーザードで検索したい -> 「Button」と「Input Field」で構成される「Search Form」
    • 具体的なコンテンツは含まない
    • 独立して存在できるコンポーネントではなく、他のコンポーネント（Organisms）の機能を助けるヘルパーとしての存在意義が強いコンポーネント
    • Atomsの組み合わせで構成される
  • Organisms
    • 単独で成立するコンテンツ
    • どんな情報がコンテンツとして表示されるのかがわかる名前
    • AtomsとMolecules、Organismsの組み合わせで構成される

特にMoleculesとOrganismsの分け方は非常に難しいところですが、それがModulableに他のコンテキストでも利用できるか（Molecules）、具体的なコンテキストを含むコンポーネントであるか（Organisms）という具合に分けると良いのではないかと。

すごく悩ましいのは、ImageとTitleとTextがレイアウトされたひとまとまりのオブジェクトで、汎用性の高いコンポーネントを考えた場合ですね。 この場合、ImageやTextなどを含んでいますのでAtomsではありませんが、具体的なコンテキスト情報を含まず、構成要素の種類とレイアウトのみを提供するコンポーネントですので、Organismsとも考えにくいです。 これが具体的なNewsListItemとかですとOrganismsですが、汎用性の高いListItemとして定義する場合は少し例外的なMoleculesなのかなぁと。

しかし、よくよく考えてみるとよりModulableな考えから、レイアウトという機能をのみを提供するとも考えられます。 ImageやTextという固定のコンテンツを含んでいるのではなく、ImageやTextや他の様々なコンテンツを含めることができるレイアウトのみの機能という考え方です。 この場合はAtomsであると考えることができて、本書でもそのように書かれています。

まぁこのあたりは実際に開発を進めていくと、結局コンテキストに合わせて個々の微妙なカスタマイズを必要とすることがあったりするため実際は似たようなOrganismsをコンテキストに合わせて作っていくのかなぁと。

Designにおける最小構成要素

サービスのUIをDesignしていくにあたってAtomsよりも小さい構成要素があります。 colorやfont familyといった属性的な要素です。 これらはButtonといったAtoms要素の中にも含まれるもので、これらはAtomsというよりはそれよりも小さいStylesやAttributionsみたいなものになるのかなぁと思います。 これらはWeb開発ではSassなどのCSSプリプロセッサーにて変数として扱われるものばかりですね。 そういう観点から見るとcolorやfont familyという以外にも、角丸の大きさやShadowのルール、fontサイズの規則やアニメーションなどもこれらと同列なものであるとわかります。

まとめ

Atomic Designはあくまで設計手法・考え方の一つですので、これに則してガチガチに考える必要はありません。 ですが、よりModulaleで使いまわしたり、効率よく開発・改善していくにあたって非常に優れた設計方法であると思います。 またエンジニアとデザイナーがどのように協力をして開発を進めていくのかという部分で、本書を参考にして実務に取り入れてみると良いと思いました。

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

Atomic Design ~堅牢で使いやすいUIを効率良く設計する