よくあるガイドラインからの逸脱

ウィンドウ
レイアウト
テキスト
コントロール
キーボード
マウス
ダイアログ ボックス
プロパティ シート
ウィザード
ウィザード ページ
エラー メッセージ
警告メッセージ
確認
アイコン
ヘルプ

ここでは、UX ガイドにあるガイドラインに関して最もよくある逸脱をまとめています。これをチェックリストとして利用し、プログラムのユーザー インターフェイスについて、以下の重要なアイテムが適切に設定されていることを確認してください。

ウィンドウ

  • Windows の最小有効解像度 (800 × 600 ピクセル) をサポートします。セーフ モードで動作する必要のある重要なユーザー インターフェイス (UI) では、640 × 480 ピクセルの有効解像度をサポートします。タスク バーと共に表示するウィンドウについては、縦方向に 48 相対ピクセル短くして、タスク バー用の領域を確保します。
  • サイズ変更可能なウィンドウのレイアウトを 1024 × 768 ピクセルの有効解像度に最適化します。より低い解像度の場合にも機能するように、これらのウィンドウのサイズが自動的に変更されるようにします。
  • 96 dpi (ドット/インチ) の 800 × 600 ピクセル モード、120 dpi の 1024 × 768 ピクセル モード、144 dpi の 1280 × 1024 ピクセル モードで、必ずウィンドウをテストします。コントロール、テキスト、ウィンドウなどが切り詰められていないか、アイコンやビットマップが引き伸ばされたりしていないかなど、レイアウト上の問題をチェックします。
  • タッチ PC やモバイル PC 向けシナリオのプログラムでは、120 dpi に最適化します。現在、タッチ PC やモバイル PC では高 dpi 画面が普及しています。
  • 所有されるウィンドウの初期表示は、オーナー ウィンドウ前面の "中央配置" にします。下には配置しません。その後の表示については、最後に表示された位置 (オーナー ウィンドウに対する相対的な位置) に表示する方が使用しやすいと思われる場合は、その表示方法も検討します。
  • コンテキスト ウィンドウの場合は、必ず起動元オブジェクトの近くに表示します。ただし、表示するウィンドウで起動元のオブジェクトが隠れることがないように、適切な位置に配置します (できれば右下にオフセットします)。

レイアウト

  • ウィンドウ内のコントロールや第 2 ウィンドウのサイズを標準的なコンテンツに合うように指定します。テキストの切り詰めと、切り詰めを表す省略記号の使用を回避します。標準的なコンテンツの表示には、ユーザーのウィンドウ操作が必要ないようにします。非常に大きなコンテンツを扱う場合は、サイズ変更やスクロールを使用可能にします。特に、以下の点を確認します。
    • コントロールのサイズ。コントロールのサイズを標準的なコンテンツに合うように設定し、必要に応じて、幅や高さを増やしたり、複数行にしたりします。利用できる領域が広いウィンドウでは、スクロールをなくすか、スクロール幅が縮小されるようにコントロールのサイズを設定します。また、ラベルの表示が欠けたり、利用可能な領域が広いウィンドウ内でテキストの表示が欠けたりしないようにします。ただし、テキストを読みやすくするには、行幅を 65 文字に制限するようにします。
    • 列幅。リスト ビューの列に、最適な既定のサイズ、最小サイズ、および最大サイズが表示されるようにします。特にリスト ビュー内に利用可能な領域がある場合は、テキストの表示が欠けないような列幅を既定にします。
    • レイアウトのバランス。ウィンドウのレイアウトは、左右でおよそのバランスがとれているようにします。レイアウトが左に偏る場合は、コントロールを横に広げて、一部のコントロールを右方向へ移動させるようにします。
    • レイアウトのサイズ変更。ウィンドウのサイズが変更可能で、データの表示が欠ける場合は、より多くのデータが表示されるようにウィンドウのサイズを大きくします。データが欠けていると、ユーザーは、ウィンドウのサイズを変更してより多くの情報を表示させようと考えます。
  • コンテンツが利用できなくなる下限のサイズがある場合は、ウィンドウの最小サイズを設定します。サイズ変更可能なコントロールに対しては、機能を維持できる最小サイズを設定します (リスト ビューが役目を果たすことができる最小の列幅など)。

