CQRS を考案した Greg Young 氏の以下のドキュメントを以前読んでいたときに出てきたInductive UIについて気になったので調べてみた
https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
CQRSの文脈的には、
コマンドを構築するにあたってUIは一般的なDTO アップ／ダウンシステムとは少し異なり、「タスクベース・ユーザーインタフェース」（別名：Microsoft の「Inductive UI」）に傾斜する必要がある
とのことで紹介された
Microsoft の「Inductive UI」
Inductiveは「誘導的な、帰納的な」という意味で、Inductive UI（IUI）を直訳すると「誘導的なUI」ということになる
つまり、IUIは機能を説明と理解が容易な画面またはページに分割することにより、ソフトウェアアプリケーションを単純化する方法を提案する新しいユーザーインターフェイスモデルである
これの対照的なUIとして、「演繹的なUI」がとりあげられている
「演繹（えんえき）」とは、すでに知られている法則（一般論・ルール）や前提から、階段を登っていくように論理を積み重ねて結論を出す考え方
Microsoft 社は、IUI の研究にあたり、演繹的なUI の3 つの主な問題点をあげた
①ユーザは製品の十分なメンタルモデルを作らない
- ほとんどのソフトウェア製品のインタフェース設計は、デザイナが慎重に巧みに作れば、ユーザは概念モデルを理解すると決めてかかっている
- 残念なことに、ほとんどのユーザは、インタフェースによるナビゲーションを導くのに十分な完全かつ正確なメンタルモデルを取得していない
- これはユーザの要領が悪いわけではなく、彼らが非常に多忙で情報に惑わされているため、ソフトウェアの概念モデルについて探求する時間、エネルギーや欲求がないから
②多くのユーザは経験が長くても、決して手順をマスターしない
- 新しいユーザは最初にトラブルを抱えるが、学ぶにつれてトラブルが消えていくことをデザイナは知っている
- ただ、ある研究によると、手元の仕事に集中しているユーザは経験のない手順に気づかない（次回にユーザが同じ操作を行う時も、まったく同じ方法でつまずく）ので、一向に手順をマスターしない
③ユーザは機能や画面を理解するのが困難である
- 多くのソフトウェア製品は、その概念モデルを理解していて、一般的な手順をマスターしている（少数の）ユーザ向けに設計されている
- 大多数の顧客にとって、各々の特徴や手順は、苛立たしい不必要なパズルそのもの
- ユーザは、コンピュータを使うからには、このパズルは不可避なコストだと思い込んでいる
- しかし、この重荷がないほうが各自にに幸せである
一方で、タスクベース UI（または誘導的 UI、IUI）の基本的な考え方は
- ユーザがどのようにソフトウェアを使いたいのかを把握すること
- プロセスを通して使用方法を導くこと
の2 つが重要としている
さらにこの基本的な考え方は、IUIを使用するソフトウェアを設計するための一連の4つのステップに拡張できる
- 各画面を1つのタスクに集中させる
- タスクを記述する
- 画面の内容をタスクに合わせて作成する
- 二次タスクへのリンクを提供する
またさらに上記の4つの手順に加えて、次の5つのガイドラインに従うことでインターフェイスを強化できる
- 一貫性のある画面テンプレートを使用する
- タスクを開始するための画面を提供する
- 画面上のコントロールを使用してタスクを実行する方法を明確にする
- タスクを完了して新しいタスクを開始する簡単な方法を提供する
- 次のナビゲーションステップを明確にする
適切に設計された誘導インターフェースは、ユーザーが画面を見ているときに直面する2つの基本的な質問に答えることができるようになる
- 私は今何をすべきか？
- 次のタスクを実行するために、ここからどこに移動するか？
このインタフェーススタイルだと、ユーザの意図に沿ったコマンドを構築するのが簡単になる
例として挙げられているのが、画面タイトル
- 演繹的なUIの画面タイトルが「アカウント管理画面」
- それに対して、IUI では「使いたいアカウントを選択してください」
というような感じ
最近では一般的になっているかなと思うが、自分が設計する際もユーザがソフトウェアをどのように使いたいのかを注意深く観察して設計していきたい
