アプリケーションのUI（主にGUI）の設計・評価をする際、ほとんどの場合は評価の範囲が画面（ページ）単位で行われることが多く、この設計・評価のフォーカスの粒度についてもっと考えたほうがいいのではないかと最近よく思います。
画面単位での評価をしていてよくあることは…
画面 A 画面 B どちらにもリストがあり、そのリストは同じリストアイテムを表示していたりする場合でも、
「画面 Aとリストがー…」
「画面 Bのリストがー… 」
と同じリスト要素なのに画面単位で話をしてしまうことがよくあります。これはかなり無駄なことをしているように思えます。
もちろん、《そのデザイン要素はどういうコンテクストなのか》を議論する上で画面を持ち出すのは必要な事と思いますが、そもそもそのコンテクストは何に依存するものでしょうか？
それはコンポーネントとして分解していくと実は画面そのものにあまり依存していない事が見えてくると思います。
上の図のようにリストはリストアイテムを持っており、リストアイテムは表示や入力を促すだけだったりすることを考えると、画面のコンテクストからも少し離れています。
継承はあっても依存していない（他がなくても成立する）ものがすべて同じレイヤーで考えられているのは、色々な歪みや無駄を生むのではないかと思います。
画面 = 機能という概念を疑う
スマートフォンの画面の概念としてほとんどの場合、 1つの画面 = 1つの機能 という見方をされています。
一つの画面に複数の機能を置く事はユーザーに優しくないGUIであるし、全くもってその通りだと思いますが、この場合の機能とは一体どこからどこまでを指すのかは明言されていません。
また、ユーザーが画面を利用する時、視点は画面全体を捉えているというわけではなく、画面のどこかに中心視野がありそれ以外を周辺視野で捉えていることを考えると、画面 全体だけでソフトウェアのユーザビリティなどを考慮するのは曖昧な評価につながるのではないかなと思います。
機能が ユーザータスクの関心ごと なのか OSやPlatform・ブラウザににおけるGUIの関心ごと なのか、それを区別して考えることはUIデザインする上でもソフトウェアを設計する上でも重要だと思います。
つまり、UIの設計や評価の粒度は画面よりも小さい単位で考えた方がいいのではないかと思います。
そこでコンポーネント指向の登場です。
コンポーネント指向とは、ソフトウエアを機能ごとに部品（ソフトウエアコンポーネント）として分割し、必要に応じて組み合わせて使うという考え方である。
ちなみに、コンポーネント指向は様々な分野（サーバサイド、バックエンドなど）でも使われていてややこしいので UIコンポーネント指向 と自分は呼んでいます。
UIコンポーネントの粒度とAtomic Design
UIコンポーネントの粒度を決めるメソッドに Atomic Design というものがあります。
この Atomic Design 、デザイン時のパーツの粒度程度に捉えられがちですが実装まで考慮した場合、 ORGANISMS / MOLECULES / ATOMS はだいたいは疎結合なUIコンポーネントになるはずです。
疎結合とは、細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のことである。 疎結合では、個々のコンポーネント同士は相互に連携しているが、相互に依存している余地が少ない。
UIコンポーネントが疎結合であるということは、UIコンポーネントは与えられるデータを処理する一つの機能であり、それは主に 出力・操作・入力というインタラクション を持ったモノになります。
例えば、Header Navigation に 戻るボタン（Back Button） と 画面のタイトル（Screen Title） を置くとすると以下の関係になると思います。
ATOMS や MOLECULES は GUIの機能、ORGANISMS 以上をユーザーのタスク と呼ぶと、関心ごとのレイヤーとしては同じではないと考えられます。
ドアというコンポーネントを例にしてみる
コンポーネント指向では コンポーネントの親子関係では 親は子を知っているが子は親を知らないとして考えます。
- ドアは、ドアノブを知っていてもドアノブはドアの構造（丁番とか）を知る必要はない。
- ドアノブを回わすというアクションでラッチボルトが引っ込むけど、ラッチボルトはドアノブの構造を知る必要はない。
- ラッチボルトが引っ込んでデットロックも引っ込んで初めてドア全体の状態が変わる。
- 例えばラッチボルトに不具合があればラッチボルトから検証して、影響範囲がラッチボルトの交換だけならそこだけ対応すれば良い。
現実世界のものもこのように動いています。
デバイス画面内のものも 状態（State）やデータが降りてきて表示や振る舞いを促す という小さい機能の単位で動作すれば、子が親を意識する必要はないはずです。
つまり、子それぞれの処理速度や認知性・可読性（ラベリング・カラー設計・フォント…）など評価をした方がより具体的な問題点を探しやすいはずです。
UIコンポーネントの概念定義とOOUX
自分の場合はUIコンポーネントを次のレイヤーで分けています。
- デフォルトのGUIパーツ = ATOMS
- ユーザーの関心事（メンタルモデル）= MOLECULES
- ATOMS, MOLECULESを集約して状態管理するもの = ORGANISMS
- 画面は、ORGANISMSを集約し、ユーザーのタスクからルーティングの定義を行うもの
そしてこの方法は Object-Oriented UX : オブジェクト指向UX にとても似ている方法だと思います。
Object-Oriented UX (OOUX) とは…
実世界の物事とそれを説明した文書を区別するべきである。表現の前にリソースである。
引用: オブジェクト指向UX
以下の図は、OOUX: A Foundation for Interaction Design に掲載されている CTA (Call To Action) 表です。
SYSTEM’S OBJECTS はレシピサービスのシステムに存在する概念を抽出したもので、それらを基準に属性値や関連するデータ、包括する概念を表にしています。
- MAIN OBJECTS は概念モデル
- CORE CONTENT は概念が持つ属性
- METADATA は概念が持つ 関連するその他の属性
- NESTED OBJECT は概念が包括している子概念モデル
このように、OOUXは概念モデル（≈ メンタルモデル）が持つ属性などをコンポーネントに映し出して設計・定義をしていきます。
これはモデリングからコード設計を行う オブジェクト指向と似ています。
まず、エンジニアは問題の領域を構成するオブジェクトを綿密に計画することから始めます。これは、UXのWebサイトを作成する際にも最初にするべきことです。ワイヤフレームやプロトタイプを見た時に、デザインをリバースエンジニアリングしてオブジェクトを抽出します。そして彼らは、「オブジェクトXはオブジェクトYとどのように通信するのか。オブジェクトAは複数のオブジェクトBで構成されていのか。オブジェクトの属性は何か。このクラスのオブジェクトはあのクラスのオブジェクトを継承するのか。」と思うでしょう。
OOUXはドメイン駆動設計 に似ている
オブジェクト指向には ドメイン駆動設計（Domain-Driven Design = DDD） というサービスやシステムを抽象化した概念 を モデル にして整理しながら設計するものがあります。
DDD では、利用者や提供者などサービスに関連するヒト・システムの ユースケース から ドメインモデル という概念モデルを導き出します。
それを クラス というオブジェクトに置き換え、それらが持つ 属性 や 振る舞い を定義しつつ、概念化できない 技術的な部分に依存しているもの （データベースとの通信やプログラム的な所作など）などを分別して互いに影響を及ぼさないように コード にしていきます。
OOUX も 抽象化した概念 を モデル化 してそれをコンポーネント定義に落とし込んでいます。
違うとすれば、責務（UIの場合は、OSやPlatform・ブラウザに依存しているデフォルトのUIパーツなど）の分別がされていないくらいだと思います。
最適なUIコンポーネント設計はAtomic Design + OOUX
というわけでまとめると。
自分の考え方としてはAtomic Designの粒度 に 責務分離 としてOOUX の 概念モデリング をしたものが UIコンポーネント指向 としてまとめるならベストなのではないかなと最近考えています。
みんなコンポーネント設計どうしてるの？
長々と書きなぐってきましたが、そもそもAtomic DesignやOOUXなどこれらのメソッドが有効なのか、それはプロダクトのケースにもよるし組織にもよるし開発メンバーのスキルセットにもよるし… まだまだ手探りですし、これが完全なる最適解というわけではないなと思う次第です。
そんなわけで、みなさんはどうしているのかは最近すごく気になるところです。
Atomic Designを導入しているケースはちょこちょこ見かけますが、OOUXは知名度もあるのか実践している人を見かけないです…。
また、これらの考え方はデザイナーだけではなくフロントエンドエンジニア（Native/Webどちらも）やバックエンドエンジニアなどUI/View層に関わる人たちにも関係のあることだと思いますが、実際問題レイヤードアーキテクチャやクリーンアーキテクチャなどから見てこのUIコンポーネント指向はどうなのか、また今までのUI層との付き合いってどうだったのか…。
などなど、そういうのを話す機会ってないなーと思います。
勉強会やります。
というわけで、こういう設計やデザインメソッドの知見を共有する勉強会が欲しいなと思い 9/7（水） Speeeさんのオフィスをお借りして、有志で主催している Design For User グループの勉強会第二回のテーマとして勉強会を開催することになりました。興味のある方は是非ご来場ください 😁
Design For User #2 - コンポーネント指向から考えるUIと設計 ➡
UIコンポーネント設計（AtomicDesignやOOUX）とそれに関連するフロント・バックエンドのアーキテクチャの話がテーマです。
デザイナー・エンジニアの垣根を越えていろいろ知見を共有します。