テキスト

  • できる限り、会話で使用するような一般的な用語を使用します。テクノロジではなく、ユーザーの目的を重視します。これは、複雑な技術的概念や操作を説明する場合に、特に効果的です。ユーザーの肩越しにのぞき込み、タスクの実行方法を説明している様子を想像します。
  • ていねいに、サポートするように、また、やる気を起こさせるようにします。ユーザーが、見下され、非難され、威圧されていると感じることのないようにします。
  • 冗長なテキストは削除します。ウィンドウ タイトル、メイン指示テキスト、補足指示テキスト、コンテンツ領域、コマンド リンク、コミット ボタンに冗長なテキストがないことを確認します。通常、メイン指示テキストと対話型コントロールのテキストはそのまま残し、他の部分にある冗長なテキストを削除します。
  • タイトルにはタイトル スタイルの大文字化を、その他のすべての UI 要素にはセンテンス スタイルの大文字化を使用します。これにより、Windows® のトーンにより適したテキストになります。
    • 例外: 古いアプリケーションでは、大文字/小文字のスタイルが混在しないように、コマンド ボタン、メニュー、列見出しにタイトル スタイルの大文字化を採用することもできます。
  • 機能名やテクノロジ名については、大文字化は控えめにします。一般には、主要なコンポーネントのみを大文字化します (タイトル スタイルの大文字化を使用)。
  • 機能名およびテクノロジ名については、大文字化に一貫性を持たせます。その名前が 1 つの UI 画面に何度も出現する場合、常に同じように表示する必要があります。同様に、プログラム内のすべての UI 画面で、その名前を同じように表示する必要があります。
  • 汎用的なユーザー インターフェイス要素名は大文字で表記しません。たとえば、"toolbar (ツール バー)"、"menu (メニュー)"、"scroll bar (スクロール バー)"、"button (ボタン)"、"icon (アイコン)" などがあります。
    • 例外: アドレス バー (Address bar)、リンク バー (Links bar)、リボン (ribbon)。
  • キーボード上のキーを表すのにすべて大文字の表記は使用しません。標準キーボードで使用されている表記に従うか、ラベル表示のないキーボード キーの場合は小文字で表記します。
  • 省略記号は不完全であることを意味します。 次の UI テキストで、省略記号を使用します。
    • コマンド: コマンドに追加の情報が必要であることを示します。省略記号は、操作によって別ウィンドウが表示される場合に使用するのではなく、追加の情報が必要な場合にのみ使用します。詳細設定、ヘルプ、オプション、プロパティ、設定など、ラベルの内容によって別のウィンドウが表示されることが明らかにわかるコマンドについては、省略記号を付ける必要はありません。
    • データ: テキストの一部が表示されていないことを示します。
    • ラベル: タスクが進行中であることを示します ("検索しています..." など)。
    ヒント: ウィンドウやページに未使用の領域があるにもかかわらずテキストの切り詰めがある場合は、レイアウトに問題があるか、既定のウィンドウ サイズが小さすぎることを示しています。切り詰めを減らし、可能ならすべてのテキストを表示できるように、レイアウトや既定のウィンドウ サイズを修正してください。詳細については、「レイアウト」を参照してください。
  • リンク以外のテキストを青色にしないようにします。ユーザーがリンクと誤解する可能性があります。色付きテキストは使わずに、太字または灰色を使います。
  • 太字は、必読のテキストに注目を集めるために、控えめに使用します。
  • 表示されたウィンドウまたはページでユーザーがすべきことを簡潔に説明するために、メイン指示テキストを使用します。優れたメイン指示テキストは、単に UI 操作に注目させるだけではなく、ユーザーの目的を明確に示します。
  • メイン指示テキストは、必須の指示や具体的な質問の形式で表現します。
  • コントロール ラベルやメイン指示テキストの最後には、句点を付けません。
  • 文と文との間には、スペースを 1 つ入れます (英語の場合)。2 つ入れないようにしてください。

