この記事では、コンセプトモデルとは何かについてと、アプリのUIをデザインする前にこのモデルを確立することの価値について解説します。
コンセプトモデルとは
アプリのコンセプトモデルとは、デザイナーがユーザーに対してアプリをこう理解して欲しいと望んでいるモデルのことです。アプリを使い、ほかのユーザーと話し、資料を読むことによって、ユーザーはアプリの使い方を頭の中にモデルとして構築します。望ましいのは、このときユーザーが頭に描いたモデルが、デザイナーの意図に近くなることです。デザイナーが開発プロセスの重要なパートとして、明快なコンセプトモデルをしっかりデザインしていればその可能性は高くなります。
システムでユーザーができることや、彼らが認識すべきコンセプトについて、コンセプトモデルは(キーストロークやマウスアクションや画面のグラフィックスといった個々の機能の単位ではなくタスクの単位で)抽象的に説明します。
コンセプトモデルを注意深く作り上げ、それを基にUIをデザインすることによって、アプリはシンプルでわかりやすくなります。コンセプトモデルを、1)できるだけシンプルにして必要な機能を提供するコンセプトだけにとどめ、2)可能な限りタスクの領域に集中して、アプリが対象としているタスク領域にはないコンセプトは入れない、または最小限にとどめることが必要です。
オブジェクト指向分析
オブジェクト指向分析はコンセプトモデルの重要な要素です。これには「アプリ内のユーザーから見えるオブジェクト型の列挙」「各オブジェクト型の属性」「各オブジェクト型でユーザーができる操作」が含まれます。ユーザーが認識する必要がない演出面、または実装面にまつわるオブジェクトは、コンセプトモデルには不要です。
アプリのコンセプトモデルのオブジェクトは通常、親タイプから子タイプが操作を継承する階層型構造として体系づけられます。アプリによっては、あるオブジェクトがほかのオブジェクトを包含する包含階層の形で体系化されることもあります。この2種類の階層構造をコンセプトモデルに組み込むことで理路整然として明快なインターフェイスのデザインと開発がしやすくなります。
オブジェクトとメソッドの実装におけるもっとも自然な階層が示されるので、この分析は実装のガイドとして役立ちます。また、デザイナーはどの操作が複数オブジェクトで共通しているかを把握して、一般的な操作としてデザインすることができるので、アプリのコマンド構造をシンプルにできます。
ユーザーがコマンドの構造を習得するのも簡単になります。特定のオブジェクトだけで使ういくつもコマンドを覚える必要はなくなり、代わりに多くのオブジェクト型で使ういくつかの一般的なコマンドを覚えるだけでよくなるのです。
オブジェクトAとオブジェクトBの作成と操作をするためのアプリを例に挙げてみましょう。よく考えられたアプリでは、オブジェクトAの作成方法を知っているユーザーがオブジェクトBを作りたいとき、両方の作り方が同じためユーザーはどうすればいいかをすでに理解しています。コピー、移動、削除、編集、印刷などについても同様です。
例:オフィス用カレンダーアプリのオブジェクト指向分析
オフィス用のシンプルなカレンダーアプリを例にとって、オブジェクト指向分析をしてみましょう。オブジェクト、属性、操作、そしてその関係は以下の表1の通りになります。
オブジェクト | 属性 | 操作 |
---|---|---|
カレンダー | 所有者、現在のフォーカス | 調べる、印刷、作成、表示変更、イベント追加、イベント削除 |
イベント | 名前、説明、日付、時刻、期間、場所、繰り返し、タイプ(会議など) | 調べる、印刷、編集(属性) |
To Do項目 | 名前、説明、期限、優先順位、ステータス | 表示、印刷、編集(属性) |
人 | 名前、職業、オフィス、電話番号 | メール送信、詳しく見る |
表1. シンプルなオフィス用カレンダーアプリのオブジェクト指向分析
オブジェクト:カレンダー、イベント、To Do項目、人などのオブジェクトが含まれます。バッファ、ダイアログボックス、データベース、文字列、といったタスクと関係ないオブジェクトは含まれません。
属性:カレンダーには所有者とデフォルトフォーカス(日、週、月)があります。イベントには、名前、説明、日付、時刻、期間、場所などが入ります。To Do項目には、名前、説明、期限、優先順位などが入ります。人には、名前、職業、オフィス、電話番号などが入ります。バイトサイズも確かめられますが、タスクではなく実装に着目した要素なため含まれません。
操作:カレンダーには、調べる、印刷、作成、表示変更、イベント追加、イベント削除といった操作が含まれます。イベントは、調べる、印刷、編集などが入ります。To Do項目はイベントとほぼ同じです。データベースの読み込み、表の行の編集、バッファ出力、モード切替えといった実装関連の操作は含まれません。
シンプルにする
機能性を高めるために、新たなコンセプトを追加する誘惑にかられることがあります。しかし、コンセプトの追加は高くつくと意識してください。
コンセプトを新たに追加した場合、今あるタスク領域を知っているユーザーが理解していないコンセプトを追加するため、その分ユーザーは追加の学習をしなければなりません。また追加されるコンセプトは、アプリのほかのコンセプトと相互に影響し合うため、アプリの複雑さが指数関数的に増加します。
そのため、可能な限り余計なコンセプトの追加は避けるべきです。コンセプトモデルの操作をデザインするための極意は「シンプルなほど良い」です。
コンセプトモデルはアプリとプロジェクトの土台となる
UIデザインではコンセプトモデルで説明される抽象的なコンセプトを、具体的な外観とユーザーの行動として表現します。これがうまくいくためには、コンセプトモデルをデザインしたあとにUIをデザインすることが大事です。その次にUIデザインのレベルで、ユーザーがアプリを使うときのシナリオを書き直します。コンセプトモデルからUIをデザインすると、コンセプトモデルの問題点が明らかになることもありますが、その都度モデル自体を改善すればよいのです。
コンセプトモデルによってUIデザインだけでなく、アプリの実装と文書化をするための土台が作られます。コンセプトモデルはプロダクト全体のデザインと開発において、中心的な役割を果たすのです。
まとめ:コンセプトモデルの6つの利点
コンセプトモデルを用いてデザインを始めることには以下の利点があります。
1. シンプルなUIデザインに繋がる
タスク領域のオブジェクトと操作を設計することで、多くのオブジェクトで共用できる操作をデザイナーが把握できます。そうしてデザインされたUIは、複数オブジェクトで共通して利用できる操作を持つ、ユーザーが習得しやすいシンプルなものになります。
2. コンセプトを理解してUIデザインができる
デザイナーが、「(コンピューターの領域ではなく)タスク領域とコンセプトの関連」「オブジェクトの型階層」「オブジェクトの包含階層」などといったコンセプトの重要性を考えるようになり、UIデザインがしやすくなります。
3. プロジェクト内で使用する用語を統一できる
プロダクト内で使われる、オブジェクトや操作を説明するための用語を定義する出発点になります。これによってアプリの実装時と資料とで一貫した用語を使った説明ができます。
4. ユーザーシナリオが書ける
デザイナーがコンセプトモデルに含まれるコンセプトと用語のみを使って、ユーザーシナリオ(アプリを使ってタスクを遂行するシナリオ)を描くことができます。
たとえば、カレンダーアプリのコンセプトレベルのシナリオは次のようになります。
ジョンがその週のアポイントを確認する。チームのメンバーを招待してチーム会議のスケジュールを決める。歯医者の予約を追加する。
使用例を示すこのようなシナリオは、アプリの機能評価のときにデザインの有効性を確認する助けになります。シナリオをプロダクトの説明書やチュートリアルなどに活用することもできます。また、目標達成のためにUIレベルでどのような操作が必要かを示さなくても、コンセプトレベルのシナリオ使ってタスクと達成目標を説明することができるため、ユーザビリティテストのタスク解説にも使うことができます。
5. すばやく開発に入れる
コンセプトモデルは(ユーザーが最初に認識するであろう)アプリの基本的なオブジェクト構造を明確にするため、開発者が実装を始めるときにも活用できます。
6. 首尾一貫したアプリづくりができる
洗練されたコンセプトモデルは、ユーザーから見えるあらゆる面(機能、用語、UI、資料、サポートなど)に一貫性を持たせることができ、より良い開発プロセスに役立ちます。コンセプトモデルをチームメンバー全員の共同責任のもとに置くことで、首尾一貫したアプリ作りに繋がり、作業のやり直しを減らし、開発リソースを節約することができます。