内容
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