『オブジェクト指向UIデザイン』をチームで読み合わせ。day.2

UIUXデザイナー必読書の、オブジェクト指向UIデザインを、デザインチームで読み合わせして、個人的な備忘録を兼ねて、noteにまとめます。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 (WEB+DB PRESS plusシリーズ)

第2章：オブジェクト指向UIの設計プロセス

オブジェクト指向UI設計メソッドは、要求から解決へのミッシングリンクを繋ぐ重要なノウハウ。

・実際のUIをどう取り扱うかというセオリーがどこにも説明されていない。

アプリケーションの手がかりとはどこからやってくるのか？
「やること（タスク）」を思い浮かべて発想するとタスク指向に、「対象物（オブジェクト）」を思い浮かべて発想するとオブジェクト指向に。タスク指向にしすぎると、ユーザーが「自分のやりたいことは何か？」を強く意識しないといけなくなる（例：目的ごとに入口の分けた家）。

ユーザー、タスク、オブジェクトの関係
ユーザーの目当て（関心）であるオブジェクトを先に見えていないと、ストレスに感じる。「やること」を実現するためであっても、対象をまずユーザーに見せることがオブジェクト指向。

ソフトウェアデザインについて、OOD※はユーザーのイメージする関心対象への構造的概念＝メンタルモデルを再現する。
※オブジェクト指向設計（OOD）
※メンタルモデル ＝ 「思いこみ」や「価値観」 参考：メンタルモデルとは

ソシオメディア

モデル：オブジェクトモデリングは最も重要。ユーザー調査、タスク分析を十分に行い、ユーザーのメンタルモデルを反映したものにしないといけない（ただ、ユーザーは特殊なユーザーではなく、普遍的なユーザーを広くカバーすべき）。開発者が行うものと同じだが、UIを作るモデリングとは、プログラムの実装や細かいロジックは考えないでいい。「実装方法を考えるよりも先に、あるべきUIがモデリングされているべき」

​一連の業務の仕組みのようなものをイメージ？

インタラクション（機能）、プレゼンテーション（表層）：この2つは互いにデザインしながら「ルック」を作成していく。時にはメンタルモデルに立ち帰えることも。

インタラクション ＝ 作成、閲覧、入力、削除（CRUD※）などの操作。オブジェクトに対して複数のビューとアクションを用意する）
※create、read、updata、delete エンジニアでもよく使う用語。
プレゼンテーション ＝ 表層。

デザインの究極の目的は形
あるべきグラフィックの形を最も優先的に検討すべき。ある種の直感も必要。ロジックは後から見出される※。
※アブダクションライン ＝ twitter：デザイナーの逆推論

道具の抽象性：リンゴの皮むき機。ユーザーに合わせるのではなく、ユーザーが自らを合わせることができるデザインで、ゴールを最大化する。

・​ユーザーに合わせすぎると、使いにくいデザインになる。
・レビュー会​：広く意見を求めることについてどうか？多くの場合デザインプロセスに問題がある。

オブジェクト指向UI 設計の基本ステップ

ステップ1. オブジェクトの抽出（モデルレイヤー）
オブジェクト指向分析のクラス定義、エンティティ定義と同じ作業。UIモデリングではユーザーが意識すべき概念だけ定義する。「数えられる名詞」「同種の集合として管理」「共通のアクション」でオブジェクトと言えるかどうかを判断する。例：メッセージ、メールボックス

ステップ2. ビューとナビゲーションの検討
CRUD（作成、閲覧、入力、削除）とビュー。ビューとは、ユーザーが実際に画面で目にすることができるひとまとまりの情報表示領域で、大きくコレクションとシングルがある。

・ステップ1：インタラクションのためのページマップのような感じ。
・コレクションビューは一覧、シングルビューは個別詳細ページのような。​
・ナビゲーションは画面をつなぐもの。（行ったり来たりできる）​

ステップ3. レイアウトパターンの適用
ペイン※間でのビューの呼び出しに伴うインタラクションは、「左で操作した結果が右に反映される」「上で操作した結果が下に反映される」といった方向性を持ってデザインされるとその振る舞いの意味がユーザーに理解されやすくなります。
※pane: 枠

・ここだけ急に、置いてかれた気分。
・我々はレイアウトのhowto（どのように）の部分もうちょっと深く考えないといけない。

Day3に続きます。

オブジェクト指向UIデザイン：読み合わせ｜maiokamoto｜note