内容

Atomic Designの本を読んでみたので、要点をまとめていきます。

この本で学べること

コンポーネント・ベースの設計のメリットや考え方
Atomic Designを用いたコンポーネントの分割方法
トーン＆マナーを揃えるためのポイント
コンポーネント・ベースのテストについて
エンジニア以外の人とAtomic Designというフレームワークを使ってコミュニケーションを取る方法

第1章 UI設計における現状の問題を振り返る

UIの見た目から与えられる情報が適切なこと
UIが期待通りに動作すること
UIが効率的で最小の工数で目標を達成すること
UIが適切なタイミングでフィードバックを返すこと
ユーザーがミスを犯してもすぐに修正可能なこと
ユーザーが安心してアプリケーションを遷移出来ること
それ以外でストレスがないこと

OOCSSなんで初めて聞いた。。
スタイルガイドなども触ったことがなかった。

第2章コンポーネント・ベースのUI設計

2章では、コンポーネント・ベースでUIを開発するメリットやコンポーネント設計について書かれていました。

コンポーネント化のメリット

コンポーネント単位でテストできる
不具合のリスク・ポイントを減らすことができる
メンテナンスがしやすくなる
解決する問題が小さくなる

効率化

再利用で実装量を減らす
平行開発で待ち時間を少なくする
仕様変更による手戻り作業を最小化する
新規参入開発メンバーを最短で戦力化する
複数のテスト・アプローチでテスト工数を下げる
複数アプリケーションの開発を容易にする

基本設計

カプセル化されている
置換可能である
再利用可能である
コンポーネントを別のコンポーネントを組み合わせて作成可能である

コンポーネント設計で注意する原則

単一責任の原則
- ひとつのコンポーネントはひとつのことにしか責任を持つべきでないという原則です。例えば、表示に関する責任とデータの整形や条件分岐などのロジックを混合させるべきでないということです。これらのことをやってしまうと、不具合が生じたときに問題の究明が遅くなったりテストがしにくかったりと保守性の問題に繋がります。
関心の分離
- 単一責任ではコンポーネント単位の話でしたが、こちらは層ごとの責任に関してです。
  同じ層に属するコンポーネントは同じことに関心を持たせるようにすることで開発がしやすくなります。
  - 具体的には、
    - Atoms：デザインの統一性
    - Molecules：行動を阻害しないコンテンツ
    - Organisms：行動を促すコンテンツ
    - Templates：画面全体のレイアウト
    - Pages：アプリケーションそのもの

です。

関心や責任を分離し一つの責務に関わることに集中できることで、開発やテストがしやすいだけでなくユーザビリティの向上にも繋がります。
また、上位の（より具体的な）コンポーネントの変更が下位のコンポーネントの影響することはありません。

第3章　Atomic DesignによるUIコンポーネント設計

Atomic Design はデザインシステムを作る方法論となります。UIデザインはアプリケーションを使うユーザーがUIを通じてどのように行動してほしいかをデザインすること

UIデザインを階層化アーキテクチャの概念を取り入れて設計するもの。

例)
Template: 画面全体のレイアウト
Organisms: ユーザーの行動を促すコンテンツ
Molecules: 行動を阻害しないコンテンツ
Atoms: デザインの統一性

階層化のメリット

全体を考慮する必要がなく1つの層の責務に関わる課題だけに集中できる
同一層に属するコンポーネントであれば差し替えることができる
上位層のUIコンポーネントの変更が下位層に影響することがない。
- 上位層と階層は影響度が違う。階層の方が影響が少ない

Atoms（原子）

「それ以上UIとしての機能性を破壊しない最小要素」

適用箇所

プラットフォームのデフォルトUI
プラットフォームのデファクト・スタンダードなUI
レイアウト・パターン
セマンティックなデザイン要素

Molecules（分子）

Molecules（分子）は、Atoms を組み合わせて作る要素です。
この Atoms を組み合わせて Molecules を作るというのは「単一責任の原則」や UNIX 哲学の「1 つのプログラムは 1 つのことをうまくやる」に基づいているようです。

Molecules になることで意味を持つ要素となります。
たとえば、Atoms であるラベル・入力フォーム・登録ボタンという 3 つのコンポーネントがあってもそれら単体は意味をなしません。
しかし、これらの要素を組み合わせることにより「ラベルで示したことに応じて、入力フォームに何かを書いて、登録ボタンを押す」という意味が示せるようになります。『ラベル・インプット・ボタン』というAtomsの組み合わせは、Moleculesで『入力ボックス』になるのです。
同じAtoms層コンポーネントを使っていても、Molecules層によって違う役割を与えられるのは、Atoms層が抽象的な機能だけ持つように作られているからです。
もし、ボタン自体に「メッセージを投稿する」という処理をコンポーネントの機能として含めていたら、そのボタンは検索フォームには使えません。
「ユーザの関心に強く影響するのは　Molecules層であり、ユーザがAtomsを意識することはない」

ユーザーがMoleculesを通じてやりたいことを簡単にするためには、

