第8章 分類に迷ったとき

UIの大きさではなく、何の境界を作っているかで判断します。

5つの問い

Part
「どう見えるか」（状態を持たない）

Component
「どう操作できるか」（状態を持つ）

Island
「この機能は何を管理するか」

Bridge
「複数の機能はどう協調するか」

Scaffold
「この画面をどう成立させるか」

上から順に問い、最初に「はい」と答えられたところがその要素の単位です。

順序が下から上ではなく上から下なのは、狭い責務から確認するためです。「どう見えるか」で説明がつくものを Island にすると、必要のない状態と機能をそこへ集めることになります。

レスポンシブで迷ったとき

この要素の内部だけが変わるか？
→ その要素自身

複数Islandの配置関係が変わるか？
→ Scaffold

Island同士の論理関係が変わるか？
→ Bridge

判断がつかないときの追加の問い

Component か Island か迷う。 → その部分だけを別の画面へ移したとき、機能として成立するか。成立するなら Island。

Part か Component か迷う。 → その要素が自分で状態を持つか。持つなら Component、持たないなら Part。アニメーションや読み込み状態も状態に数えます。 → 持たせるかどうかは設計の選択なので、どちらにしたいかを先に決めて構いません。Part にしたいなら、その状態を外から受け取る形にします。

Scaffold か Bridge か迷う。 → その状態は画面全体に影響するか、特定の Island 同士だけの問題か。後者なら Bridge。

Island が Island を含んでいるように見える。 → 含んで構いません。ただし、内側の Island の状態が外側から必要とされるなら、それは1つの Island に統合するか、Bridge を挟むべき状況です。

通しで分類する

個々の判定ではなく、1つの画面をまるごと分類する手順は 第6章 適用のしかた にあります。

• 既存のページをほぐす場合 — 状態を書き出し、読み書きの顔ぶれから Island と Bridge を割り出す
• 新しい画面を作る場合 — Island を1つ作り、必要が生じた順に境界を足していく

この章の問いは、その手順の中で個々の要素を判定するときに使います。

分類は変わってよい

最初 Component として作ったものが、状態と機能が増えて Island になることがあります。逆に、Island として作ったものから機能が抜けて Part になることもあります。

分類は要素の性質に付いたラベルであり、性質が変われば分類も変わります。変わったときに名前と置き場所を直すことが、この手法を使う実際の作業です。

この手法が答えないこと

上に置かれた単位だから必ず大きい、という関係ではありません。

UI Boundary Architecture が表すのは、UIの物理的な粒度ではなく、責務と状態所有の境界です。

したがって、次のような問いには答えません。

• どこまで細かくコンポーネントを分けるべきか
• ファイルを何行までに収めるべきか
• デザインシステムの部品をどう命名するか

これらは別の基準で決めてください。

特に1つ目の粒度については Atomic Design が答えを持っています。 Atoms と Molecules は、Part と Component の内側にある大きさの目盛りとして併用できます(→ 第5章 既存の設計手法との比較)。

この手法が決めるのは、責務の切れ目と、状態の置き場所だけです。