実践的なユーザビリティ

アプリケーション ナビゲーションの設計戦略

Dr. Charles Kreitzberg および Ambrose Little

目次

認知的視点
ナビゲーションはメタファである
ユーザーが混乱する理由
複数のページを論理セクションにグループ化する
フレームを作成する
ナビゲーション支援機能を使用する
まとめ
ソフトウェア的視点
大企業をコピーする
カード分類法
UX デザイン パターン
明確なエントリ ポイント
実装
コントロール
テスト、追跡、および微調整
まとめ

認知的視点

Dr. Charles B. Kreitzberg

ナビゲーションを適切に作成することは、設計の最も重要な側面の 1 つです。ナビゲーションは、画面、操作、および視覚的な外観を設計するためのフレームワークです。ユーザビリティの最も基本的な原則は、ユーザーができるだけ簡単にソフトウェアを操作でき、ソフトウェアを使用する本来の目的を果たす作業に集中できるようにすることです。ナビゲーションがわかりづらく、理解するために注意が必要な場合、ユーザビリティは低下します。

ナビゲーションはメタファである

"ナビゲーション" という用語は、ある場所から別の場所へ移動するという概念を表しています。そして、ある場所から別の場所に移動する経路と、移動する方法を指示または制限する基本的なフレームワークが存在することも示しています。しかし、ソフトウェア製品におけるナビゲーションとは、ユーザーがどこかに移動することを意味しているわけではありません。操作に応じて画面上の画像が変化するだけで、ユーザーは 1 か所に留まっています。つまり、"ナビゲーション" はまさにメタファであり、設計を理解するために行う精神的なゲームです。

ナビゲーションについて考える場合、ほとんどの人は画面間を移動する手段としてメニューに目を向けます。しかし、単一画面を中心に構築された強力なプログラムを記述することも十分可能です。Microsoft Word を例に考えてみましょう。多数の強力な機能を備えているにもかかわらず、図 1 に示すように、プログラム全体はほぼ単一画面を中心に構築されています。

図 1 Word の解剖 - すべてが単一画面に収まっている

作業中のドキュメントは画面設計の中心となります。リボンから選択したツールをドキュメントに適用すると、コンテンツや外観が変更されます。複雑な操作が必要なツールの場合は、通常、ドキュメント上に子ウィンドウが表示されます。子ウィンドウがモーダル ウィンドウの場合、ユーザーはドキュメントに戻る前に、操作を完了させ、その子ウィンドウを閉じる必要があります。その一例が "図の挿入" コマンドです。ユーザーに操作手順を示すウィザードの場合もあります。また、子ウィンドウが類義語辞典コマンドのようにモードレスな場合は、ドキュメントの操作中に、子ウィンドウを端にドッキングし、開いたままにしておくことができます。

単純な単一画面ナビゲーションによるアプローチの利点は、ユーザーが決して迷子にならないことです。ドキュメントは常に平面です。ユーザーは依然としてツールの場所とその動作を学習する必要はありますが、サイバースペースで迷子になったり、ドキュメントがどこに行ったのかわからなくなったりすることはありません。単一画面パラダイムはワード プロセッサ アプリケーションに広く利用されていますが、それ以外にも、Microsoft Paint などの画像処理プログラムや Microsoft Excel などの表計算プログラムにも問題なく利用されています。Excel では、図 2 の左下に見える、関連付けられたタブをユーザーがクリックしたときにアクティブなドキュメントを切り替えることで、複数のドキュメントを扱いながら単一画面のメタファを維持する優れた方法が採用されています。

図 2 Excel でも単一画面を採用している

単一画面メタファの簡潔さには、非常に大きな価値があります。しかし、ほとんどのプログラムは複数画面 (または複数ページ) のメタファを中心に構築されています。複数ページを中心にプレゼンテーション層を設計することに決めると、多くの混乱を招く可能性があります。さまざまなユーザビリティ テストを見てきた結果、ユーザーを新しいページに連れて行くたびに、ユーザーを迷子にさせる危険を冒しているということに気が付きました。

ユーザーが混乱する理由

