イブがクリスマスの後にやって来ました。
アトラエアドベントカレンダー24日目の記事です
Atomic Designの話をしようと思います。
デザイナーの視点から、Atomic Designのコンポーネントのイメージしづらい部分をどう捉えるとよさそうかを書いて見ようと思います。
課題感：分子と有機体の境界線
私が最初に当たったのが「分子と有機体の境界線がわからない」ということでした。定義では理解しているつもりでも、実際にデザインする段階になるとイメージがしづらいポイントだと感じました。
複雑さや抽象的な目的は定義として曖昧です。実装までをイメージすると、明確な定義があったほうがデザインを詰める段階ではとくに重要になるはずです。
コンポーネントの目的で分類してみる
そもそもAtomic Designはコンポーネント設計におけるフレームワークです。
各コンポーネントが何を目的として設計されているかを整理して考えてみます。
| Atomic Design | デザインの関心 | コンポーネントの進化のベクトル |
|:---|:---|:---|:---|
|原子|デザインのトンマナ | デザインの変更 / 機能の明瞭性 |
|分子| 行動を阻害しない機能を提供 | 機能の明瞭性 |
|有機体| 行動を促す独立したコンテンツ | ユーザー体験にあったコンテンツの見せ方 |
|テンプレート| ページのレイアウト（情報設計） | ユーザー体験にあったコンテンツの配置 |
こんな感じです。
あらためて、関心の範囲から有機体というものを捉えてみる
そのコンポーネントがもつプロパティも「従業員のデータ」や「今日の友人の投稿」など、そのプロダクトの特性に強く依存する具体性の強いものになります。（内容適当です）
そのプロダクトが独自に持つデータ、つまりコンテンツに強く依存するコンポーネントは有機体です。
逆にコンテンツに依存してしまったコンポーネントは分子になりえません。それはコンテキストに強く依存するので、汎用化しづらいからです。
結局の所、Atomic Designでは何を目的にそのコンポーネントが集められたかが重要なのであって、それが共通化できるかどうかや複雑かどうかはあまり関係ないと考えたほうが、かえって齟齬がなくてわかりやすいかもしれません。
デザインへのフィードバックに活かす
すこし余談かもしれませんが、上記の例がうまくいけばデザインのフィードバックもエンジニアと共通言語をもってコミュニケーションすることができるようになります。