タスク指向を避ける

タスクをベースにUIを構築すると、

• UIの煩雑化
• 無駄な遷移が増える
• 直感的に操作しにくい

といった問題が生じがち。
タスクではなく、ユーザーの関心事（＝オブジェクト）を起点にUIを構築するのがオブジェクト指向UIデザイン。 まずはオブジェクトを提示し、その次にアクションを選ばせる。
UIは、複数のオブジェクトを構造的に表象した合成物。

設計の基本ステップ

オブジェクトの抽出

オブジェクト = そのドメインにおける主要な概念。
それが画面に見えていることで、ユーザーはそのアプリケーションの用途や作業範囲を把握できる。
ユーザーのメンタルモデルや業務に、どのような概念が存在するか調査し、オブジェクト / コレクションとして表現する。

ビューとナビゲーションの検討

オブジェクト選択 → アクション選択という操作構文を、出来るだけアプリケーション全体で踏襲する。
ナビゲーションは、今見ているオブジェクトに付随する / 関連する別なオブジェクトを呼び出すものとして考える。それによりナビゲーション項目は名詞形の表現となり、オブジェクト指向の操作構文に沿ったものになる。

ビュー：情報表示領域。オブジェクトを具象化したもの
ナビゲーション：関連するビュー同士を呼び出すもの。

レイアウトパターンの検討

オブジェクトとビューの定義後、それらを画面上にレイアウトしていく。
同じUIモデルをもとに、画面サイズと相談しつつ最適なレイアウトを探っていくことになる。

タスクをどのように扱うか

問題点

「水を飲む」というような単純な行動でも、タスクの粒度は様々。
しかも、タスクは次々と増えていきやすく、後から変化しやすいものでもある。
したがって、まずタスクを定義し、それを元にUIを構築しようとすると複雑化しやすい。

ではどのように扱う？

オブジェクト指向で構築されたアプリケーションでは、タスクはオブジェクト＋アクションに分解される。
しかし、ページの内容によってはタスクが直接UI上に現れることもある。
例：ヘルプコンテンツ。ユーザーの「〇〇する」というタスクに沿ってコンテンツが構成される。

また、既存のアクションのバリエーションとしてUIに反映されることもある。新たなタスクを検討するときに、そこから抽出したオブジェクトがすでに存在するのであれば、そのアクションのバリエーションとして追加すると良い。

その他だと、フォームの初期値、フィルタリング上などにタスクが反映されることもある。

実装にあたって

個人的には、フロントエンドにとってのモデル = UIをデータ構造として表したものだと思っている。
その観点とオブジェクト指向UIデザインの方法論には親和性を感じる。

デザイン時に抽出したデータ構造（モデル）をTypeScriptで型定義し、それを元にフロントエンドの実装を進める、というフローも可能。

ただし、書籍内では「実際に表示される項目をベースにオブジェクトとして抽出する」となっているが、それをそのまま実装に当てはめることは難しい。
実際の開発では、

• 画面に表示されないが、状態管理上必要なデータ
• 条件分岐のために必要なデータ

といったものも扱わないといけない。

それを差し引いても、オブジェクト指向UIには、デザイナー側とエンジニア側の共通言語としての可能性を感じる。