Atomic Designについて

Atomic Designについてのまとめを書きます。

前提について

UI設計について説明を行う前に予め前提を知ってもらうことで、齟齬を極力減らす。

  • UI設計に正解はない
  • UI設計は難しい(ビジュアルは人によって捉え方が変わる、まるで国語のテストの様に)
  • 設計は臨機応変に変えていく(ここで示した通りの設計に従う必要はない)

UI設計の背景

バックエンドアプリケーション(ビジネスロジック)での設計は今まで多くのパターン(MVC,MVVM,MVP,DDD etc)が存在し、 これらは良く議論され、積極的に適用しているサービスも多い。

しかし経験上UIに関してバックエンドほど積極的ではない場合が多いように感じられる。

ここではUI設計を正しく行わないとどのような問題が発生するかについて説明する。

UI設計が正しくできていないと何が困るのか？

コンポーネントが再利用されていない

ページごとにコンポーネントをそれぞれ作ってしまいがち。 そのため車輪の再発明を多くしてしまい、コード量・無駄な工数・コードの複雑化をまねき予期せぬバグの増加を引き起こしてしまう。

トーン＆マナーが揃えられていない

上記問題にも関連するが、再利用性が低いとデザインをそれぞれ個別で開発してしまい、 ページごとにデザインが若干異なり全体の統一感がなくなりユーザーに対して良くない印象を与えてしまう。

デザイナーとのコミュニケーションコストが上がる

デザイナーがカンプを作り、開発者がそれを元に作成し、再度デザイナーにチェックを行い OKサインが出ないのであればまた開発というループを繰り返し、非常に効率が悪く、コミュニケーションコストが高くなってしまう。

テストの難易度が上がる

コンポーネントが細かい粒度で分割されていないと、大きい粒度でコンポーネントをテストするしか無いため、 テスト環境を整える手間や、テストケースの増加などテスト難易度が上がる。 これによりテストコードのないレガシーコードとなってしまう可能性が高い。

変更に弱い

再利用性が低くいことから、同じデザインであってもそれぞれ独自のコンポーネントを作成している可能性が高いため、 共通的に使用しているデザインに変更があった場合でも、それぞれの画面に変更を加える必要があるため工数が増え、非常に効率が悪い。

新しく開発者が加わったときに独自の開発をしがち

新しく開発者が加わった時、UI設計の指標となるものが存在しないとコードを読んで理解するしか無く、 またコードもUI設計の指標が無いと統一感がないため、独自の開発が進みさらに保守性が下がる。

Atomic Design とは

UIを実装するためには上記理由から何かしらのルールが必要であることは自明であり、この資料ではUI設計の指標となる Atomic Design について説明する。

Atomic Design とはWebデザイナーBrad Frost氏が考案・提唱したデザインシステム。

また デザインシステム とは デザイナー・開発者が共通認識をするための「共通言語」である。 (DDDにおけるユビキタス言語っぽいもの)

Atomic Design の概要について公式ページを元に軽く説明を行う。

https://bradfrost.com/blog/post/atomic-web-design/

Atomic Designが解決すること

Atomic Design を使用することで 背景 に上げた問題を解決できる。

コンポーネントが再利用されていない

Atomic Designでは Atoms, Molecules, Organisms, Templates, Pages と粒度の大きさで、 コンポーネントを分離しており、また Molecules 以上になるとすでに作成されたコンポーネントを利用して構成されるため、 必然的に再利用性が高くなり冗長なコード・工数・予期せぬバグを減らすことができる。

トーン＆マナーが揃えられていない

上記の再利用性が高まることにより、デザインが整えられたコンポーネントを組み合わせるので、ページ単位でデザインが統一されトーン＆マナーが揃えられる。

デザイナーとのコミュニケーションコストが上がる

Atomic Design に従うことで、発生しうるコミュニケーションコストを下げることができる。 例えばデザイナーが Atom を認識しており、開発者にどれを使用するか説明すれば、開発後のデザインチェックが少なくなるため、 コミュニケーションコスト・工数が下がる。 またさらに、すでに実装されているデザインを変更したい場合も、 Atomic Design に従っていれば、それぞれのコンポーネントが 細かい粒度で分解され単純化されており、ロジックも分離されているため、デザイナー自身で変更することもできる。(デザイナーが変更を加えるハードルが低くなる)

テストの難易度が上がる

コンポーネントを細かい粒度で分解しているため、それぞれの粒度に合わせたテストが可能になり、 かつコンポーネントの責務も単純化されているのでテストケースも少なく書け、 より堅牢なアプリケーションを作成することができる。

変更に弱い

再利用性が高い開発を実現できるため、元となるコンポーネントのデザインを変更することで、 アプリケーション全体のデザインを変更することができ、変更に対し工数が少なくなる。

新しく開発者が加わったときに独自の開発をしがち