コントロール

  • 全般
    • すべてのコントロール、コントロールのグループにラベルを設定します。次の場合は例外です。
      • テキスト ボックスおよびドロップダウン リストには、プロンプトを使用してラベルを設定することができます。
      • 従属コントロールには、関連するコントロールのラベルを使用します。スピン コントロールは、常に従属コントロールになります。
    • すべてのコントロールの既定値は、最も安全 (データの消失やシステム アクセスが失われることを防ぐもの) で、最もセキュリティの高い値にします。安全性やセキュリティを考慮する必要がない場合は、最もよく使用される値か、最も便利な値を選択します。
    • できるだけ制約付きコントロールを使用します。テキスト入力の負担を減らすために、テキスト ボックスのような制約のないコントロールではなく、リストやスライダーといった制約付きコントロールをできる限り使用します。
    • 無効化されているコントロールは検討し直します。無効化されているコントロールがあると、ユーザーは無効化されている理由を推測しなければならないため、使用には注意が必要です。ユーザーが使用することが見込まれ、無効になっている理由を簡単に推測できる場合に、コントロールを無効化します。ユーザーが有効にできないコントロール、またはユーザーが使用することが想定されないコントロールは削除するか、有効なままにして、誤って使用された場合にエラー メッセージが表示されるようにします。
      • ヒント: コントロールを無効にするか、またはエラー メッセージを表示するかで迷った場合は、まず実際にエラー メッセージを作成してみてください。対象ユーザーが簡単に思い付かないような役立つ情報がエラー メッセージに含まれている場合は、コントロールを有効にしたままで、エラーを表示するようにします。その他の場合は、コントロールを無効にします。
  • コマンド ボタン
    • ラベルは汎用的な内容ではなく、具体的になるようにします。ラベル以外のものを読まなくてもユーザーが意味を理解できることが理想です。一般にユーザーは、静的テキストよりも、コマンド ボタンのラベルを優先的に読む傾向があります。
      • 例外: [キャンセル] ボタンのラベルは、何を取り消すのかがあいまいであっても変更しないでください。ユーザーがすべてのラベルを読まなくても、どのボタンが操作を取り消すものであるかがわかるようにするためです。ただし、保留中の処理が複数ある場合など、どの操作が取り消されるのか明確でない場合は、別のラベルを使用してかまいません。
    • 問い合わせに対する応答ボタンは、その内容に合ったラベルにしてください。たとえば、"はい" か "いいえ" で答える質問であれば、[はい]/[いいえ] ボタンを用意します。
    • プロパティ シートやコントロール パネル アイテム以外のダイアログ ボックスで、[適用] ボタンを使用しないでください。[適用] ボタンをクリックすると、保留中の変更が適用されますが、ウィンドウは開いたままになるため、ユーザーはウィンドウを閉じる前に変更内容を評価することができます。ただし、このようなプロセスを必要とするのはプロパティ シートとコントロール パネル アイテムだけです。
    • "キャンセル" というボタンのラベルは、取り消すことによって環境を以前の状態に (副次的な影響を残さず) 戻せる場合に使用します。これ以外の場合は、変更された現在の状態が維持されることを示すために、ボタンのラベルは "閉じる" (処理が完了した場合) または "停止" (処理が進行中の場合) を使用します。
  • コマンド リンク
    • コマンド リンクは常に 2 つ以上のセットで提示します。応答が 1 種類しかない質問は論理的に意味をなしません。
    • 明示的な [キャンセル] ボタンを用意します。この用途でコマンド リンクを使用しないでください。タスクを実行する必要がないと、ユーザーが途中で気付くことはかなり頻繁にあります。コマンド リンクを取り消しに使用すると、どのコマンド リンクが取り消しを意味するか判断するために、すべてのコマンド リンクをよく読む必要が生じます。[キャンセル] ボタンがあれば、ユーザーは効率よくタスクを取り消すことができます。
    • 明示的な [キャンセル] ボタンを用意するとコマンド リンクが 1 つだけになってしまう場合は、取り消すためのコマンド リンクと [キャンセル] ボタンの両方を用意します。これにより、選択肢があることがはっきりとユーザーに伝わります。このコマンド リンクでは、単に "キャンセル" またはそれに類する語句ではなく、もう一方の選択肢との対比が明らかな語句を使用します。
  • [今後、この <アイテム> を表示しない] チェック ボックス
    • "今後、この <アイテム> を表示しない" というオプションの使用を検討します。これにより、ユーザーは同じダイアログ ボックスを繰り返し表示しないように指定できます。ただし、これは他に良い手段がない場合に限ります。ユーザーが本当に必要としている場合は、ダイアログ ボックスを常に表示することをお勧めします。必要としていない場合は、単純に削除します。
    • <アイテム> を具体的なアイテムに置き換えます。たとえば、[今後、この通知を表示しない] とします。ダイアログ ボックスを指す場合は、一般的に、[今後、このメッセージを表示しない] を使用します。
    • ユーザー入力を今後の既定値として使用する場合は、その旨を明確に示します。オプションの下に、"選択内容は、今後既定値として使用されます" という文を追加します。
    • このオプションは既定でオンにしません。ダイアログ ボックスを本当に 1 回だけ表示する必要がある場合は、確認せずに 1 回だけ表示します。このオプションを追加すれば済むとは考えず、既定の動作がユーザーにとってわずらわしくならないように配慮してください。
    • ユーザーがこのオプションをオンにして [キャンセル] をクリックした場合、このオプションは "有効" になります。この設定はメタオプションであるため、副次的な影響を残さないという [キャンセル] の標準の動作には従いません。ユーザーが今後そのダイアログ ボックスを表示しないようにする場合、そのダイアログ ボックス自体もキャンセルする可能性が高いことに注意してください。
  • リンク
    • アクセス キーは割り当てません。リンクには Tab キーでアクセスできます。
    • リンク テキストに "クリック" や "ここをクリック" は追加しません。リンク自体がクリックすることを示唆しているため、こうした言葉は必要ありません。
  • ツールヒント
    • ラベルのないコントロールにラベルを付けるには、ツールヒントを使用します。一貫性を保つためだけに、ラベル付きコントロールにツールヒントを設定する必要はありません。
    • ツール バーのボタンにラベルが付けられている場合でも、有益であれば、ツールヒントで詳細を提供してもかまいません。既にラベルにある情報を繰り返したり言い直すことはしません。
    • ユーザーが確認または操作しようとするオブジェクトがヒントで隠れないようにします。ポインターとヒントが離れることになっても、ヒントは常にオブジェクトの脇に配置します。オブジェクトとヒントとの関係性が明らかである限り、多少離れても問題はありません。
      • 例外: リストやツリーで使用される、完全な名前を表示するツールヒント。
    • アイテム コレクションに対しては、次に来るオブジェクトをユーザーが確認または操作する可能性がある場合、オブジェクトが隠れないようにします。水平にアイテムが並んでいる場合は、右にヒントを配置しないようにし、垂直にアイテムが並んでいる場合は、下にヒントを配置しないようにします。
  • 段階的表示
    • ユーザーが通常は必要としない高度なオプションおよびコマンド、使用頻度の低いオプションおよびコマンド、または詳細情報を非表示にするには、詳細表示/簡易表示を切り替える段階的表示ボタンを使用します。一般的に使用される項目は非表示にしないでください。ユーザーが見つけられない可能性があります。ただし、非表示になっているものには必ず価値があるようにします。
    • 何らかのオプション、コマンド、または詳細が常に表示される場合は、以下のラベルの組み合わせを使用します。
      • オプションの詳細表示/オプションの簡易表示。オプションに、またはオプション、コマンド、詳細が混在する場合に使用します。
      • コマンドの詳細表示/コマンドの簡易表示。コマンドにのみ使用します。
      • 詳細表示/簡易表示。情報にのみ使用します。
      • <オブジェクト名> の詳細表示/<オブジェクト名> の簡易表示。フォルダーなど、上記以外のオブジェクトの種類に使用します。
    • または:
      • オプションの表示/オプションの非表示。オプションに、またはオプション、コマンド、詳細が混在する場合に使用します。
      • コマンドの表示/コマンドの非表示。コマンドにのみ使用します。
      • 詳細の表示/詳細の非表示。情報にのみ使用します。
      • <オブジェクト名> の表示/<オブジェクト名> の非表示。フォルダーなど、上記以外のオブジェクトの種類に使用します。
  • 進行状況バー
    • 処理時間の長さが有限である場合は、確定型の進行状況バーを使用します。これは、時間を正確に予測できない場合であっても同じです。不確定型の進行状況バーでは、進行中であることが示されますが、その他の情報は示されません。正確に予測できない可能性があるという理由だけで、不確定型の進行状況バーを選択しないでください。
    • 正確に推測できるのであれば、残り時間の見積もりを提供します。正確に見積もられた残り時間は有用ですが、見積もりがまったくの見当違いであったり、頻繁に大きく変わる場合は役に立ちません。正確な見積もりを提供するために、何らかの処理を実行する必要がある場合は、処理の初期段階では、不正確な可能性のある見積もりを表示しないようにします。
    • バーの進行を再開させないでください。おそらく処理の 1 つのステップが完了したという理由だと思いますが、バーの進行を最初から再開させると、進行状況バーの価値は失われます。これでは、ユーザーは処理がいつ完了するのかわかりません。代わりに、処理内のすべてのステップで進行状況を分割し、進行状況バーを 1 回で完了させます。
    • 有用な進行状況の詳細を提供します。進行状況の追加情報を提供します。ただし、ユーザーがその情報に基づく何らかの作業を行うことができる場合に限ります。テキストは、ユーザーが読むのに十分な時間、表示されるようにします。
    • 進行状況バーとビジー ポインターを組み合わせて使用しません。どちらかのみを使用し、両方を同時に使用しないでください。
  • プロンプト
    • テキスト ボックスがツール バーのような特別な領域にあり、ラベルや指示がない方が良い場合は、プロンプトを使用します。
    • プロンプトは、テキスト ボックスまたはコンボ ボックスの目的を省スペースで示す場合に、主に使用します。コントロールの使用中にユーザーが確認する必要のある重要な情報は、プロンプトでは示しません。
    • プロンプト テキストと実際に入力されたテキストが混同されないようにします。 そのためには、次のことに留意します。
      • プロンプト テキストは灰色で表示し、実際に入力されたテキストは通常の黒色で表示します。
      • プロンプト テキストは編集可能にしません。ユーザーがテキスト ボックス内をクリックしたり、Tab キーでテキスト ボックスに移動したら、画面からプロンプト テキストを消去します。
        • 例外: テキスト ボックスに既定で入力フォーカスがある場合は、プロンプトを表示し、ユーザーが入力を開始したときに画面から消去します。
    • 末尾に句読点や省略記号は付けません。
  • 通知
    • 通知は、現在のユーザー操作に無関係で、ユーザーがすばやく対応する必要がなく、無視してもかまわないイベントに対して使用します。
    • 通知を乱用しないでください。
      • 通知は、必要な場合に限って使用します。通知を表示すると、ユーザーの作業を中断したり、ユーザーに不快感を与えたりする可能性があります。正当な理由で中断が行われるようにします。
      • 通知は、ユーザーがすばやく対応する必要がない、重大ではないイベントまたは状況に使用します。ユーザーがすばやく対応する必要のある重大なイベントまたは状況の場合は、他の UI 要素 (モーダル ダイアログ ボックスなど) を使用します。
      • 機能の告知に通知を使用しないでください。