考えてみれば、画面間を移動することで迷子になることは驚くことではありません。迷子になるとは、ユーザーが方向感覚を失うことです。図 3 の 2 人のユーザーを見てください。Bob は単一画面を中心に設計されたプログラムで作業しています。Sally は複数画面を中心に設計されたプログラムで作業しています。

この図を見れば、Sally の方が認知作業がたいへんなことが一目瞭然です。Sally は今どこにいてどこに行くかを考える必要があるだけでなく、一度に 1 画面しか表示できないという事実によって、内部の道路地図を作成する厄介な作業がさらに複雑になってます。全体を見渡すことができないため、不慣れなソフトウェアの使い方を覚えながら、自分の頭の中にあるモデルをまとめる必要があります。これは余分な作業で、それによって習得に時間がかかる可能性があります。

図 3 ユーザーを混乱させる

サイトや製品のナビゲーションは、プレゼンテーション層の設計全体の骨組みになります。適切に作成することにより、製品のユーザビリティを向上させることができます。ナビゲーションの設計を開始するにあたり、次の提案を検討してください。

可能な限り単一ページ ナビゲーションを使用する

単一ページのメタファは単純で強力です。ユーザーに混乱や困惑を感じさせないように画面設計に気を配れば、1 つのページにたくさんの機能を盛り込むことでユーザビリティを大幅に改善できます。単一画面設計の強力な点は、新しい情報を見ている間に、ユーザーがコンテキストを見失うことがないことです。

Web のドキュメント指向、検索エンジンがユーザーを内部ページに導く頻度、検索エンジン最適化 (SEO) 技術の制限、および HTML とその基本的な UI コントロールのあまりスマートでない再描画特性により、標準的な設計手法として多数の Web ページを作成することが一般的になっています。ページをたくさん作成して、そのどこかにユーザーを連れて行けばよいという場合もありますが、それは非常にまれです。World Wide Web の喜びとパワーである無料リンクは、ネットサーフィンには最適ですが、タスク フローが伴う状況にはあまり適していません。

あるページから別のページに移動させることがどれだけユーザーの方向感覚を失わせるのかを認識していないと、必要以上に多くのページを設計してしまいがちです。ユーザビリティ テストのときにユーザーが言っていましたが、目的のページを探す場合、サイトのナビゲーションを使用しないで直接検索ボックスを使用するそうです。

現在では、高度な UI コントロールを備えた機能豊富な Web ページを作成できます。タブ、カルーセル、アコーディオン、ツールヒント、および子ウィンドウは簡単に利用でき、それらを使用して必要な画面間のナビゲーションの数を減らすことができます。

筆者が本気でお勧めする設計のアイデアは、可能な場合は画面間のナビゲーションを避けることです。単純な例を使用して、その理由を説明します。図 4 は、一般的な Web のナビゲーション設計を示しています。

図 4 一般的な Web のナビゲーション

この例では、会社の一連の製品が 1 番目のページに一覧表示されています。目的の製品名をクリックすると、ユーザーは製品情報ページに移動し、そこから製品一覧に戻ったり、3 番目のページに移動して保証について確認したりできます。

図 5 に示す単一画面バージョンのナビゲーションをご覧ください。このバージョンでは、3 つの製品が 1 つのタブ コントロールに表示されています。タブをクリックすると、製品の説明が表示されます。ユーザーが "Warranty Information (保証情報)" のリンクをクリックすると、その情報がモーダル ポップアップ ウィンドウに表示されます。ポップアップ ウィンドウを閉じると、元のページに戻ります。

図 5 単一画面のナビゲーション モデル

もちろん、たくさんの選択肢を扱う必要がある場合、タブには拡張性があまりないため、リスト ビュー コントロールや、カルーセルのようなおもしろいコントロールを検討します。これらの図を見れば、2 番目のナビゲーション モデルの方がはるかに単純なことがわかります。また、製品タブの上にたくさんのリンクを配置し、それぞれのリンクから別のウィンドウ (またはウィザード) を表示させることができるという利点があります。1 回のクリックで常に基点に戻ります。そこにはポップアップ ウィンドウを表示したときと同じ製品が表示されます。この方法では、コンテキストが維持されるため、ユーザーは非常にわかりやすいと感じます。詳細情報を取得するためにページを移動することはありません。