新規に開発者が加わった場合、 Atomic Design の原則、既存コードの コンポーネント (特に Atoms, Molecules) を把握することで、統一感を持った開発が比較的早くできる。

Atomic Designの方針

すでに気づいているかもしれないが、公式ホームページを読んでも、Atomic Designをするときに迷う点が幾つか存在知る。

以下主に感じる迷いポイント。

  • Molecules と Organisms の違い
  • どこまでが Atoms なのか

これらのポイントは主に Atoms, Molecules, Organisms の境界が公式で明快でないため発生するものだと考え、 以下これらの説明を詳細に記し、迷いが発生しないようにする。

Atoms

最大限抽象化した機能をもたせたコンポーネント。 要素としての最小単位ではなく、 機能の最小単位 になるまで分割をする。

わかり易い例が ButtonはAtomなのか、Moleculeなのか に載っているので参照のこと。

例えばボタンであれば、矩形と文字に分解できるが、それぞれの要素は単独で「クリックしたらある反応が起きる」という機能を再現できないため、ボタンの機能としては矩形と文字は分割できない要素である。

またAtoms はデザインの統一性(トーン＆マナーを揃える)を担い、全体を通してサービスに良い印象を抱くことを目的としている。

Atoms はより汎用的に使えるように、コンテンツ に依存しないようにする。

Atoms になる例

  • タイトル

  • レイアウト・パターン

レイアウトは特定のコンテンツに依存しない一つの機能である。

  • Divider セマンティックな(意味を付加するような)デザイン要素

Molecules

２つ以上の Atoms で構成される。 Atoms は「ボタンをクリックする」や「テキストを入力する」だけで、ユーザーがどんな動機でそれを行うのか、 という部分が抜けているが Molecules は 何のため に「ボタンをクリックする」のか、 何のため に 「テキストを入力する」のか、ユーザーに具体的な動機を示すコンポーネントになる。

つまりユーザーの関心に強く影響を与えることを目的としている。

また Molecules もより汎用的に使えるようにコンテンツについて依存しないようにする。

Molecules になる例

  • 検索フォーム
  • バッジ付き画像

Organisms

Organisms は Molecules と Atoms で構成されるコンポーネント郡。

Organisms は コンポーネントで完結するコンテンツを提供する。

Molecules と Organisms の違い

Molecules との違いは、 Molecules は独立して存在できるコンポーネントではなく、他のコンポーネントの機能を助けるヘルパー的な存在意義が強い

コンポーネントであり、Organisms は独立して存在できるスタンドアローンなコンポーネント。

Organisms になる例

  • 特集ニュースアイテム
  • 特集ニュースアイテムリスト

Atomic Designが定着するために必要なこと

コンポーネントの把握(特に Atoms, Molecules)

Atomic Design が本領を発揮する理由は、コンポーネントの再利用性にある。 そのため、予めどのようなコンポーネントがあるかを把握しておく必要がある。 特に Atoms や Molecules は使用頻度が高いため、これらは網羅しておきたい。 全体で集まる会議を設定し、現在どのようなコンポーネントが存在しているのかをすり合わせる 時間をとったほうが良いと考える。

この時コンポーネントの一覧を見れるツールを用いるのが良い (storybook)。

またデザイナーもこれらコンポーネントを把握することで、デザインカンプを作成するための参考となり、 開発者への指示も出しやすくなる。 上記により開発後にデザインの後戻りがなくなり、コミュニケーションコストの削減に貢献する。

デザイナーがコードへ関与する

Atomic Design はコードを粒度を細かく、より分かりやすいコードを目標としている。 またUIとロジックが分離しているため、デザインのみに特化したコードが多い。

そのためデザインシステムのないコードよりもデザイナーが参入しやすい環境が用意されるため、 デザイナー自身も開発へ参加し、より質の高いコードが提供できるはずだ。

参考

  • https://bradfrost.com/blog/post/atomic-web-design/
  • https://qiita.com/rhirayamaaan/items/7f990e146ec01f2e7e08#button%E3%81%AFatom%E3%81%AA%E3%81%AE%E3%81%8Bmolecule%E3%81%AA%E3%81%AE%E3%81%8B
  • https://www.amazon.co.jp/Atomic-Design-%EF%BD%9E%E5%A0%85%E7%89%A2%E3%81%A7%E4%BD%BF%E3%81%84%E3%82%84%E3%81%99%E3%81%84UI%E3%82%92%E5%8A%B9%E7%8E%87%E8%89%AF%E3%81%8F%E8%A8%AD%E8%A8%88%E3%81%99%E3%82%8B-%E4%BA%94%E8%97%A4-%E4%BD%91%E5%85%B8-ebook/dp/B07CJ5TLK2/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=atomic+design&qid=1594705467&sr=8-1

©Tsurutan. All Rights Reserved.