キーボード

  • ユーザーが最初に操作する可能性の高いコントロールに最初の入力フォーカスを割り当てます。多くの場合、最初の対話型コントロールに割り当てます。最初の対話型コントロールが適していない場合、ウィンドウのレイアウトを変更することを検討します。
  • 読み取り専用の編集ボックスを含む、すべての対話型コントロールにタブ ストップを割り当てます。次の場合は例外です。
    • 1 つのコントロールとして動作する、関連するコントロールのグループ (ラジオ ボタンなど)。このようなグループには 1 つのタブ ストップが割り当てられます。
    • 方向キーでグループ内を前後に移動したときに、フォーカスがグループ内から外に出ないように、グループを適切に設定します。
  • タブ オーダーは左から右、上から下の順序にします。一般的に、タブ オーダーは読む順序と同じにします。よく使用するコントロールは、例外的にタブ オーダーの早い方に設定することを検討します。Tab キーでは、止まることなく両方向に、すべてのタブ ストップを循環するようにします。グループ内では、タブ オーダーに例外を設けず、順番どおりにします。
  • タブ ストップ内では、方向キーは、左から右、上から下へ移動するようにします。例外は設けません。方向キーでは、止まることなく両方向に、すべてのアイテムを循環するようにします。
  • 次の順番でコミット ボタンを配置します。
    • [OK]/"実行する"/[はい]
    • "実行しない"/[いいえ]
    • [キャンセル]
    • [適用] (該当する場合)
    "実行する" および "実行しない" には、メイン指示テキストに対する具体的な応答が入ります。
  • アクセス キーとショートカット キーを混同しないでください。アクセス キーとショートカット キーは両方ともキーボードで UI にアクセスできますが、それぞれ異なる目的とガイドラインがあります。
  • 可能な限り、すべての対話型コントロールまたはそのラベルに一意のアクセス キーを割り当てます。 読み取り専用のテキスト ボックスは対話型コントロールである (ユーザーがスクロールし、テキストをコピーできる) ため、アクセス キーを割り当てるメリットがあります。以下には、アクセス キーを割り当てないでください。
    • [OK]、[キャンセル] および [閉じる] の各ボタン。Enter キーおよび Esc キーが、それぞれのボタンのアクセス キーに使用されています。ただし、"OK" または "キャンセル" を意味する異なるラベルのコントロールには、アクセス キーを常に割り当てます。
  • ショートカット キーを最もよく使用するコマンドに割り当てます。使用頻度の低いプログラムや機能の場合、代わりにアクセス キーが使用されるので、ショートカット キーは必要ありません。
  • ショートカット キーがタスクを実行する唯一の方法にならないようにします。マウスやキーボードの Tab キー、方向キー、アクセス キーも使用できるようにする必要があります。
  • よく知られているショートカット キーに別の機能を割り当てないようにします。よく知られているショートカット キーはユーザーに記憶されているので、機能に一貫性がないと、ストレスやエラーの原因になります。Windows プログラムで使用され、よく知られているショートカット キーについては、「Windows のキーボード ショートカット キー」を参照してください。
  • システム全体に作用するショートカット キーをプログラムに割り当てないようにします。プログラムのショートカット キーは、プログラムに入力フォーカスがある場合にのみ効果を発揮します。