確かに、筆者が設計した製品の多くは複数のページで構成されています。結局、単一ページに収めることができる機能の数には限りがあります。複数のページも慎重に使用し、わかりやすい形で機能をグループ化することで、UI を単純化できます。コツは、ユーザーを新しいページに連れて行くたびに、コンテキストが失われ、ユーザーが迷子になる危険性があるということを認識することです。そのため、筆者は控えめに、慎重に使用しています。さらに、ページをセグメント化する適切な方法を真剣に考えています。

複数のページを論理セクションにグループ化する

筆者にとって、何の変哲もない HTML リンクはナビゲーションの悪夢です (筆者と同僚の Ben Shneiderman は Web 以前のハイパーテキスト ブラウザである HyperTies で本当に悪夢を見ました。この話は別の機会にします)。ユーザーはリンクをクリックするたびに、新しいページに転送されます。慎重に設計しないと、移動することで、森で迷子になったような気持ちにすぐになります。

複数のページで構成される製品を設計している場合は、ページをセクションに集約する方法について知恵を絞ってください。図 6 は、ページをサブセクションにグループ化した、一般的なナビゲーション設計を示しています。

図 6 一般的なナビゲーション設計

メイン メニューは一連のタブで構成されており、Home (ホーム ページ) と 3 つの Section (セクション) があります。セクションに入ると、セクション メニューを使用してそのセクション内のページを移動できます。コンテンツ領域などには、多状態のコンテンツ コントロールを使用しています。Section 1 にはタブ コントロールを、Section 2 にはアコーディオン コントロールを配置しています。

このように設計することで、たくさんのページを管理できます。たとえば、メイン メニューのセクションが 7 つあり、各セクションにはページが 7 つ、各ページには 7 つのペインを備えた多状態のコンテンツ コントロールが 1 つある場合、7³、つまり 343 の異なるページを効率的に制御していることになります。また、各コンテンツ ペインからポップアップをいくつでも表示させることができるめ、多くのサイバー不動産を管理することができます。ページがもっと必要な場合は、スライドアウト メニューやカスケード メニューを使用してメニューを拡張できます。

特に注意が必要なのは、メニュー以外のナビゲーションを作成する必要がある場合です。ユーザーを別の場所に移動させるリンクやボタンをページのコンテンツに配置したくなることがよくあります。しかし、それによって問題が起こるのを何度も経験しています。できる限り、ナビゲーションにはメニューを使用し、埋め込まれたリンクやボタンはコントロールの状態変更やポップアップの表示に使用します。

図 6 に示したナビゲーション モデルには、暗黙的な階層が存在しています。パスを図で示すと、そのことがよくわかります。

図 7 を見ると、セクション間の水平ナビゲーションとセクション内のナビゲーションが存在することがわかります。この場合、対処が必要な問題がいくつかあります。

図 7 セクション間のナビゲーション

1. セクション間を移動するときに、どこに到達しますか。目的地は、実行しようとしている作業の流れによって異なります。通常、最初にセッションにアクセスしたときは、セクションの最初のページ (たとえば、図の Page A) にユーザーを連れて行くと、最も混乱が起きません。そのページをセクションへの入り口 (つまり、セクションの "ホーム" ページ) として設計することもできます。次に、ユーザーがセクションを離れ、戻ってきたときに、同じページが表示されるようにサイドバー メニューの状態を保持します。
2. たとえば、ページ B からページ G に移動する必要がある場合はどうでしょうか。

ナビゲーション モデルを逸脱すると、ユーザーを混乱させることになるため、特に注意が必要です。まず、2 つの内部ページを移動する必要がある理由を確認します。タスクを完了させるために両方のセクションに移動する必要がある場合は、設計の調整が必要になる場合があります。1 つのタスクを 2 つの内部ページに分割すると、作業しづらく、非効率になります。

最近、データ ファイルとログ ファイルを書き込むファイル転送プログラムで、この問題に遭遇しました。その環境では、USB ドライブを抜き差しすることで割り当てられたドライブ文字が毎日変わるため、そのプログラムを使用するたびにドライブ文字をリセットする必要がありました。"セクション A" に移動してデータ ファイルの場所を設定し、次に "セクション B" に移動してログ ファイルの場所を設定する必要がありました。非常に不便で、時間の無駄でした。