以前に使ったことがある、または直感的に使い方がわかる形をしている
似た形をしたものは常に同じ挙動をする

Organisms 有機体

Moleculesはユーザーの関心事に対して機能を提供しましたが、Organisms層はコンポーネントで完結するコンテンツを提供します。
たとえば、instagramにあるユーザーの投稿を表示するコンポーネントはOrganisms層に分類されます。

AtomsやMoleculesを組み合わせてできる『Organisms（有機体）』は、非常に複雑なデザインを可能にします。

特にMoleculesとOrganismsの分け方

molecules: 独立して存在できるコンポーネントではなく、他のコンポーネントの機能を助けるヘルパーとしての存在意義が強いコンポーネント
Organisms: 独立して存在できるスタンドアローンなコンポーネント

ここの記事が参考になるかもしれません。

Atomic Design の理解 : molecules と organisms をどのように分割するか
https://frasco.io/atomic-design-molecules-organisms-dc937b5989

Templates（テンプレート）、Pages（ページ）

Templates層の目的は、コンポーネントがページ上で正しくレイアウトされるかを確認することです。
『ページ構造の説明画面』で、絵画のラフ画やスケッチ画に相当します。ワイヤーフレーム（配置図・設計図）とほぼ同義と覚えておいてもよいでしょう。
このデザインが実際にどのように配置されるのか、それらをTemplatesで『見える化』していきます。特に、レイアウト部分や、MoleculesとOrganismsの組み合わせで不具合が生じている場合は、ここで修正していきます。

Template層のコンポーネントに実際のコンテンツを流し込んだものがPagesです。
実際のコンテンツが流し込まれた、ユーザーが目にする『最終製品』が表示され、美しく機能的なUIデザインで、ページをチェックできます。

第4章　UIコンポーネント設計の実践

4章は、実践編です。あるページのデザインが与えられ、実際にAtomicDesignで分割していきます。

Atoms、Molecules、Organisms、Templates、Pagesに実際に分割する
分割する際のポイントや基準の解説
　- Atomsは抽象度が高いコンポーネントにするよ
　- ロジックと表示に関する責任は分離するよ（諸説あり）
　など

レイアウトしやすいコンポーネントの特徴はこんな感じだよ
適切な命名の付け方について
などなど、実際に実務で使える知識が満載でした。

エンジニアには馴染みのない、アプリケーションのデザインの統一性の話など、デザイン観点での解説もとても有意義だと思いました。一方で、SFCやHOCに関する話題が載っていたので、Reactに関する情報は少し古いと感じました。

Storybookなどを使用しているので勉強になりました。今後チュートリアルをしてみようと思いました。
https://www.learnstorybook.com/

ここからダウンロードします。
https://gihyo.jp/book/2018/978-4-7741-9705-0/support

第5章　UIコンポーネントのテスト

5章は、コンポーネントのテストについてです。
フロントのテストに関する、テストのポイントや用語がたくさん載っていて、とても勉強になりました。

UIが適切に分かれていれば、テストが簡単になる
Enzymeを使ってインタラクションテストをする
　　インタラクションとは、ユーザーのアクションを適切にUIが処理しているかどうかのテスト。

レスポンシブデザインのテスト
パフォーマンスのテスト
「情報アクセシビリティ」「Webアクセシビリティ」という考え方

　視力や聴力の違いのような身体的特徴による差異だけではなく、ユーザーが一時的に片手でスマートフォンで利用している場面やネットワーク帯域が狭い場所でも利用している場面などでも利用しやすくすること。

アクセシビリティを確認するChrome拡張でテストが行える。

第6章　現場におけるコンポーネント・ベース開発のポイント

6章では、エンジニア以外の人を巻き込んだAtomic Designの使い方について説明されていました。

エンジニアとデザイナーで問題解決の方法が違う
そのすれ違いをフレームワークを使ってどのように解決するのか
コンポーネントリストを作ってエンジニア以外の人も触れる環境を作る
などです。

参考

Atomic Design 〜堅牢で使いやすいUIを効率よく設計する〜を読みました
https://miyamizu.hatenadiary.jp/entry/atomic-design

Atomic Designの考え方と利点・欠点
https://blog.kubosho.com/entry/using-atomic-design

Atomic Design読んでみた
https://dragon-taro.com/technology/post-568

Atomic Design ～堅牢で使いやすいUIを効率良く設計する読了
https://kudakurage.hatenadiary.com/entry/2018/05/01/005401

「Atomic Design ~堅牢で使いやすいUIを効率良く設計する」を読んだ
https://massa142.hatenablog.com/entry/2018/09/09/132720

アトミックデザインとは？考え方やメリットデメリットを解説
https://offers.jp/media/design/a_860

Atomic Designってデザイナーには難しくない！？という話
https://qiita.com/rhirayamaaan/items/7f990e146ec01f2e7e08

Atomic Design の理解 : molecules と organisms をどのように分割するか
https://frasco.io/atomic-design-molecules-organisms-dc937b5989