マウス

  • オブジェクトがクリック可能かどうかを判断するために、ユーザーが実際にクリックしなくても済むようにします。オブジェクトを見ただけで、クリックできるかどうかが判断できるようにします。
    • プライマリ UI (コミット ボタンなど) には、静的なクリック アフォーダンスを設定します。ユーザーは、プライマリ UI を判断するのにマウス ポインターを合わせる必要がなくなります。
    • セカンダリ UI (副コマンドや段階的表示コントロールなど) では、ポイント時にクリック アフォーダンスを表示できます。
    • テキスト リンクでは、リンク テキストを静的に示唆し、マウス ポインターを合わせるとクリック アフォーダンス (ポインターを手の形に変更し、下線やその他の表示を変更する) を表示するようにします。
    • グラフィック リンクでは、ポイント時に手の形のポインターを表示するだけにします。
  • 手の形の (または "リンク選択" の) ポインターは、テキスト リンクおよびグラフィック リンクに対してのみ使用します。このようにしないと、ユーザーはオブジェクトがリンクであるかどうかを判断するために実際にクリックしてみなければならなくなります。

ダイアログ ボックス

  • モーダル ダイアログ ボックスは対話操作を要求するため、ユーザーがタスクを続行する前に応答する必要があるタスクに使用します。作業を続行する前に完了させる必要がある、重要または頻度が低い、1 回限りのタスクなど、正当な理由で中断が行われるようにします。それ以外のタスクでは、モードレス ダイアログ ボックスの使用を検討します。
  • モードレス ダイアログ ボックスは対話操作を要求しないため、ダイアログ ボックスとオーナー ウィンドウを切り替える必要がある場合に使用します。モードレス ダイアログ ボックスは、頻度が高く、繰り返し発生する、継続的なタスクに最も適しています。ただし、リボン、ツール バー、およびパレット ウィンドウの方が適切な方法であることもよくあります。