このような状況を解決するには、すべてのディスク情報を 1 ページにまとめるか、それができない場合は、別のページに移動せずに設定できるように、2 番目のディスクの "シャドウ コピー" をポップアップ ウィンドウに表示させます。

利便性だけの問題なら、複雑にしてまでユーザーのクリック回数を減らす価値があるかどうかを判断する必要があります。これは、ユーザーが移動する必要がある頻度によって決まります。頻度が少ない場合、ナビゲーションが簡単でマウスのクリック回数が多い方を選びます。頻度が多い場合は、ユーザーが 1 ステップで内部ページに移動できるように、水平メニュー バーにドロップダウン メニューを配置することを検討します。ユーザーをある内部ページから別の内部ページに移動させるという状況は思いつきません。"スタートレック" では非常に役立つでしょうが、ソフトウェアでは迷子になりやすくするだけです。

フレームを作成する

最後に、視覚的な設計がどのように移動しやすさに役立つかについて説明します。まず、ページ フレームに使用する要素について考えます。要素は、すべてのページに一貫して表示されます。ユーザーが迷子にならないようにする最善の方法の 1 つは、予測可能な場所に一貫した要素を配置することです。そうした要素は、ユーザーにとって視覚的なアンカーになります。

ほとんどのフレームにとって重要な要素はページ タイトルです。ページ タイトルは、ユーザーがページを名前に関連付けるのに役立つだけでなく、サポート スタッフとやり取りするときにも便利です。

色分けについても考えます。前の例では、Home セクションに水色、Section 1 に緑色、Section 2 にオレンジ色を使用しています。色分けすることで、ユーザーはどのセクションにいるのかを把握できます。また、色覚障害をお持ちのユーザーをサポートするためには、視覚的な設計に図形やテクスチャも使用します。

ナビゲーション支援機能を使用する

使用する価値のあるナビゲーション支援機能は、階層リンクとサイトマップの 2 つです。これらの機能だけで設計の問題を解決できるわけではありませし、階層リンクに至っては、見たことがないか、理解していないユーザーが多いでしょう。しかし、理解しているユーザーにとっては便利で役に立つ機能です。ユーザビリティの専門家の Jakob Nielsen は、自身の Web サイトの useit.com で、階層リンクを利用するユーザーが増えていることを指摘しています。また、階層リンクにはページ アクセスの履歴ではなく、ナビゲーション階層を反映させる必要があると主張しています。これは、筆者もまったく同意見です。

サイト マップは、ユーザーがナビゲーション レイアウトを把握するの機能です。あまり活用されていないようですが、ナビゲーションの概観を把握するのに役立つため、サイトには必要です。ただし、それで設計の問題を解消できるとは思わないでください。

ユーザビリティ コミュニティのお決まりの冗談の 1 つに、ユーザビリティに関するどの問いも答えは 1 つ、"それはケース バイ ケース" というのがあります。残念ながら、これはナビゲーションにも当てまります。設計のルールは数少なく、ほとんどはガイドラインと経験則です。そのため、UI を設計する前に、ユーザーを研究し、使用のコンテキストを理解することが非常に重要になります。

その注意を念頭に置きつつ、ベスト プラクティスをいくつか紹介します。

1. ナビゲーションの選択肢について理解および判断するために必要な労力を最小限に抑える。UI を使用するために費やす労力が少なければ、それだけユーザビリティは向上します。
2. 可能な場合は、単一画面設計を使用する。複数ペインの高度なコントロール、ポップアップ、およびウィザードを使用すると、横方向のナビゲーションに頼らなくても、ユーザーは非常に多くのタスクを実行できます。
3. 複数のページを作成する場合は、それらをセクションにまとめる。メインのナビゲーション コントロールを使用してセクション間を簡単に移動できるようにし、セクション内の移動には補助的なコントロールを使用します。階層を深くすることは極力避けます。ナビゲーションが単純だと、その分ユーザーがスキルを身に付けるのが早くなります。
4. メニュー、タイトル、すべてのページに表示されるその他の情報など、主な要素が、視覚的な観点から一貫して表示されるようにする。ユーザーは、画面の一部の要素が固定されていて、それによって方向感覚を維持できるという感覚を持ちます。
5. あるセクションの内部ページから別のセクションの内部ページにユーザーを移動させるナビゲーション要素に対して十分注意する。この操作は実現可能ですが、ユーザーが迷子になりやすくなります。
6. 階層リンク、サイトマップなどの補助的なナビゲーション支援機能を使用するが、それに依存しない。
7. 今後の拡張について常に考える。将来的に製品に新しい機能を組み込む場合は、ナビゲーションを拡張して新しい画面をシームレスに組み込む方法を最初に決めておきます。

