Atomic Design への誤解で生じたデザインとフロントエンドの溝 - 有効性について再考する
はじめに
Webフロントエンドで UI を構築する際に、Atomic Design という考え方を取り入れる機会は多くありました。しかし、Atomic Design の考え方はデザインとフロントエンド間で混乱が生じることも多くありました。
そこで、Atomic Design の有効性とこれからの考え方についてまとめようと思います。
ちなみに、再考するきっかけになったのは、Atomic Design の発案者である Brad Frost 氏が「Is Atomic Design dead?（Atomic Designは死んだのか？）」という登壇を行うことになったからです。（私はこの登壇を楽しみにしています。）
この登壇を聞く前に、私自身の思考を整理したいと思い、本記事を書きました。
もし、Atomic Design に関してのブログ記事を読んでいない方は、ぜひこちらを読んでみてから、本記事を読んでみてください。
結論
- Atomic Design によるコンポーネントの分類は特に意味がない
- UI が果たす役割を明確にする方が意味がある
Atomic Design に対する疑問
まず、Atomic Design は素晴らしい考え方だと思っています。
Atomic Design によって UI の構造は、要素を分離し、組み合わせることによって、一貫性やコンポーネントの再利用性を高めることに意識が向くようになりました。
しかし、Atomic Design はフロントエンドの実装や構造を最適にする考え方ではありますが、デザイン（Figma）ではどうでしょうか、基礎となる構造やコンポーネントの組み立て方を理解するのに Atomic Design は役立ちましたが、デザインやシステム構築の助けになったのでしょうか
Atomic Designとは少し違うアプローチが必要になってきていると考えています。
Atomic Design の分類
提案された Atomic Design の分類
- Atoms(ボタン)
- Molecules(インプット + テキスト)
- Organisms(メニュー)
- Templates(ページのレイアウト)
- Pages(テンプレートのインスタンス)
Atomic Design が招いた誤解
- HTMLの Atoms はデザインの Atoms ではない
- デザインにおける Atoms の定義は曖昧である
- デザインツール(Figma)内の整理をする時に混乱を招くことがある
HTMLの Atoms は Figma の Atoms ではありません。
HTML の input フィールドは HTML では単一ですが、Figma では少なくとも2つから構成されます。
外側に Frame があり、内側に Text があります。この input フィールドはフロントエンドでは Atoms ですが、デザインでは Molecules になります。
さらに input フィールドに email の icon があったとしましょう。この inputフィールドは2つの要素なのか、それとも3つの要素なのでしょうか
フロントエンドでは、アイコンの配置は CSS を使ってフィールド内にスタイリングするか、HTML内に配置してスタイリングするかによって、要素の数は変わっていきます。
デザインとフロントエンドの構造は根本的に異なっていたのです。
もちろん、デザインとフロントエンド の対等性(Single Source of Truth)は目指しますが、単純な Atomic な分類をすると問題が生じてしまいます。さらに Atoms で発生した曖昧な定義はより複合的な要素(Molecules, Organisms)に影響し、概念は理解しにくくなるでしょう。
Atomic な分類を導入しても利益が少なく、デザイナーや開発者への説明や共通認識を持つのが難しくなり、デザインやフロントエンドでの溝を深め、混乱を招いてしまったと私は考えています。
何度も言いますが、Atomic Design は素晴らしい考え方だと思っています。
用語を厳格に定義し、守ることが Brad Frost 氏の伝えたかったことでもなく、むしろ私たちの文脈に合った方法でコンセプトを構築することが重要だと教えてくれたのだと思っています。
小さくシンプルで再利用可能な要素が大きく複雑で再利用可能な要素を作るという考え方は、デザインとフロントエンドへの横断的なシステムとして、今でも効果を発揮しています。
ですが、Atomic Design という言葉によって "ユースケースの理解" よりも "コンポーネントの分類" について意識が高まってしまったのではないでしょうか。
Atomic な分類の代替案は Scenario Based Design
これまで述べたことは当たり前のことかもしれませんが、アプローチには様々な方法があり、Atomic Design はそのうちの一つです。より適切なアプローチがあるかもしれません。私が気になっているアプローチは Scenario Based Design です。
Scenario Based Design は、ユースケースやシナリオを中心にコンポーネントをまとめる方法で、デザインと開発の間で共通の認識を持ちやすくなります。これにより、ユーザーが操作する一連の流れで各 UI（Patterns）が果たす役割を明確にし、一貫した体験を実現できるでしょう。
もしも、具体的に挙げるなら
ユースケースやシナリオを持たない Atoms, Molecules, Organisms を Components としてまとめてしまい、ユースケースやシナリオを持つ Components のまとまりを「Patterns」とグループ分けすることになるでしょうか
Scenario-Based Design についてはこちらのスライドを見ると理解しやすいと思います。
さいごに
私たちに適した分類法や構造を模索することが大切で、UI が果たす役割を明確にすることに集中した方がよいのかもしれません。
Discussion