プロパティ シート

  • プロパティの必要性を確認します。デザイン上の難しい判断を回避するためだけに、プロパティ ページに不要なプロパティを詰め込まないようにしてください。
  • テクノロジではなく、ユーザーの目的という観点からプロパティを表示します。プロパティは特定のテクノロジを構成するためのものですが、だからといって、そのテクノロジの観点からプロパティを表示する必要はありません。
    • テクノロジの観点から設定を表示する必要がある場合 (ユーザーがテクノロジの名前を把握している場合など) は、ユーザーの利点を簡潔に説明するテキストを追加してください。
  • 具体的で意味のあるタブ ラベルを使用します。"全般"、"詳細設定"、"設定" など、どのタブにも当てはまるような汎用的なタブ ラベルの使用は避けます。
  • [全般] ページはできるだけ使用しないようにします。[全般] ページは、必ずしも必要ではありません。[全般] ページは次の場合にのみ使用します。
    • プロパティが複数のタスクに適用され、ほとんどのユーザーに対して重要な場合。[全般] ページには、特殊なプロパティや詳細なプロパティを配置しません。ただし、[全般] ページのコマンド ボタンを通じてこれらにアクセスできるようにすることが可能です。
    • プロパティをより具体的なカテゴリに分けられない場合。カテゴリに分けられる場合は、その名前をページに使用します。
  • [詳細設定] ページはできるだけ使用しないようにします。 [詳細設定] ページは次の場合にのみ使用します。
    • プロパティが一般的ではないタスクに適用され、主に詳しい知識のあるユーザーにとって重要な場合。
    • プロパティをより具体的なカテゴリに分けられない場合。カテゴリに分けられる場合は、その名前をページに使用します。
  • プロパティ ウィンドウにタブが 1 つしかなく、拡張不可能である場合は、タブは使用しません。代わりに、[OK] ボタン、[キャンセル] ボタン、そして場合によっては [適用] ボタンを持つ通常のダイアログ ボックスを使用します。ただし、拡張可能なプロパティ ウィンドウ (サード パーティによる拡張が可能なウィンドウ) の場合は、必ずタブを使用する必要があります。

ウィザード

  • 最初は、ダイアログ ボックス、作業ウィンドウ、単一ページなどの軽量コントロールについて検討します。ウィザードは重い UI であり、複数の手順から成る、実行頻度の低いタスクに最も適しています。ウィザードは必ずしも使用する必要はありません。役立つ情報やヘルプはどんな UI でも提供できます。
  • [次へ] は、未確定のまま次のページに移動する場合にのみ使用します。[戻る] や [キャンセル] をクリックして結果を元に戻せない場合、次のページに進むことは確定と見なされます。
  • [戻る] は、間違いを修正する場合にのみ使用します。間違いの修正以外では、タスクを進めるために [戻る] をクリックすることをユーザーに要求しないようにします。
  • タスクを確定する場合、メイン指示テキストに対する具体的な応答であるコミット ボタン ([印刷]、[接続]、[開始] など) を使用します。タスクの確定に、確定を意味しない [次へ] や、具体的ではない [完了] などの汎用的なラベルを使用しないでください。コミット ボタンのラベルは、単独で意味のわかる名前にする必要があります。コミット ボタンのラベルは常に動詞から始めます (英語の場合)。次の場合は例外です。
    • "具体的な応答" が [保存]、[選択]、[取得] などの汎用的な文言になる場合は、[完了] を使用します。
    • 具体的な設定/設定群を変更する場合は、[完了] を使用します。
  • コマンド リンクは、確定ではなく選択する場合にのみ使用します。具体的なコミット ボタンは、ウィザードのコマンド リンクに比べて、確定する行為であるということをより明確に示すことができます。
  • コマンド リンクを使用している場合、[次へ] ボタンは非表示にしますが、[キャンセル] ボタンはそのまま表示します。
  • [閉じる] は、フォローアップ ページや完了ページで使用します。ウィンドウを閉じても、この時点までに行われた変更や操作は破棄されないため、[キャンセル] は使用しません。[完了 (Done)] は命令形の動詞ではないため、使用しません。
  • ウィザード名において "ウィザード" は使用しません。たとえば、"ネットワーク セットアップ ウィザード" ではなく "ネットワークへの接続" を使用します。ただし、ウィザードに言及する際にはウィザードと表現することができます。たとえば、"最初にネットワークをセットアップする際に、ネットワークへの接続ウィザードを使用することができます" という表現が可能です。
  • ナビゲーション中にユーザーの選択を保持します。たとえば、ユーザーが変更を行い、[戻る] をクリックしてから [次へ] をクリックした場合、これらの変更を保持するようにします。明示的に変更を取り消していない限り、ユーザーは変更を再入力する必要があるとは想定していません。