ナビゲーションを適切に作成することは、製品のユーザビリティを確保するための最も重要な作業の 1 つです。時間をかけて適切に作成し、ユーザビリティ テストを行って設計を確認すれば、満足のいく結果が得られます。

ソフトウェア的視点

Ambrose Little

ナビゲーションはほとんどのソフトウェアの開発者が当たり前と考えているものの 1 つで、設計に関する疑問と同様、開発者は他の開発者のやり方を見たり、取り入れたりする傾向があります。開発者は "Office のようにしろ" とか、"Amazon.com のようにしろ" などとマネージャから要求されますが、プログラムを動作させることに集中しているため、設計について考える時間はほとんどありません。

実際の情報アーキテクト (または何でもこなす器用な UX 開発者) と一緒に作業する幸運な開発者もいます。ときには、グラフィックス設計者がナビゲーションを設計の一部として扱ってくれるのを期待することもありますが、彼らのほとんどは専門知識や背景知識を持っていません。しかし、ありがたいことに、ナビゲーションの厄介な問題に対処するための優れたリソースがたくさんあります。ここでは、その一部を紹介します。

大企業をコピーする

まず、業界上位の企業のやり方を取り入れることは必ずしも悪いことではありません。彼らは情報アーキテクチャに大量の時間とリソースを実際に費やして、ユーザーが期待するものを方向付けている可能性は十分にあります。ある意味で、規則を作成し、標準を設定し、結果的にソフトウェアの動作方法に対する期待を変更しています。

そうは言っても、Charlie が指摘したように、開発者が提供するソリューションのユーザーについて、そして扱う対象となる要素について実際に理解する方がはるかに優れています。これらの要素には、Web サイトやドメイン内のオブジェクトの情報とコンテンツが含まれます。ユーザーを理解する際に重要となるのは、ソリューションを使用する目的を理解することです。正しく理解すれば、アプリケーションを適切に構築するのに非常に役立ちます。

大企業から学ぶ所はたくさんありますが、対象ユーザーが異なる場合があるため、無条件に従う必要はありません。皆さんのユーザーの方が非常に少ないこともありますし、コンテンツや製品がまったく異なることもあります。この違いを最もよく示している例として、Microsoft Office のリボン (図 8 を参照) を模倣する試みがあります。

図 8 Microsoft Word のリボン (Office Fluent UI の一部)

リボンは最新の Office UI スキームであるため、多くの開発者によって模倣される傾向にあります。問題は、リボンを使用すると、ナビゲーション設計のひどさが目立つように感じることです。標準のメニュー、タブ、およびその他のコントロールを適切に作成していない場合は、ひどいナビゲーション設計であっても問題が起きないかもしれませんが、リボンは適切に使用しないとメタファが壊れます。

タブはユーザーの目的やタスクに基づいている必要があります。そのため、要素を挿入するためのタブ、ページ レイアウト用のタブ、ドキュメントを校閲するためのタブがあります。そして、タブ内にはコマンドのグループ (図 8 の Clipboard (クリップボード) および Font (フォント) など) があり、それらもユーザーに重点を置いており、関連するタスクやアクションに基づいてグループ化されています。リボンでは、よく使用される機能をユーザーが簡単に見つけて使用できるように、使用率データに基づいたさまざまな大きさのボタン (大きな Paste (貼り付け) アイコンおよび小さな Cut (切り取り) アイコンと Copy (コピー) アイコン) を使用しています。

つまり、効果的なリボン スタイルの要素を設計するには多くの労力が必要になります。そのため、リボンをナビゲーション メカニズムとして自分のアプリケーションに無条件に採用しないでください。

