このトピックでは、誘導ユーザー インターフェイス (IUI) と呼ばれるユーザー インターフェイス モデルについて説明します。 IUI モデルは誘導ナビゲーションとも呼ばれ、説明と理解が容易な画面やページに機能を分割することで、ソフトウェア アプリケーションを簡単にする方法を提案します。 この IUI モデルは、Microsoft Money 2000、Windows コントロール パネル アプレット、Microsoft Visual Studio 2010 のさまざまな画面とダイアログ、Microsoft Office のタスク パネルなど、さまざまな Microsoft プロジェクトではっきり分かります。
- はじめに
- IUI の動作: 一般的な設計上の問題の解決
- 誘導ユーザー インターフェイスの作成手順
- 追加のガイドライン
- User Assistance
- 付録: Microsoft Money 2000 の設計とテスト
はじめに
IUI は、説明と理解が容易な画面やページに機能を分割することで、ソフトウェア アプリケーションを簡単にする方法を提案するユーザー インターフェイスです。 Microsoft では、大規模な商用ソフトウェア アプリケーションである Money 2000 でこのモデルを実装しています。 非公式のテストでは、ユーザーは従来のインターフェイスと同じようにこのモデルでタスクを迅速に実行でき、より簡単に検索できる可能性があることを示唆しています。
多くの商用ソフトウェア アプリケーションには、一連のコントロールが画面に表示されるユーザー インターフェイスが含まれますが、ページの目的の推測とその目的を達成するためのコントロールの使用方法はユーザーに任せています。
このドキュメントで説明する原則では、特定の厳密な設計、コントロール、またはビジュアル要素のセットは必要ありません。また、そういった意味も含まれていません。 一般的なグラフィカル ユーザー インターフェイスと同様に、このドキュメントの原則には、設計における柔軟性と創造性のための余地がたくさんあります。
誘導ユーザー インターフェイスの一般的な原則は、Money 2000 から引き出された例で示されています。
重要
IUI の全体的な概念は、その初期段階にあります。 これらの手法を採用するデザイナーは、ソフトウェアで使用する際に学習し、その詳細を発見します。 このドキュメントの情報は、この分野の研究と知識が増加するにつれて、時間の経過と同時に進化します。 このトピックでは、しっかりした包括的なガイドラインのセットではなく、IUI の概要について説明します。
IUI の動作: 一般的な設計上の問題の解決
このセクションでは、今日のソフトウェア製品の一般的な設計上の問題について説明し、問題を克服するための手法として IUI を紹介します。
問題: ソフトウェアが使いにくい
ほとんどのソフトウェアは使いにくいです。 この結論は、ユーザビリティ テスト、事例証拠、およびソフトウェアデザイナーの個人的な経験から引き出されます。 IUI の概念は、研究を行い、現在のソフトウェアが使いにくしているものは何か、知識に基づいた推測を行い、ソリューションを提案することによって生み出されました。 IUI を使用するデザイナーは、設計の最終的な成功を判断するために、顧客満足度に依存する必要があります。
最新のソフトウェア製品は、次の一般的な理由から使いにくくなっています。
ユーザーは、製品の適切なメンタル モデルを構築していないようです。
最新のソフトウェア製品のインターフェイス設計では、デザイナーが慎重に作成した概念モデルをユーザーが理解することを前提としています。 残念ながら、ほとんどのユーザーは、ナビゲーションを導くために十分に徹底的かつ正確なメンタル モデルを取得していないようです。 これらのユーザーは非常に忙しく、情報過多になっている可能性があります。 ソフトウェアの概念モデルについて学ぶ時間、エネルギー、または欲求がありません。
長年のユーザーでも、多くが一般的な手順を習得することはありません。
デザイナーは、新しいユーザーが最初はつまずく可能性があることを知っていますが、ユーザーが一般的なタスクを学習すると、これらの問題は消えると予想しています。 ユーザビリティ データは、多くの場合でこの問題が発生しないことを示しています。 ある研究では、研究者は自宅でユーザーをビデオに撮る自動装置を設定しました。 そのビデオテープは、手元のタスクにフォーカスするユーザーが、自分が従っている手順に必ずしも気付くわけでもなく、経験から学ぶわけでもないことを示しました。 ユーザーが次に同じ操作を実行すると、まったく同じようにつまずく可能性があります。
ユーザーは、各機能または画面を使えるようになるために努力する必要があります。
ほとんどのソフトウェア製品は、概念モデルを理解し、一般的な手順を習得している (少数の) ユーザー向けに設計されています。 大多数の顧客にとって、各機能や手順はイライラするもので、望ましくないパズルのようなものです。 ユーザーは、これらのパズルは、コンピュータを使用する上で避けられないコストであると想定するかもしれませんが、この負担がなければ間違いなくもっと満足でしょう。
これらの問題に対する最善の解決策は、ソフトウェア製品の機能をより自明かつ一目瞭然にするための一般的な戦略を見つけることです。 ユーザーは、必要があれば機能を検索でき、その機能を使用したい時に使用できるべきです。
誘導ユーザー インターフェイス
現在のソフトウェアのほとんどの要素では、次のスクリーン ショットで示すように、ユーザーはそれらを学習し、動作を推測する必要があります。
ソフトウェアデザイナーを含む、経験豊富なコンピューター ユーザーは、このダイアログで一覧を管理できることをすばやく認識します。 一覧の下にあるボタンが一覧事項に関する情報を追加、削除、および提供できることを知っています。 ただし、ダイアログ自体にこの動作が明示的に記述されていない点に注意してください。
ここで、カジュアル ユーザーの観点からダイアログをもう一度見てみましょう。 多くのユーザーは、このダイアログに直面したときに、「私はこれで何をすれば?」と自問します。ダイアログが表示されたら、ユーザーは停止し、次に何をすべきかを把握する必要があります。 まず、ユーザーは、大きな白い四角形が空のリスト ボックスであり、項目をいれるものだという事実を推測する必要があります。 ボックスの小さなテキスト ラベル「Things」は、曖昧なヒントを提供します。 一部のユーザーは、編集テキスト ボックスのように見えるため、リスト ボックスに入力しようとします。
次に、ユーザーは、リストの下にあるボタンがその内容に影響することを推測する必要があります。 一部のボタンは最初は無効になっています。これはまた、ユーザーの混乱の原因となる可能性があります。 ユーザーは、ダイアログの仕組みを学習するために、コントロールを試す必要があります。
ユーザーは、他の質問をする場合もあります。「リストに入れるべき項目はいくつですか? 特定の順序で項目を入力する必要がありますか? 最初にこのダイアログが表示されたのはなぜですか? 何を目的としていますか?」
ユーザーは、画面の目的とその使用方法を把握する必要があるときは常に、目標から気が外れてしまっています。 これは最終的には、時間がかかりユーザーの満足度にも影響します。 さらに悪いことに、ユーザーは機能を使用するたびにインターフェイスで混乱し、この経験を何度も繰り返します。
画面には、その目的を明確に説明するタイトルが必要です。 デザイナーが画面を作成するときに、明確に表現可能な目的を求めることはほとんどありません。 代わりに、単にユーザーが推測する必要がある大規模な概念モデルの一部である可能性があります。
研究では、多くのユーザーがソフトウェアの基本的な操作でも混乱していることが分かっています。 製品が何を提供できるか、操作を実行する場所、および操作が見つかったらその操作を実行する方法を簡単には理解できません。 基本的な変更を行ってソフトウェアを簡素化することは、既存の顧客を完全に満足させ、新しいユーザーを引き付ける強力な方法です。
ソリューション: 誘導ユーザー インターフェイス
ソフトウェアを設計する新しい方法として、IUIの目標は、ユーザーは製品の一部間を正常に移動し、その機能を使用しなければならないという直接関係のない思考の量を減らすことです。 誘導という言葉は動詞の誘発から来ています。これは、影響や説得力によって導いたり動かしたりすることを意味します。
IUI は、一般的な Web スタイル インターフェイスの拡張機能です。 Web 環境では、各情報を比較的遅い接続でサーバーに送信する必要があるため、ページはシンプルでタスクベースである必要があります。 その後、サーバーは次の手順などで応答します。 優れた Web デザインとは、ページごとに 1 つのタスクにフォーカスし、ページ間のナビゲーションを提供していることです。 同様に、誘導ナビゲーションは、各ページのアクティビティを 1 つの主要なタスクにフォーカスすることから始まります。
適切に設計された誘導インターフェイスは、ユーザーが画面を見るときに直面する 2 つの基本的な疑問を解決するのに役立ちます。
- 今何をする必要がありますか?
- 次のタスクを達成するには、ここからどこに移動すればよいですか?
これらの原則に従って設計されたソフトウェアは、基本的な前提から始めることによりこれらの質問に答えます。1 つの明記された明確な目的を持つ画面は、そのような目的を持たないページよりも理解しやすくなります。 画面がわかりやすくなれば、ユーザーは何をすべきか、次に行く場所が分かりやすくなります。
この基本的な前提は、IUI を使用するソフトウェアを設計するための一連の 4 つの手順に拡張できます。
- 各画面を 1 つのタスクにフォーカスするようにします。
- タスクを述べます。
- 画面の内容をタスクに合わせたものにします。
- セカンダリ タスクへのリンクを提供します。
このドキュメントでは、IUI の一般的な原則について説明しますが、Money 2000 やその他のソフトウェアの例を示すことで、これらの原則が実際に動作していることを示します。 これらの例は、実装のための厳密なモデルではなく、IUI の特定の表現と考える必要があります。
上記の 4 つの手順に加えて、次の 5 つのガイドラインに従ってインターフェイスを強化できます。
- 一貫性のある画面テンプレートを使用します。
- タスクを開始するための画面を提供します。
- 画面上のコントロールを使用してタスクの実行方法を明確にします。
- タスクを完了して新しいタスクを開始する簡単な方法を提供します。
- 次のナビゲーション手順を明確にします。
処理
多くのタスクでは、ユーザーが一連の画面間を移動する必要があります。 タスクを実行しているユーザーは、主要タスクを構成する一連の画面から移動するセカンダリ タスクへのリンクをクリックすることがあります。 ユーザーがセカンダリ タスクを完了すると、元のタスクの分岐ポイントにユーザーを直接返す簡単な方法が必要です。 ユーザーは、[戻る] ボタンや [進む] ボタンなどの従来のナビゲーション コントロールを使用して、開始した場所に戻る際に問題が発生する可能性があります。
この機能を提供するために、IUI は、プロセス、画面、またはタスクを実行する一連の画面と呼ばれるナビゲーションの概念を定義します。 プロセスは、一種のナビゲーション サブルーチンとして機能します。 ユーザーはプロセスを開始して一連の画面に取り組んだ後、最後のページで [完了] ボタンをクリックすると、プロセスを開始したページにすばやく戻ることができます。
誘導ユーザー インターフェイスの作成手順
このセクションでは、IUI の作成に使用できる 4 つの手順の詳細について説明します。
手順 1: 各ページを 1 つのタスクにフォーカスする
IUI を設計する最初の手順は、機能または一連の機能を取得し、別々の画面に分割することです。 各画面は、画面のプライマリ タスクと呼ばれる 1 つのタスクに集中する必要があります。
このアイデアは単純に聞こえますが、それに従うアプリケーションはほとんどありません。 ほとんどのアプリケーションでは、関連するすべての機能が実行される画面が表示されます。 この設計では、ユーザーが出来ることとその方法を把握 (推測) する必要があります。
プライマリ タスクは、特定のタスクでも、オープン エンドでもかまいません。 たとえば、パーソナル ファイナンス プログラムでは、特定のタスクが「支払う請求書を選択する」であるのに対し、未処理のタスクは「投資のパフォーマンスを確認する」の場合があります。
プライマリ タスクは、実装の詳細やその他の抽象的な概念を反映するのではなく、ユーザーに理にかなったものでなければなりません。 このタスクは、ユーザーが行おうと考えるものにする必要があります。できれば、自分の言葉で説明したものが好ましいです。
例
このセクションでは、Money の 2 つの異なるリリースを比較します。 この例では、ユーザーが財務アカウントを表示および管理できるようにするといった非常によく似た機能を示しています。
IUI モデルは、個人の財務を管理するためのアプリケーション Money 2000 の作成時に開発されました。 Money 2000 は、製品の 8 番目のメジャー リリースです。 Money 2000 は、100 万行を超えるコードを含む大規模な Windows プログラムです。
Money 2000 は Web スタイルのアプリケーションです。 Web サイトではありませんが、Web サイトと多くの属性を共有しています。 そのユーザー インターフェイスは、ナビゲーション スタックを前後に移動するためのツールを使用して、共有フレームに表示される全画面表示ページで構成されています。 この基盤上、Money 2000 では、より構造化されたユーザー エクスペリエンスを作成する一連の新しいユーザー インターフェイスの決まり事が追加されます。
IUI は Money 2000 の Web スタイルのデザインで最初に使用されましたが、ウィンドウやダイアログ ボックスなどの従来のインターフェイス要素でも使用できます。
Money 99 では、ユーザーは多くの場合、1 つの画面でさまざまなタスクを実行しました。 たとえば、次のスクリーン ショットは、1 つの画面で Money 99 のすべてのアカウント関連機能を表示したアカウント マネージャーを示しています。
この画面では、アカウントに移動する一般的なタスクと、アカウントの作成や削除などの頻度の低いタスクをグループ化します。 これらの特定のタスクはいずれも、画面のタイトルであるアカウント マネージャーには直接表現されていません。 多くのユーザーは、この画面を図 1 のサンプル ダイアログと同じくらい難しいと思うかもしれません。 どちらの場合も、ユーザーは画面の目的と使用方法を推測する必要があります。
IUI に続く Money 2000 は、アカウント関連の機能のほぼ同じセットを提供しますが、2 つの異なる画面でそれらは提供されます。 次のスクリーン ショットは、これらの画面の最初の画面を示しています。これは、ユーザーがアカウントの選択に重点を置いて行われます。
Money 2000 画面には、以前の Money 99 画面とほぼ同じ数のビジュアル要素が含まれていますが、ページはユーザーがアカウントを選択できることに完全に焦点を当てています。 たとえば、Money 99 バージョンでは、ユーザーがアカウントを開くには 2 回クリックする必要がありました。1 つはアカウントを選択し、もう 1 つは開く操作を選択する必要がありました。 Money 2000 バージョンでは、ユーザーがアカウントをクリックする唯一の理由はアカウントを開く際の 1 回のクリックで十分です。 この方法では、画面の数が増える場合でも、一般的なタスクを実行する上で必要なクリックの数が減ることがよくあります。
場合によっては、ユーザーはアカウントを追加または削除する必要があります。 Money 2000 でこのタスクを実行するには、アカウントの設定に重点を置いた 2 番目の画面 (次のスクリーン ショットに表示) に移動します。
各画面の目的は、Money 2000 の IUI バージョンでより明確になります。 さらに、各画面には、その目的を果たすのに専念するためのより多くのスペースがあります。 たとえば、Money 99 のアカウント マネージャーは、画面の他のコマンドと比較してほとんど使用されないため、[アカウントの削除] ボタンにはほとんどスペースを与えませんでした。 これに対し、Money 2000 のアカウント設定画面では、このコマンドがより目立つように表示させることで、検出しやすく、分かりやすくなっています。
シングル タスクとは
画面が 1 つのタスクのみに本当に焦点を当てているかどうかを確認するにはどうすればよいですか? 多くのタスクをサポートする画面は、その目的が十分に抽象的であれば、1 つの目的しか持たないという説明される場合があります。 デザイナーがその目的を簡潔で意味のある自然な聞こえの画面タイトルで表現できる場合、画面は 1 つの目的に焦点を当てていることになります。
Money 2000 のデザイナーは、これらの画面をさらに多くの画面に分割することを検討しました ([使用するアカウントを選択する] と [Money でアカウントを設定する])。 しかし、各画面には既に簡潔で意味のある自然な聞こえのタイトルがあるため、デザイナーは画面に十分な焦点を当てたと考えました。 画面を設計するときに、明確でシンプルなタイトルが考えられない場合は、画面上で多くのことを達成しようとしている可能性があります。
手順 2: タスクを述べる
各画面には、プライマリ タスクの簡潔で明示的なステートメントがタイトル付けされている必要があります。 これは、直接の指示 ("バランスを取るアカウントを選択してください" や、ユーザーに回答を求める質問 ("どのアカウントのバランスを取りますか?") を指定できます。
これは、多くの場合、実践されていないもう 1 つのシンプルに聞こえる原則です。 たとえば、以前のリリースの Money には、Online Financial Services Manager や Balance Account などのタイトルを含む画面がありました。 ユーザーは、コントロールの配置とラベルからこれらの画面の目的と動作を推測する必要がありました。
画面またはページのタイトルは非常に重要です。 製品がウィンドウ、Web スタイルのページ、ダイアログ、または別のデザインを使用しているかどうかに関係なく、タイトルをスクロールしないようにする必要があります。
使用可能な画面には明確なタイトルがある
多くのタスクを実行する画面には、抽象的または複雑なタイトルが必要です。 たとえば、図 2 に示す Money 99 画面では、ユーザーはアカウントに移動し、アカウントを設定できます。 抽象的なタイトル "アカウント マネージャー" は、これらの両方の目的をキャプチャしようと、このページに付けられました。 ユーザーは、"アカウント マネージャー" ページの動作についていくつかの考えを持つかもしれませんが、この画面の最も一般的なタスクは単にアカウントを選択しただけでは十分に認識できない場合があります。
一部の画面またはコマンドには、明確なタイトルを容易に提案しない抽象的な目的があります。 これらの画面では、デザイナーは、"QuickStep;" などの "設定;" の造語された流行語や、実装の詳細を明らかにする専門用語 ("Database Compaction") など、意図的にあいまいな名前を選択できます。 このような名前は、多くの場合、ユーザーに混乱を招いたり、誤解を招いたりします。 さらに、通常、このような名前は、ユーザーが実行したいアクションを表さない名詞のため、混乱を招きます。
多くの場合、画面タイトルとその他の名前は、設計プロセスの終わり近くまで決定されません。 デザイナーは、多くの場合、設計とコード化が完了した後、画面に適した名前を書き込むようライターに依頼します。 その時点で、適切な名前が見つからない場合はリソースがないため、チームは明確でない名前で解決しなければならない場合があります。 この欠陥の解決策は、デザイナーが設計プロセスの早い段階で画面の機能と名前の分かりやすさを検討することです。
画面の機能と名前は、顧客が実行する最も一般的なタスクに焦点を当てる必要があります。 デザイナーは、多くの場合、設計チーム自体の要望と共に、最も多くの顧客を満足させるために膨大な量の機能を提供したいと考えています。 ただし、追加の機能では、常に複雑さと他の手間が追加されます。
画面タイトルが設計の明瞭さを測る
IUI モデルでは、デザイナーは設計プロセスの最も早い段階で画面タイトルを選択します。 タイトルを選択して画面の動作を正当化する代わりに、タイトルを使用して画面が理にかなっているかどうかを判断します。 適切なタイトルが見つからない場合は、機能が再設計されます。 設計で明確で簡潔なタイトルが許可されていない場合 (つまり、機能を説明する方法がない場合)、デザイナーは機能を破棄する可能性があります。 次のスクリーン ショットでは、ページの静的なラベル ("Upcoming Bills & Deposits") を提供する左側の Money 99 請求書支払い画面と、明示的なタイトル ("Click the bill you'd like to pay") が表示されている右側の対応 Money 2000 画面を比較します。
画面のタイトルは、もちろん単なるフレーズや文に過ぎなく、設計やコードよりも簡単に変更できます。 この事実にもかかわらず、IUI の経験は、明確な画面のタイトルを早期に主張することはより良い設計を生み出すことを示しています。 タイトルは、ユーザー教育とユーザビリティのチーム メンバー、製品デザイナーからの入力で選択する必要があります。
チーム メンバーは、ユーザーが画面の目的の理解を共有することを前提として、この決定を延期しようとする場合があります。 しかし、この目的の明確で簡潔な声明を提供することを余儀なくされた場合、意見の相違がしばしば明らかになります。 これらの違いを解決し、タイトルを早期に選択することで、設計のディスカッションをよりスムーズに進めることができます。
タイトルを選択した後は、変更不可と見なす必要はありません。 デザイナーは、他の設計と同様に、時間の経過と共に画面タイトルを調整する可能性があります。 ただし、最初に選択されたタイトルは、開発のその段階で可能な限り強力である必要があります。
画面タイトルを選択するためのガイドライン
このセクションでは、適切な画面タイトルを選択するための簡単な手法について説明します。 この手法を使用するために、デザイナーは友人が「この画面は何ですか?」と尋ね、「これはどこの画面ですか?」という文を完成させる明確で役立つ応答を思い付きます。文を完成する単語が画面のタイトルになります。
Money 2000 の開発中、チームのドキュメント ライターは、品質と一貫性を確保するための画面タイトル ガイドラインを作成しました。 たとえば、これらのガイドラインでは、動詞を使用し、質問や直接の指示として表現されたタイトルが提案されています。 デザイナーは、抽象化を増やし、あいまいになる可能性がある静的な名前を避けました。
タイトルを簡略化するために、デザイナーは複合文を回避し、会話言語を使用しようと試み、厄介な用語や専門用語を避けました。 デザイナーが組み合わせ (「そして」や「また」) に頼らずにタスクを記述できない場合、画面は複数のタスクを実行しようとしている可能性が高く、ユーザーがすべきことをすぐに理解できる可能性が低くなります。
タイトルを慎重に選択した場合でも、タイトルの領域が小さすぎて複雑なタスクを適切に説明できない場合があります。 この問題を軽減するために、画面のコンテンツ領域の上部に、タスクを詳しく説明する簡単な段落を含めることができます。
次の表に、Money 99 の画面タイトルと、Money 2000 の同じ画面または関連する画面のタイトルの例をいくつか示します。
| Money 99 の画面タイトル | Money 2000 の新しい画面タイトル | コメント |
|---|---|---|
| [アカウント マネージャー] |
アカウントを選ぶアカウントをセットアップする |
静的なタイトルがアクティブなタイトルに変更されました。 |
| アカウントの詳細 | アカウントの設定を変更する | 静的タイトルがアクティブな特定のタイトルに変更されました。 |
| 支払カレンダー | 請求書の支払い | あいまいなタイトルを分かりやすくしました。 |
| オンライン ファイナンシャル サービス マネージャー | 再設計後にページは必要ありません。 |
画面のタイトルを目立たせる
便利な画面タイトルに落ち着いたら、ユーザーの注意を引くようになっているか確認することが重要です。 一部の研究では、ユーザーが説明文を読むことはめったにありません。 この問題を解決するには、ユーザーの注意を引くために、画面タイトルが目立つように設計し、魅力的にする必要があります。 画面のビジュアル デザインは、タイトルが最も読むべき重要なことだということをユーザーに通知する必要があります。
手順 3: ページの内容をタスクに合わせる
IUI のガイドラインに従ってソフトウェアを作成する場合、最も難しい設計作業では、通常、機能を画面またはページに分割することが含まれます。 次の手順では、各画面でプライマリ タスクを実行するために使用されるコントロールを決定します。 これらのコントロールは、ユーザーが作業を行うページの内容を構成します。 画面のタイトルと内容は、プログラムとユーザー間のダイアログの 2 等分です。 タイトルはプログラムの質問をしたり、指示を与えたりして、ユーザーが画面のインターフェイスを通じて応答します。
画面のタイトルが明確でシンプルな場合、通常、画面の設計は簡単です。 たとえば、前に示した Money 2000 画面の 1 つは「使用するアカウントの選択」というタイトルです。このタイトルを考えると、画面には明らかにユーザーが選択できるアカウントの単純なリストが含まれているはずだと分かります。 別の Money 2000 画面には、「税金に含める項目を確認する」というタイトルがあります。当然ながら、この画面には項目のチェックリストが含まれています。
ユーザーは、コントロールを使用して画面のプライマリ タスクを実行する方法を簡単に把握できる必要があります。 ユーザーがアカウントを選択するように言われ、画面を見てアカウントの一覧を見つけることができると、タスクの解釈を確認します。 これにより、ユーザーが成功する可能性が高くなり、他のタスクの実行に対する信頼度も高くなります。
画面コンテンツ領域
画面コンテンツ領域の正確な場所と形状は、ソフトウェアの設計によって異なります。 Money 2000 では、画面コンテンツ領域は、画面タイトルの下とタスク一覧の右側にあるすべての領域です。 この領域は、長い画面でスクロールする場合があります。 一部の重要でないコンテンツは、タスク 一覧の下のステータス領域にも表示される場合があります。
デザイナーは、コンテンツ領域の上部にある段落の画面のプライマリ タスクを詳しく説明することを選択する場合があります。 ユーザーはこのテキストを読む必要はありませんが、役に立つ場合があります。 多くのユーザーは省略しますが、画面は正常に使用できます。 タイトルとは異なり、画面がスクロール可能な場合、この説明はスクロールできます。 詳細については、「画面タイトルを選択するためのガイドライン」を参照してください。
デザイナーが重要でないアラーム、アラート、またはその他のステータス情報をページに表示する場合は、画面の左側のタスク リストの下にあるメイン コンテンツ領域の左側に表示できます。 機能的には、このステータス領域は画面コンテンツの追加領域です。 この領域は、重要なコントロールを含ませる程には目立っていません。
明確なページの終了を指定する
タスクが正常に完了すると、ユーザーは別の問題に直面します。それは、画面を離れるタイミングと方法です。 プライマリ タスクがナビゲーションである画面の場合、タスク自体を実行すると、ユーザーは次の画面に移動します。 他の画面では、続行方法がユーザーに伝わりにくい場合があります。 たとえば、ユーザーにフィールドに情報を入力するよう求める画面では、ユーザーがいつ、どのように進めるかを把握するためにヘルプが必要になる場合があります。 このようなページでは、一貫した場所に明確な [次へ] または [完了] ボタンを表示すると便利です。
ユーザビリティの調査では、ツール バーの [戻る] や [ホーム] ボタンなどのグローバル ナビゲーション ボタンが使用可能な場合でも、このようなボタンを使用することを好むことが分かっています。 ユーザーは、情報を読むことだが目的の画面であっても、明確な終了指示のない画面では不快に感じることがよくあります。
このテーマの詳細については、「追加のガイドライン」セクションの「タスクを完了して新しいタスクを開始する簡単な方法を提供する」を参照してください。
手順 4: セカンダリ タスクへのリンクを提供する
画面を設計する最後の手順は、プライマリ タスクを直接実行せず、画面に関連する機能であるセカンダリ タスクへのリンクを用意することです。 たとえば、画面上のプライマリ タスクが手紙を書く場合、その画面のセカンダリ タスクは、郵送先住所を検索したり、封筒を印刷したりすることである場合があります。
セカンダリ タスクは、ダイアログ ボックスを表示したり、画面の内容の視覚的な表示を変更したり、ユーザーを別の画面に移動したりする場合があります。 セカンダリ タスクは、プライマリ タスクを間接的に実行したり、失われたユーザーを検索先の場所にリダイレクトしたりする場合があります。
ページがコンピューターとユーザーの間の会話である場合、セカンダリ タスクを使用すると、ユーザーはコンピューターの現在の質問を無視し、代わりに他の操作を実行するようにコンピューターに依頼できます。 たとえば、次のダイアログを考えてみましょう。コンピューター:「どの請求書を支払うのですか?」ユーザー:「実は、私が本当にやりたいことは、しばらく前に支払った請求書を見つけることです。
製品の一部の画面にはセカンダリ タスクがありません。他の画面には複数のタスクがあります。 ユーザーがスキャンするのが難しくなるかもしれないタスクの長いリストは作成しないようにする必要があります。 画面に比較的長いセカンダリ タスクの一覧がある場合は、最も一般的なタスクを最初に配置するか、別のセクションにグループ化するか、視覚的に強調する必要があります。
この一覧には、次のナビゲーション手順が明確なら、考えられるすべてのセカンダリ タスクを含めるべきではありません。 多くのセカンダリ タスクを提供する代わりに、画面には、他のタスクを一覧表示する補助ページに移動するセカンダリ タスクを提供できます。
セカンダリ タスクの視覚的な設計
セカンダリ タスクは、画面上の下の位置に一覧表示する必要があります。必要に応じてアクセスできますが、プライマリ タスクからユーザーの注意がそれることのないようにします。 各画面でこのリストを一貫した位置に配置すると、ユーザーは必要なときに一覧をすばやく見つけることができます。
画面の左側にセカンダリ タスクの一覧を表示する場合は、Money 2000 の請求書支払い画面の次のスクリーン ショットに示すように、一覧自体をスクロールしたり、ページと共にスクロールできるようにしないでください。
追加のガイドライン
このセクションでは、前のセクションで説明した 4 つの手順に従って IUI を作成するための 5 つの便利なガイドラインについて説明します。
一貫性のある画面テンプレートを使用する
IUI モデルに従うソフトウェアを設計する場合は、すべての画面でガイドとして使用するテンプレートを作成する必要があります。 誘導モデルでは、特定のテンプレートの使用についての規定はありません。 誘導設計に合うような多くの可能性のあるバリエーションがあります。 製品の画面全体に必要なテンプレートが 1 つだけである場合や、さまざまな目的で複数の異なるテンプレートを作成する場合があります。
優れたテンプレートを使用すると、新しいユーザーは製品の画面の仕組みをすばやく理解できます。 製品の画面でテンプレートを一貫して使用すると、画面間の良好なユーザー インターフェイス フローが提供されます。 ユーザーは、同じ要素が同じ場所に表示されることが通常だと学習すると、新しい各画面をより迅速にスキャンして使用し始めることができます。
タスクを開始するための画面を提供する
IUI で設計された製品では、多くの場合、一連のタスクでユーザーの開始用に設計された特別な画面が使用されます。 これらの画面は、一般的なタスクの関連グループを整理するため、アクティビティ ページと呼ばれます。 アクティビティ ページは、ユーザーの開始点を提供します。 通常、アクティビティ ページには、ユーザーが実際に作業を行う他のページへのリンクが表示されます。 アクティビティ ページでは、ユーザーに「今何をしますか?」と尋ね、考えられる回答の一覧を表示します。 アクティビティ ページは、ユーザーが認識できるように特別なテンプレートに従う場合があります。
アクティビティ ページは、製品の適切な既定のスタート ページになります。 ユーザーがアプリケーションを起動する時、一般的には、達成したいタスクが念頭にあります。 通常、製品を起動する理由は、ごく一般的な少数のタスクの 1 つです。 製品既定のスタート ページでは、一般的なタスクを開始する方法を明確にすることで、これを認識します。
Money 2000 のホーム ページは、アクティビティ ページの例です。 既定では、ユーザーにはこの画面が表示されます。この画面では、アプリケーションの起動時に、請求書の支払いや口座の残高調整などの一般的な財務タスクへのアクセスが表示されます。
次のスクリーン ショットは、Money 2000 のホーム ページです。
Money には多くの財務機能が用意されているため、最も一般的な財務タスクのみがホーム ページに表示されます。 その他のタスクはどれも、ホーム ページは、財務センターと呼ばれるアクティビティ ページの補助セットにリンクします。 Money の各主要領域には、ファイナンシャル センターがあります。 これらの画面では、次のレベルのタスクが表示され、各エリア内のすべての機能の出発点として機能します。
たとえば、[Money Taxes] の領域には、製品の税金関連の機能が含まれています。 [税金] 領域には、次のスクリーン ショットに 示すように、税務センター ページでこれらの機能へのリンクが表示されます。
使用できるオプションが少なければ、アクティビティ ページの方がはるかに簡単になる場合もあります。 次のスクリーン ショットは、アクティビティ ページを使用して Windows ユーザー アカウントを管理する方法を示しています。
画面上のコントロールでタスクの実行方法を明確にする
このガイドラインに従う最善の方法は、適切な画面タイトルを選択し、プライマリ タスクのスコープを最も一般的なもののみに制限することです。 ページの明確なタイトルと目的に到達すると、適切なコントロールセットを簡単に選択できます。
タスクを完了して新しいタスクを開始する簡単な方法を提供する
ユーザーが画面上で直面する最後の障害は、いつどのように終了するかです。 ユーザーは通常、リンクをクリックするか、別の画面に移動するコマンドを実行して画面を離れます。 これらのリンクは、画面コンテンツ領域、タスク一覧、またはナビゲーション ツールバーに表示できます。 ユーザーは、現在のファイルまたはアプリケーション自体を閉じて画面を離れることもできます。
一部の画面のタスクは、ユーザーが確認または取り消す必要がある操作を準備することです。 通常、このような画面には、操作を実行してコミットする 1 つのリンクと、キャンセルする別のリンクが用意されています。 ユーザーがこれらのオプションを無視して別のリンクをクリックした場合、プログラムは破壊的でないオプションを実行する必要があります。 画面は、ユーザーがこのパスを選択すると何が起こるかを示す必要があります。 リンクをフレーズして、これをより明確にすることができます。 たとえば、[変更の保存] というラベルの付いたコミット ボタンは、画面に加えられた変更は、そのボタンがクリックされるまで有効にならないことを意味します。
ユーザーが好きなときにいつでも離れることができる場合でも、ページからの分かりやすい終了を提案するリンクを提供できます。 静的な情報を表示するページについても同様です。 このトピックの詳細については、「ページから離れる明確な方法を提供する」セクションを参照してください。
プロセスの開始と完了
この記事の目的上、プロセスは、ユーザーを複数の画面に連れて行くタスクを処理するための手法です。
ユーザーが画面のコンテンツまたはタスク リスト内のリンクをクリックし、別の画面に移動したとします。 そのページは、全体的な結果を達成する一連の画面の最初のページになる可能性があります。 この一連の画面の最後に、ユーザーはプロセスの前の画面に戻りたいと考えています。 ユーザーが戻ることができる方法は少なくとも 2 つあります。 [戻る] ボタンを繰り返しクリックするか、ホーム ページに戻ってそこから移動します。 しかし、これらの方法はどちらも明白でもなければ自然でもありません。 ほとんどのユーザーは、元の画面に直接戻すボタンを最終的な画面にあると予測しています。
IUI モデルは、ナビゲーション ユニットとして扱われるプロセス、画面、または一連の画面の概念を通じて、このシナリオをサポートします。 ユーザーはプロセスを入力し、画面を操作し、最後の画面で、開始した場所に戻るボタンを見つけることができます。 重要なのは、ユーザーは製品内の複数の場所からプロセスを起動できることです。 ユーザーは、プロセスを開始した場所に関係なく、常に開始した場所に戻ります。
プロセス名
各プロセスに名前を付け、プロセスの各画面のどこかに名前を表示される必要があります。 Money 2000 では、このアプローチが使用されています。 プロセス全体の一部である各画面には、そのプロセスの名前が上部に表示されます。 このプロセス名は、重要ではないため、画面の一意のタイトルよりも目立たなくなります。 プロセス名は、実行しているプロセスをユーザーに通知し、プロセス内のすべての画面が 1 つの機能の一部であるという概念を補強します。 たとえば、[Money Taxes] 領域には、複数の画面にまたがって税金の見積もりプロセスが含まれています。 このプロセスの各画面には、一括プロセス名とその一意の画面タイトルの両方が表示されます。
プロセスの実装
同じプロセスをさまざまな画面のさまざまなリンクから起動でき、ユーザーは常に正しい開始ページに戻ります。 リンクの宛先は異なるため、プロセスの最終画面でハード コーディングされたリンクを使用してこの動作を実現することはできません。 代わりに、アプリケーションは、Back コマンドと Forward コマンドで使用される通常のナビゲーション スタックとは関係なく、アクティブなプロセスのスタックを管理することで、この動作を実装できます。 ユーザーがプロセスを起動すると、起動画面がプロセス スタックにプッシュされます。 ユーザーがプロセスの最後の画面で [完了] ボタンをクリックすると、アプリケーションはスタックから最新の起動画面をポップし、その画面にユーザーを返します。
ユーザーがプロセス内の画面から離れると、プロセスはプロセス スタック上でアクティブのままになります。 ユーザーは、画面にバックアップするプロセスを完了してから続行できます。 これにより、ユーザーは迂回したり、バックアップしてから、プロセスを進めることができます。 この動作の仕組みを確認するには、World Wide Web でオンライン ショッピング プロセスを開始し、サイトを離れて、[戻る] ボタンを押します。 通常は、中断したところから再開できます。
完了ボタン
画面を完了し、プロセスの次の画面に進むには、ページの下部付近にボタンを表示できます。 このボタンのラベルは、「次へ」、「完了」、または同様のものです。 ボタンがプロセスを終了し、複数の場所からプロセスを呼び出すことができる場合は、[完了] ボタンのキャプションに呼び出し元の場所の名前を含めることができます。
ナビゲーション バー
どの画面でも、ユーザーは製品の現在の領域を終了したと判断し、他の作業を開始したいと考える可能性があります。 製品の別の部分に進む前に、現在の画面を明示的に完了したくない場合があります。 ナビゲーション ツール バーでは、新しいタスクを開始するための一連のリンクをユーザーに提供できます。 タスク リンクの他の一覧と同様に、これらは次のナビゲーション手順を明確にする原則に従う必要があります。詳細については、次のセクションで説明します。
次のナビゲーション手順を明確にする
すべての機能を同時に使用できるプログラムはほとんどありません。 ユーザーは通常、特定の機能を見つけるためにプログラム内を移動する必要があります。 ユーザーは、目的の結果に少なくとも 1 歩近づく方法を簡単に確認できれば、ナビゲーションで成功します。 IUI を使用する画面は、この原則を念頭に置いて設計されています。
たとえば、アクティビティ ページには、ユーザーがその時点から達成する可能性があるすべての考えられるタスクや目的地が必ずしも表示されるとは限りません。 代わりに、アクティビティ ページには、ユーザーがクリックする適切なリンクを簡単に判断できるように、完成度の高いタスクの一覧が用意されています。これは、別のリンク ページにのみ移動する場合でも可能です。 最も頻繁なタスクは一番目立つ必要があり、ナビゲーションの量が最小限である必要があります。 頻度の低いタスクでは、より多くの手順が必要な場合があります。
以下は Money 2000 での例です。 ユーザーが、来年の売上税支払額の見積額を確認するなど、たまにしか行わない操作を実行するとします。 ユーザーはまず、Money 2000 ホーム ページでこの機能の検索を開始します。 この機能は一般的なタスクの一覧には表示されないため、財務分野の一覧をスキャンする必要があります。 税金の分野は、それらしい響きなので、クリックします。 [税金センター] ページには、探している税金の見積もり機能へのリンクが含まれているため、クリックしてタスクを完了します。 IUI の原則を適用することで、Money 2000 でユーザーは探しているものを直感的に見つけることができます。
User Assistance
このセクションでは、IUI を使用する製品にユーザー アシスタンス テキストを統合するための一連の推奨ガイドラインについて説明します。
プライマリ アシスタンスは、(次のスクリーン ショットに示すように) 画面に表示されるすべてのテキストを参照します。 プライマリ アシスタンスは、ユーザーが画面に表示されるすべての情報を簡単に理解できるように、タスクに重点を置いたテキストの手がかりを提供します。 ページの目的と、タスクの実行に役立つオブジェクトの相互関係を理解します。 テキストは画面に直接表示されるため、「何をすべきか」などの初心者の質問に回答する情報は簡単にアクセスでき、ユーザーが何も操作しなくても見つけやすいように表示されます。
セカンダリ アシスタンスは、画面に表示されないすべてのテキストで構成され、ユーザー インターフェイス要素をクリックまたはホバーするなど、ユーザー操作でアクセスする必要があります。 このコンテンツは、手元のタスクを実行するのに不可欠ではありませんが、まだ直接関連しています。
プライマリ アシスタンス
プライマリ アシスタンスには、次のコンポーネントの一部またはすべてを含めることができます。
画面タイトル
例: 画像を変更する
画面タイトルは、画面に表示される最初の最も重要な項目です。 その目的は、このページで完了できるタスクをユーザー自身の言語で記述することです。 画面タイトルでは、タスクを完了する方法の詳細を説明しないようにする必要があります。 画面タイトルのテキストは、画面のコア タスクのみを指す必要があります。 経験則として、タスクの説明が単純で短いほど、タスクがより適切に定義される可能性があります。 このトピックの詳細については、手順 2:「タスクを指定する」を参照してください。
画面のサブタイトル
例: インターネットから新しい画像をダウンロードすることもできます。
細心の注意を払っても、画面タイトルでは複雑なタスクを十分に説明できない場合があります。 サブタイトルを使用すると、画面の目的を詳しく説明できます。 サブタイトルを使用すると、ページの目的を明確にしたり、追加のタスクの説明を提供したり、期待値を設定したりできます。 サブタイトルを読まないユーザーでも、ページを正常に使用できる必要があります。 タイトルと同様に、サブタイトルでは、タスクを完了するための詳細を記述しないようにする必要があります。
タスク
例: スクリーン セーバーを変更する
タスクは、ユーザーの操作を必要とするテキスト リンクまたはグラフィカル イメージとして表示できます。 テキスト リンクとして表示されるコマンドは、動詞ベースで、明確で簡潔なタスクとして記述する必要があります。
コマンド ボタンのラベル
例: パスワードの作成
コマンド ボタンには、次の 3 種類があります。
- Cancel
- 完了
- Commit
[キャンセル] ボタンと [完了] ボタンでは、ラベルとして「キャンセル」と「完了」を使用するだけです。 コミット ボタンでは、「OK」ではなくアクティブなテキスト ラベルを使用する必要があります。たとえば、「OK」ではなく「パスワードの作成」を使用します。
他のコントロールのラベル
例: パスワードを入力する
ラジオ ボタン、チェック ボックス、テキスト ボックスなどのコントロールのラベルは、ユーザーがコントロールの目的、使用するコントロール、タスクを実行するために提供する必要がある情報を正確に把握できるように、明確かつ簡潔に記述する必要があります。
「関連タスク」リンク
例: 関連タスク - 別のアカウントを変更する
「関連タスク」リンクは、現在の機能に関連する他のタスクへの明示的なエントリ ポイントです。 タスク ベースのリンクとして記述する必要があります。
「関連項目」リンク
例: 関連項目 - テーマを変更する
「関連項目」リンクはセカンダリ タスクです。 これらはプライマリ タスクに関連していますが、ユーザーを現在のコンテキストから除外します。 これらは通常のタスク リンクとして表示されます。 セカンダリ タスクの詳細については、「セカンダリ タスクのビジュアル設計」を参照してください。
セカンダリ アシスタンス
セカンダリ アシスタンスには、次のコンポーネントの一部またはすべてを含めることができます。
ヒント
ヒントを使用すると、タスク リンクまたはコマンド ボタンに関する追加情報をユーザーに提供できます。 たとえば、タスク リンクのヒントには、「アカウントで使用する画像を選択できるページが表示する」と表示される場合があります。ヒントは、ユーザーが関連付けられているオブジェクトの上にマウス ポインターを置くと表示されます。 ユーザーがクリックできるすべてのユーザー インターフェイス要素のヒントを作成する必要があります。
「詳細情報」のヘルプ トピック
例: 詳細情報 - ファイルのダウンロード
「詳細情報」リンクをクリックすると、機能の概要、概念情報、サポート情報、手続き情報などのヘルプ トピックが開きます。 煩雑さを減らすには、画面上の 「詳細情報」ヘルプ トピックの数を最小限に抑える必要があります。
付録: Microsoft Money 2000 の設計とテスト
このセクションは、デザイナー自身の最初の説明から採用されました。 Money 2000 チームが IUI モデルに対応するように設計とテストのプロセスをどのように変更したかについて説明します。
Money 2000 の設計とテスト
誘導ナビゲーション モデルを使用して Money 2000 を設計することで、チームは長い間製品に含まれている設計に疑問を持つようになります。 モデルの原則は単純であるため、設計プロセスでモデルを採用し、そのままにしておくのは簡単でした。 最終的に、デザイナーは、モデルがそれなしで作り出した設計よりも優れたものを作るのに役立ったと信じています。
より明確なタイトルと設計
Money 2000 のデザイナーは、実際には画面に表示されない単語を使用して特徴を記述することがよくあります。 IUI モデルでは、画面自体を説明する必要があります。 たとえば、チームは、支払いカレンダーというラベルの付いた画面が請求書の支払いを目的としていると説明しました。 Money 2000 では、その画面は支払い請求書と呼ばれます。 その目的に関連しないすべての要素は、補助画面に移動され、より明確な設計になります。
もう 1 つの例として、Online Financial Services Manager という画面があります。 チームは、この画面の目的の簡単な説明を作るのに苦労しました。 結局うまく説明できなかった時、この画面を削除し、より論理的に定義されたページ間でその機能を配布しました。
新しいデザイナーを支援する
チームは、経験の浅い新しいソフトウェア デザイナーに IUI 設計手法を教えるのは簡単なことがわかりました。 この手法により、すべての経験レベルのデザイナーは、画面タイトルを明確にするためのテストとしてデザインを評価することができました。 デザインが不十分な画面に明確で簡潔なタイトルを強制的に配置すると、デザイナーはページに十分なタイトルがないことをすぐに認識しました。 彼らは、問題はタイトル言葉選びではなく、欠陥のある画面デザインにあることに気付きました。 この解釈により、画面を再設計して、より明確なユーザー操作と、より明確なタイトルをサポートできました。
ライターを含める
設計が進むにつれて、チームはドキュメント作成者と編集者が画面タイトルの作成に関与する必要があることを認識しました。 ライターは、以前のリリースで優れたタイトルを選ぶ上で能力に限界がありました。これは、遅い段階でしか関与していなかったためです。 通常、画面にはデザイナーまたはプログラマによって一時的な作業タイトルが与えられていました。 これらのタイトルは、ライターが最終的な画面タイトルを付けるように言われる製品サイクルの後半まで使用されていました。 その時点で、不適切に設計された画面を作り直すには遅すぎました。
これに対し、Money 2000 チームには、設計プロセスの初期段階でライターが関与しました。 これにより、設計の役立つ可能性がある時に、画面タイトルの貴重な入力につながりました。 画面が複雑すぎて明確なタイトルを許可できない場合、ライターはページの再設計を提案できます。
プロジェクトが終わる頃には、ライターとデザイナーは、画面タイトルが以前のバージョンよりも明確で強力であると信じていました。 ライターは、新しいページを簡単に説明し、製品を文書化する作業をより簡単にすることを発見しました。 すべてのチーム メンバーは、設計フェーズですべての規範を含め、製品をより良く、使いやすくしたと考えました。
ユーザビリティ テスト
Money 2000 の開発中、チームは、Money 99 の古いナビゲーション構造と IUI モデルの適用の結果として行われた変更の違いを確認するために、いくつかのユーザビリティ テストを実施しました。
プロトタイプのテスト
製品開発プロセスの早い段階で、デザイナーは、ユーザーが IUI にどのように反応するかを調べるためにプロトタイプを作成しました。 この作業は開発プロセスの非常に早い段階で行われ、プログラマが製品自体の見直しを開始する前に、モデルの原則を調整する時間が与えられました。
チームは、通常 Money で実行される個人の財務アクティビティをシミュレートするプロトタイプを Microsoft Visual Basic と HTML で作成しました。 プロトタイプでは、ユーザーは製品の主要領域を表す 50 ページを超えるページに移動できます。 これらの領域では、財務口座の設定、請求書の支払い、レポートの表示、投資の処理を行うことができました。
11 人の参加者が、Money 99 と IUI プロトタイプの両方で同じタスク セットを実行しました。 彼らは、最初に製品の 1 つを使用するようにランダムに割り当てられました。 4 人の参加者は現在の Money ユーザーで、4 人は競合製品の現在のユーザーであり、3 人は以前にパーソナル財務製品を使用したことがないユーザーでした。
全体的な設定では、Money の現在の 4 人のユーザーが Money 99 (自宅で使用していたバージョン) を優先し、残りの 7 人のユーザーが新しいプロトタイプを現在のバージョンに優先していることを示しました。 その他のすべての対策では、3 つのグループのユーザー間に違いはありませんでした。 全体的なパフォーマンスの面では、ユーザーは、プロトタイプと同じように、Money 99 (タスクあたり 2.82 回) を使用して製品間違った領域に 2 回いました (1 タスクあたり 1.45 回)。 他の設定データとパフォーマンス測定は重要ではありませんが、プロトタイプを支持しているように見えました。 このデータやその他のテストに基づいて、Money 製品チームは Money 2000 に IUI 原則を組み込むことを決定しました。
製品テスト
製品のコードの大部分が完了すると、チームは IUI の最終的な実装を調べるために別のユーザビリティ調査を行いました。 このテストでは、以前にパーソナル財務製品を使用したことがない 10 人の参加者が、Money 99 または Money 2000 のいずれかを使用するように選ばれました。 すべてのユーザーが同じタスクを実行しました。
Money 2000 のユーザーはタスクの 89% を正常に完了し、Money 99 のユーザーがタスクを正常に完了したのは 74%でした。 プロトタイプと同様に、ユーザーは Money 99 と比較して Money 2000 で移動する方が速く見えましたが、大きな違いはありません。 さらに、ナビゲーションに対する全体的な主観的満足度の測定も、Money 2000 では Money 99 よりも高くなる傾向があります。
コントロールされたテスト
Money 2000 は膨大で複雑であるため、IUI の適用効果に対するコントロールされたテストの実施には適していません。 代わりに、チームはテストをする上でより制約のある環境を作成しました。
このテストでは、ユーザーが画面に表示される株価レポートの表示を変更できる「株価ビューアー」アプリケーションが含まれています。 ユーザーは、レポートに含まれるデータの列、レポート列の順序、配置、および使用される小数点以下の桁数を変更できます。 デザイナーは、従来のグラフィカル ユーザー インターフェイスと比較して、このタスクに対する IUI アプローチがどのように実行されるかを確認したいと考えていました。
次のスクリーン ショットは、テストで使用される従来のユーザー インターフェイスを示しています。 1 つのダイアログで、すべてのレポートのカスタマイズ タスクが実行されます。 多くのアプリケーションでは、項目の一覧からサブセットを選択するための同様のダイアログが用意されています。 ダイアログには 2 つのリストが含まれています。左側のリストには、使用可能なすべてのレポート列が表示され、右側にはユーザーがレポートに対して選択した列のサブセットが表示されます。 追加のコントロールは、右側のリストで選択されたレポート列の順序と書式設定属性を変更します。
このタスクの IUI バージョンでは、チームは Web スタイルのアプリケーションを作成しました。 各カスタマイズ タスクは個別のページに配置されました。 アプリケーションには、次のスクリーン ショットに示すように、レポートのカスタマイズ方法をユーザーに尋ねるメイン ページも含まれていました。
このメイン ページのリンクをクリックすると、ユーザーは追加のページに移動し、特定のカスタマイズ タスクを実行できます。 たとえば、次のスクリーン ショットは、レポート列の選択に使用されるページを示しています。
両方のバージョンのテストでは、件名は、特定の開始状態 (画面に表示) から指定された目標状態 (配布資料に表示) にレポートをカスタマイズするように求められました。 コンピューターは、レポートをカスタマイズするために行われた時間と試行数を追跡しました。 コンピューターは、レポートが正常にカスタマイズされたときにユーザーに通知しました。
テストには 88 人の参加者が含まれていました。 各参加者は、アプリケーションの 2 つのバージョンのいずれかを使用して 11 個のレポートのセットをカスタマイズするように求められました。 さらに、これらの参加者のうち 72 人が 1 週間後に戻ってきて、最初のセッションと同じバージョンを使用して 11 個のレポートの別のセットをカスタマイズしました。 すべての主題は、主に電子メール、ソリティア、Web サーフィンにコンピュータを使用して、初心者のコンピュータ ユーザーとして分類されました。
2 つのバージョンのユーザー間、または関心のある他の変数の間に大きな違いはありませんでした。 ユーザーは同じ速度でタスクを実行し、同じ回数だけタスクを反復処理し、2 つのバージョンで同じ全体的な主観的満足度評価を持っていました。 したがって、このテストでは、IUI がパフォーマンスまたは主観的評価が改善または低下をもたらすことに対する対策を示せませんでした。
ユーザーがタスクを実行するためにさらに移動する必要がある場合は、タスクを実行する時間が長くなる必要があると主張される場合があります。 この実験ではこの結果は示唆されませんが、このタスクに対する 2 つの異なるアプローチの平均パフォーマンス時間とそれに関連する標準偏差はほぼ同じであることに注意することが重要です。
IUI の使用から測定可能な改善があるかどうかを判断するには、さらなる研究が必要になります。 少なくとも、このテストでは、IUI がパフォーマンスや製品の使用に悪影響を与えるという証拠は提供されませんでした。
Web サイトとの比較
適切に設計された Web サイトの多くは、このドキュメントで説明されている IUI モデルと同様の原則を使用します。 これはおそらく、Web の動作方法の副作用です。 1 つの Web ページでコントロール間の複雑な相互作用を実装するのは難しいため、デザイナーは多くの場合、新しいページを取得するためにサーバーへの複数のトリップを含むタスクを分割します。 一部のサイトには、ページの目的を明確に示すページ タイトルも含まれています。
従来のアプリケーションのデザイナーは、より豊富なツールセットを利用できます。 これにより、柔軟性が向上しますが、複雑で混乱を招くページを作成する機会も増えます。 誘導性の高いユーザー インターフェイスを作成する場合、デザイナーはこの機能を随意で使用し、明確さとシンプルさを忘れずに評価する必要があります。