ウィザード ページ

  • 効率的な意思決定を重視します。ページ数を減らして、重要なものだけを表示します。関連ページをまとめて、省略可能なページはメイン フローから外します。最初は、ユーザーがウィザードを最後まで [次へ] をクリックして完了できることが効果的なエクスペリエンスのように思われますが、ユーザーが既定値を変更する必要がまったくない場合、そうしたページは不要である可能性があります。
  • ウェルカム ページは使用しません。可能な限り、最初のページを機能的なものにします。 省略可能な "作業の開始" ページは、次の場合にのみ使用します。
    • ウィザードを正常に完了させるために必要な前提条件がある。
    • 最初の選択ページの説明では、ユーザーがウィザードの目的を十分理解できない可能性があるが、詳細を表示する場所がない。
    • "作業の開始" ページのメイン指示テキストが、"開始する前に" である。
  • ユーザーの選択を必要とするページは、最も可能性の高い選択肢に最適化します。このようなページでは、指示だけではなく実際の選択肢を提示します。
    • "作業の開始" ページを使用しない場合は、最初の選択ページの上部でウィザードの目的を説明します。
  • コミット ページは、ユーザーがタスクを確定するタイミングを明らかにするために使用します。通常、コミット ページは最後の選択ページとなり、確定するタスクを示すものに [次へ] ボタンのラベルを変更します。
    • タスクがリスクを伴うものである場合 (セキュリティ関連である、時間やコストがかかるなど) や、ユーザーが自分の選択について理解していない可能性があり、確認する必要がある場合を除き、ユーザーのこれまでの選択を単に要約するような "概要" ページは使用しません。
  • ウィザードを終了する以外に目的のない設定完了ページは使用しません。ウィザードの結果がユーザーにとって明らかである場合、最後のコミット ボタンでウィザードを終了するようにします。
    • フォローアップ ページは、ユーザーがフォローアップとして実行する可能性のある関連タスクがある場合に使用します。"電子メール メッセージを送信する" などの一般的なフォローアップ タスクは行いません。
    • "完了" ページは、結果が目に見えず、タスクが完了したというフィードバックを提供する方法が他にない場合にのみ使用します。
    • 進行状況ページが含まれているウィザードでは、タスクが完了したことを示すために、"完了" ページかフォローアップ ページを使用する必要があります。時間がかかるタスクの場合、コミット ページでウィザードを終了し、通知を使用してフィードバックを返します。

エラー メッセージ

  • ユーザーがメッセージの結果に応じて、何らかの対処をするか、自分の操作を見直す可能性がない場合は、エラー メッセージを表示しません。ユーザーが実行できる対処法がなかったり、問題がそれほど重要でない場合は、エラー メッセージを表示しないようにします。
  • ユーザーが問題を解決できるように、可能な限り解決策を提案します。ただし、解決の見込みが十分にある解決策を示すようにしてください。解決につながる見込みの低い、憶測だけの情報でユーザーに無駄な時間をとらせないようにします。
  • 具体的にします。"構文エラー" や "無効な操作" など、あいまいな表現を避けます。関連するオブジェクトの名称、場所、値などを具体的に提示します。
  • ユーザーを責めるような、またはユーザーに非があることを示唆するような言い回しは避けます。"あなた" という表現は使わないようにします。一般には能動態が好まれますが、ユーザーを主語にすることでエラーの責任がユーザーにあるかのように感じさせてしまう可能性がある場合は受動態を使用します。
  • エラー メッセージに [OK] は使用しません。ユーザーはエラーを OK であるとは見なしません。エラー メッセージに直接的な操作が示されていない場合、代わりに [閉じる] を使用します。
  • 次の言葉は使用しないでください。
    • エラー、障害 (代わりに "問題" を使用)
    • 失敗しました (代わりに "できません" を使用)
    • 不正な、無効な、悪い (代わりに "正しくありません" を使用)
    • 中止、キル、強制終了 (代わりに "停止" を使用)
    • 壊滅的な (代わりに "重大な" を使用)
    以上に挙げた言葉は不要であり、推奨される Windows のトーンに反するものです。代わりに、エラー アイコンを正しく使用すれば、問題の発生を効果的に伝えることができます。
  • エラー メッセージに効果音は使用しないでください。耳障りになることが多く、必要性もありません。