他のアプリケーションを模倣する前に、その設計が自分の状況に適しているかどうかを判断する必要があります。まず、規模は同じですか (Amazon.com や Netflix では膨大なユーザー データに基づいたお勧めを表示していますが、これを取り入れるには相当な規模が必要です)。Office には多層構成のリボンの恩恵を受ける多数のコマンドがありますが、コマンドの数が少ない場合は、おそらく一般的なメニューの方が適しています。

コンテンツの種類は同じですか。Amazon のような e コマース サイトのナビゲーション メカニズムは、環境に関する情報を提供するサイトには適していないことがあります。また、情報を提供するサイトのナビゲーション メカニズムは、アプリケーションには適していないことがあります。Charlie が説明したように、ユーザーがタスクを完了させようとしている場合は、Web 上で一般的に使用されている簡単なナビゲーション モデルはおそらく適していません。その理由は、ユーザーが目的を達成できるようにすることが目的で、邪魔をしたり、不思議の国に通じるウサギの穴に落としたりすることが目的ではないからです。

では、どうなるのでしょうか。がっかりしないでください。相談する UX の専門家がいなくても、ナビゲーションの改善に役立つ手法があります。そのような手法の 1 つに、カード分類法と呼ばれるものがあります。

カード分類法

カード分類法は、関係者 (できれば対象ユーザー) に、コンテンツの整理を手伝ってもらう方法です (図 9 に例を示します)。この手法は、利害関係者にソリューションの設計に積極的に参加してもらう必要がある点で (またカードを使用する点でも)、Class Responsibility Collaborator (CRC) カード (オブジェクト指向設計 (OOD) の手法の 1 つ) やユーザー ストーリーなど利害関係者が関与する他の手法と似ています。一般的に、この手法は Web サイト上の情報を整理するために使用されていますが、アプリケーションのコマンドを整理するためにも使用できます。

図 9 Usability.gov/ design/cardsort.html のカード分類法の例

この手法は、ソリューション中心 (またはドメイン中心) ではなく、ユーザー中心のアプローチなので、そのソリューションを実際に操作するユーザーにとって意味のある設計を見極めるのに役立ちます。ここでは、実際の手法については詳しく説明しません。ユーザーが皆さんのために資料を分類してくれる、と言うだけにとどめておきましょう。オンラインで無料で利用できるリソースはたくさんあります (http://www.usability.gov/how-to-and-tools/methods/card-sorting.html など)。また、OptimalSort など、この作業に役立つソフトウェア パッケージがいくつかあります。しかし、ソフトウェアを使用する前に、インデックス カードのアプローチを検討してください。一般的に、関係者を直接集め、実際のカードを使用すると、良い結果が得られるということに専門家も同意しています。

UX デザイン パターン

UX デザインの最高のリソースの 1 つは、パターンだと思います。ナビゲーションのデザイン パターンには、ユーザーが自分の位置を確認するのに役立つ階層リンク、検索結果に関するファセット (メタデータ) を使用して自発的に検索結果を絞り込むファセット ナビゲーション、使い慣れたモーダル ダイアログを起動するモーダル パネル、それ以外にも多数のパターンがあることは驚くことではありません。例として、図 10 に明確なエントリ ポイント パターンのサンプルを示します。

明確なエントリ ポイント

ユーザーがアプリケーションを起動したとき、またはサイトを参照したときに、何ができるのか、何をする必要があるのかがわからないことがあります。最も一般的なタスクや目的に基づいた、アプリケーションや Web サイトへの一連の明確なエントリ ポイントをユーザーに提供する必要があります。

図 10 明確なエントリ ポイントの代表的な例

明確なエントリ ポイントがないと、新しいユーザーやたまにしか利用しないユーザーは、アプリケーションやサイトを開いたとたん、途方に暮れてしまうことがあります。ユーザーを明確なエントリ ポイントに導くことで、何ができるのか、何をする必要があるのかを理解する手間を省くことができます。

このパターンは、ほとんどの対象ユーザーにとっての最も一般的な一連のタスクや目的がわかっている、または見つけることができる場合にのみ有効です。それができない場合は、このパターンを使用してもユーザーの邪魔をするだけで、やりたいことへ導くことができないため、さらに問題が発生します。

問題のタスク以外にも関連するタスクがある場合、一般ユーザーは明確なエントリ ポイントを邪魔だと感じる場合があるため、ほとんどのユーザーが新しいユーザーかたまにしか利用しないユーザーであることが重要です。

ユーザーが何をする必要があるかは明確だ、と思い込まないでください。多くのホーム ページは、その背後にある組織が提供する必要のあるあらゆるものを寄せ集めたけなので、ユーザーは何をすればよいか、どこに行けばよいかわからず、混乱します。明確なエントリ ポイントは、その混乱を解消します。

実装

明確なエントリ ポイントのパターンのコツは、主要なタスクや目的をうまく特定することです。ユーザーの立場に立った設計を行っているなら、ユーザーの主要な目標を達成するためのタスクとして既にそれらを特定していることと思います。その情報を使用して、明確なエントリ ポイントを作成します。

ユーザーの立場に立った設計を行っていない場合は、何らかの調査 (おそらくは内部と外部の両方) を行って、ユーザーの主要なタスクや目的を特定する必要があります。アプリケーションやサイトが既に存在している場合は、利用状況に関するログを確認すると非常に参考になります。また、通常、機能仕様からも主要なタスクを取り出すことができますが、選択したタスクがアプリケーションやサイトが提供する主要な目的と一致しているかどうかを、ユーザーや少なくとも利害関係者と一緒に検証する必要があります。

主要なタスクが明確になったら、それを提示する方法を考えます。タスクがいくつかある場合は、視覚的にグループ化する方法を考える必要がありますが、メイン ナビゲーションのレプリカにならないように注意して、主要なタスクを提示します。

アプリケーションやサイトの開始画面の中央にはっきりとタスクを表示します。タスクの名前には、ツールの名前などの商標の付いた用語やユーザーになじみのない用語ではなく、ユーザーが完成させるタスクに関連するものを付けます。タスクを短い言葉で表現できれば理想的ですが、おそらく、名前を補足するために、そのタスクや目的を選ぶことで達成できる事柄をわかりやすく、明確に示す説明が必要になります。

ユーザーを突然ソリューション構造の真ん中に落とすような落とし穴を作成していないことを確認します。ユーザーがタスクを選択することで達成する目的はタスクと明確に関連付けられている必要があります。それにはウィザードが適していますが、選択されたタスクとタスクを選択することで表示される画面が密接に関連付けられていれば、ウィザード ベースである必要はありません。

直接開始可能なサブタスクがある場合は、ユーザーがメイン タスクを選択したときにサブタスクが画面に表示されるようにすることもできます。ただし、完全なメニューやナビゲーション スキームである必要はありません。

最も一般的なタスクにユーザーを自動的に引きつけるために、他のタスクよりも視覚的に強調することをお勧めです。メインのエントリ ポイント画面の周りに、通常のナビゲーション構造や補助ツールまたは情報を配置する必要はありません。エントリ ポイントを目立たせるために、そうしたものは隠しておきます。

考えてみると、コントロールは一般的に、再利用可能なコードにまとめたパターンの実装であることがわかります。Silverlight、特に Silverlight 1.0 での開発 (または強力なデスクトップ UI 開発) を行っている場合は、おそらくコントロールの恩恵に対して深く感謝しているでしょう。テキスト ボックスの基本的な対話でも、手動で描画および処理するのは簡単なことではありません。

さらに、コントロール、特に HTML 仕様などのプラットフォーム コントロールは、暗黙的な標準の UI パターン規則を作成します。複数選択には他にも多くのオプションがありますが、Web では HTML SELECT コントロールが事実上の標準コントロールになっています。Rich Internet Application (RIA) プラットフォームでは、選択肢はたくさんありますが、付属のコントロールは最終的に規則を作成することは確かです (もちろん、それまでのプラットフォーム コントロールの使用状況に影響を受けます)。カスタム コントロールを使用して実装できる、多くの場面で役立つもっと複雑なパターンはたくさんありますが、Infragistics などのサードパーティ ベンダのコントロールを利用することもできます。

当然ながら、ナビゲーションの場合、最も一般的なコントロールはハイパーリンクであり、Charlie が指摘したように、タスク指向のアプリケーションでは慎重に、そして控えめに使用する必要があります。似たようなアイテムのグループ化、グループ間のナビゲーション、およびユーザーが (現在選択されているタブを通じて) 見ている対象を示す暗黙的な方法に役立つタブ コントロールがあります。Web プラットフォームとデスクトップ プラットフォームの両方にフライアウト メニュー コントロールがあります。これらを使用する場合は、3 階層 (できれば 2 階層) を超えないように注意してください。おそらくメニューに力を入れている技術者は驚くと思いますが、こうしたメニューを使用するユーザーは、マウス操作に十分慣れている人でない限り、あるメニューから別のメニューへとすばやくマウスを動かすことに困難さを感じるからです。その他、パターンの実装を容易にするタグ クラウド コントロール、そのパターンに役立つページング コントロールやダイアログ コントロールなどがあります。

タグとタグ クラウドは、目的の情報の検索に役立つ柔軟な構成を作成するための優れた方法です。それらを使用すると、メニューなどのより形式的な編成スキームを補完できます。図 11 に例を示します。

図 11 Flickr のタグ クラウド

選択するコントロール (パターン) ついて考えることを忘れないでください。簡単だからとか、一番使い慣れているからという理由で使用しないでください。パターン カタログを参照して、どのパターンをいつ使用するのかについて深く理解しましょう。また、パターンに基づいて、実装 (存在する場合) を選択することもできます。

テスト、追跡、および微調整

どのようなナビゲーション スキームや編成スキームを使用していても、問題が出てきます (少なくとも部分的には)。今のところ問題がなくても、時間の経過と共にニーズが変化する可能性があります。そのため、Charlie が説明したように、拡張性と柔軟性を備えたナビゲーション設計に力を注ぐ必要があります。

定期的にナビゲーション構造を大幅に変更する必要はありませんが、実際の使用状況データやユーザビリティ テストに基づいて微調整する必要はあります。ユーザビリティ テストを行うと、アプリケーションをリリースする前に問題を見つけることができるため、お勧めです。ただし、テストを行い、その結果に基づいて変更できるように、プロジェクトのスケジュールに余裕を持たせてください。

Web のログや機能の使用状況の追跡などの使用状況データがある場合は、それを使用して、既存の設計がどのように使用されているかを把握し、それに応じて変更を加えます。検索ログは特に有益です。その理由は、ユーザーはナビゲーションの代わりに検索を使用するため、検索ログからナビゲーション スキームの欠点がわかるからです。Web ベースの追跡を使用していない場合は、将来的な変更を支援および通知するデータを入手するために、使用状況の追跡インフラストラクチャの作成を検討します。

開発者として他にも懸念事項がたくさんある場合、優れたナビゲーションの作成は少々困難な作業に思えるかもしれません。一緒に作業する専門家がいない場合は、ここで説明した提案のいくつかに従って、独自に処理することができます。

ナビゲーションは非常に重要で、時間やリソースを注ぐ価値があります。パターンの助けを借りて少しずつ作成することができます。また、Steve Krug の『ウェブユーザビリティの法則』、Peter Morville の『アンビエント ファインダビリティ』などの読みやすい優れた入門書も役立ちます。ナビゲーションに注力することで、皆さんのソフトウェアを使用するユーザーの満足度は向上するでしょう。

Dr. Charles Kreitzberg はユーザビリティのコンサルティングとユーザー エクスペリエンスのデザイン サービスを提供する Cognetics Corporation (www.cognetics.com) の CEO です。彼は、製品のビジネス目標をサポートしつつも、ユーザーを魅了し、楽しませる直感的なインターフェイスを作成することに情熱を燃やしています。セントラル ニュージャージー在住で、パフォーミング ミュージシャンとして夜間のアルバイトをしています。

Ambrose Little は、夫人と 4 人の子供とセントラル ニュージャージーで暮らしています。ソフトウェアのデザインおよび開発に 10 年以上携わっており、INETA 講演者であり、Microsoft MVP でもあります。最近は、テクニカル デザインから人々のためのデザインにシフトし、現在は Infragistics 社のユーザー エクスペリエンス デザイナです。