警告メッセージ

  • 警告は、今後問題を引き起こす可能性のある状態を示します。警告はエラーや質問ではないため、日常的な操作に対する質問を警告として使用しないでください。
  • ユーザーがメッセージの結果に応じて、何らかの対処をするか、自分の操作を見直す可能性がない場合は、警告メッセージを表示しません。ユーザーが実行できる対処法がなかったり、条件がそれほど重要でない場合は、エラー メッセージを表示しないようにします。

確認

  • 不要な確認は使用しません。 確認は、次の場合にのみ使用します。
    • 継続しない明確な理由があり、ユーザーが継続しない可能性が十分にある。
    • 操作が重大な結果をもたらすか、簡単に元に戻すことができない。
    • 操作によって生じる結果を、ユーザーが認識していない可能性がある。
    • 選択肢の中に既定として適切なものがなく、操作の続行にはユーザーの選択が必要である。
    • 現在のコンテキストで、ユーザーがエラーになる操作を実行する可能性がある。
  • 確認は、"はい" か "いいえ" で答える質問にし、"はい" か "いいえ" で答えられるようにします。他の種類のダイアログ ボックスとは異なり、確認は、ユーザーがすばやく決定を下せないようにデザインされています。ユーザーが応答内容について考えなければ、確認の意味がありません。

アイコン

  • すべてのアイコンが Aero style アイコンのガイドラインに準拠するようにします。Windows XP スタイルのアイコンはすべて置き換えます。
  • 標準アイコンを選択する際には、その問題の重要度ではなく、メッセージの種類を基準にします。
    • エラー。発生したエラーまたは問題を示します。
    • 警告。今後問題を引き起こす可能性のある状態を示します。
    • 情報。有益な情報を示します。
    問題が複数のメッセージの種類に該当する場合は、ユーザーが対処する必要のある最も重要な側面に焦点を当てます。
  • アイコンは、メイン指示テキストまたはその他の対応するテキストと常に一致する必要があります。
  • 重大ではないユーザー入力の問題にエラー アイコンは必要ありません。ただし、インプレース エラーにはアイコンが必要です。このようなコンテキストでのフィードバックは、アイコンがなければ容易に見過ごされてしまいます。
  • 重大ではないエラーを "やわらかく伝える" 目的では、警告アイコンは使用しません。エラーは警告ではありません。エラー アイコンのガイドラインに従ってください。
  • 質問のダイアログ ボックスでは、重大な結果を伴う質問に対してのみ警告アイコンを使用します。日常的な操作に対する質問には警告アイコンを使用しません。

ヘルプ

  • 具体的で意味のあるヘルプ トピックにリンクします。ヘルプのホーム ページ、目次、検索結果の一覧、または他のページにリンクしているだけのページにはリンクしません。よく寄せられる質問の膨大な一覧で構成されたページにはリンクさせないでください。こうすると、クリックしたリンクに合致する項目をユーザーに探させることになります。具体的であっても、作業中のタスクに関連がなく、役に立たないヘルプ トピックにはリンクしません。空のページにはリンクしないでください。
  • 一貫性を持たせる目的で、すべてのウィンドウやページにヘルプ リンクを配置することは避けます。1 か所にヘルプ リンクを配置したからといって、すべての場所に配置しなければならないわけではありません。
  • 可能であれば常に、ヘルプ リンク テキストは、メインの質問に対してヘルプ コンテンツが回答を提供するような表現にします。"詳細情報の表示 (Learn more about)" や "ヘルプの表示 (Get help with this)" という表現は使用しません。
  • キーワードだけでなく、ヘルプ リンク全体をリンク テキストに使用します。
  • 完全な文を使用します。
  • 疑問符を除いて、末尾に句読点や省略記号は付けません。
  • ヘルプ コンテンツがオンライン上にある場合は、そのことをリンク テキストに明記します。そうすることによって、リンクの結果が予測しやすくなります。
表示: