次の方法で共有

デスクトップ アプリケーションの UX チェックリスト

Note

この設計ガイドは Windows 7 用に作成されたものであり、新しいバージョンの Windows 用には更新されていません。 ガイダンスの多くは引き続き原則として適用されますが、プレゼンテーションと例には現在の設計ガイダンスは反映されていません。

UX ガイドの重要なガイドラインの一部を以下に示します。 これをチェックリストとして使用し、プログラムのユーザー インターフェイスにこれらの重要な項目が正しく用意されていることを確認できます。

Windows

  • Windows の最小有効解像度である 800 x 600 ピクセルをサポートします。 セーフ モードで動作する必要がある重要なユーザー インターフェイス (UI) については、640 x 480 ピクセルの有効解像度をサポートします。 タスク バーで使用されるスペースを考慮に入れ、タスク バーと共に表示されるウィンドウ用に 48 垂直相対ピクセルを確保してください。
  • サイズ変更可能なウィンドウ レイアウトを最適化し、1024 x 768 ピクセルの有効解像度を実現します。 画面解像度が低い場合でも、機能を維持したままこれらのウィンドウのサイズを自動的に変更します。
  • 必ず、96 ドット/インチ (dpi) (800 x 600 ピクセル)、120 dpi (1024 x 768 ピクセル)、144 dpi (1200 x 900 ピクセル) モードでテストしてください。 コントロール、テキスト、ウィンドウのクリッピング、アイコンとビットマップのストレッチなどのレイアウトの問題を確認してください。
  • タッチおよびモバイル使用シナリオのプログラムの場合、120 dpi に最適化します。 現在、タッチ PC やモバイル PC では高 dpi 画面が普及しています。
  • ウィンドウが所有ウィンドウである場合、最初はそれを所有者ウィンドウ上部の "中央" に表示します。 下には表示しないでください。 後続の表示については、そのほうが便利であると思われる場合は、最後に表示された場所 (オーナー ウィンドウに対する相対位置) に表示することを検討してください。
  • ウィンドウがコンテキスト依存である場合、常にそのウィンドウが起動されたオブジェクトの近くに表示します。 ただし、オブジェクトがウィンドウに隠れないよう、邪魔にならない場所 (できれば下と右にオフセット) に配置します。

レイアウト

  • ウィンドウ内のコントロールとペインのサイズは、通常のコンテンツに合わせて変更します。 テキストの切り捨てやそれに伴う省略記号を避けてください。 ユーザーが通常のコンテンツを表示するためにウィンドウを操作する必要がないようにしてください。サイズ変更とスクロールは、異常に大きなコンテンツの場合のみに使用してください。 具体的には、以下のことを確認します。
    • コントロールのサイズ。 コントロールを通常のコンテンツに合わせてサイズ調整し、必要に応じてコントロールの幅を広げたり、高さを高くしたり、複数行にしたりします。 十分なスペースがあるウィンドウでのスクロールを排除または削減するためのサイズ コントロール。 また、十分なスペースがあるウィンドウ内では、ラベルが切り捨てられたり、テキストが切り捨てられたりしてはなりません。 ただし、テキストを読みやすくするため、行幅を 65 文字に制限することを検討してください。
    • 列の幅。 リスト ビューの列の既定値、最小サイズ、最大サイズが適切であることを確認します。 特にリスト ビュー内に使用可能なスペースがある場合、テキストが切り捨てられないリスト ビューの既定の列幅を選択します。
    • レイアウトのバランス。 ウィンドウのレイアウトは、ほぼバランスが取れている必要があります。 レイアウトが左に偏っているように感じる場合、コントロールの幅を広げ、一部のコントロールを右に移動することを検討してください。
    • レイアウトのサイズ設定。 ウィンドウのサイズを変更でき、データが切り捨てられる場合、ウィンドウ サイズを大きくすると、より多くのデータが表示されるようにしてください。 データが切り捨てられると、ユーザーはウィンドウのサイズを変更することでより多くの情報が表示されることを期待します。
  • コンテンツが使用できなくなるサイズがある場合、最小ウィンドウ サイズを設定します。 サイズ変更可能なコントロールの場合、リスト ビューの最小機能列幅など、最小のサイズ変更可能な要素サイズを最小の機能サイズに設定します。

テキスト

  • 可能な場合、通常の会話に使用する用語を使用します。 テクノロジではなく、ユーザーの目標に焦点を当てます。 これは、複雑な技術的概念やアクションを説明する場合は特に効果的です。 ユーザーの肩越しに見て、タスクを達成する方法を説明する自分を想像してください。
  • 礼儀正しく、支える態度で、励ましてください。 決してユーザーが見下されたり、非難されたり、脅されたりしていると感じてはいけません。
  • 冗長なテキストを削除します。 ウィンドウのタイトル、主な指示、補足指示、コンテンツ領域、コマンド リンク、コミット ボタンで冗長なテキストを探します。 通常、主な指示と対話型コントロールに完全なテキストを残し、他の場所から冗長なテキストを削除します。
  • タイトルにはタイトル スタイルの大文字/小文字を使用し、他のすべての UI 要素には文スタイルの大文字/小文字を使用します。 このようにすると、Windows のトーンによりふさわしくなります。
    • 例外: 従来のアプリケーションについては、大文字化のスタイルの混在を避けるために必要な場合、コマンド ボタン、メニュー、列見出しにタイトル スタイルの大文字化を使用してもかまいません。
  • 機能とテクノロジの名前については、大文字化は控えめにしてください。 通常、主要なコンポーネントのみを大文字化する必要があります (タイトル スタイルの大文字化を使用)。
  • 機能とテクノロジの名前については、大文字化に一貫性を持たせてください。 名前が UI 画面に複数回表示される場合は、常に同じように表示する必要があります。 同様に、プログラム内のすべての UI 画面で、名前の表示に一貫性を持たせる必要があります。
  • ツール バー、メニュー、スクロール バー、ボタン、アイコンなどの一般的なユーザー インターフェイス要素の名前を大文字にしないでください。
    • 例外: アドレス バー、リンク バー、リボン。
  • キーボード キーをすべて大文字にしないでください。 そうではなく、標準キーボードで使用されている大文字化に従うか、キーボードにキーのラベルが付いてない場合は小文字にしてください。
  • 省略記号は不完全であることを意味します。 UI テキストで省略記号を次のように使用します。
    • コマンド。 コマンドに追加情報が必要であることを示します。 アクションによって別のウィンドウが表示される場合は省略記号を使用しないでください。省略記号は追加情報が必要な場合のみ使用してください。 暗黙の動詞によって別のウィンドウを表示するコマンドには、省略記号は必要ありません (例: 詳細、ヘルプ、オプション、プロパティ、設定)。
    • データ。 テキストが切り捨てられていることを示します。
    • ラベル。 タスクが進行中であることを示します (例: "検索中...")。

ヒント: スペースが使用されていないのにウィンドウまたはページでテキストが切り捨てられる場合は、レイアウトが悪いか、既定のウィンドウ サイズが小さすぎることを示しています。 切り捨てられるテキストがなくなるか、その量が削減されるレイアウトと既定のウィンドウ サイズになるように努めます。 詳細については、「Layout」 (レイアウト) を参照してください。

  • リンク以外に青いテキストは使用しないでください。これは、ユーザーがリンクであると見なす可能性があるためです。 通常は色付きのテキストを使用するところを太字またはグレーのテキストにします。
  • ユーザーが読む必要があるテキストに注意を引くため、太字を控えめに使用します。
  • 主な指示は、特定のウィンドウまたはページでユーザーが行う内容を簡潔に説明するために使用します。 適切な主な指示は、UI の操作だけに焦点をあてるのではなく、ユーザーの目的を伝えます。
  • 主な指示は、必須の指図や具体的な質問の形式で表します。
  • コントロール ラベルまたはメイン手順の末尾にピリオドを配置しないでください。
  • 文の間にはスペースを 1 つ使用します。 ふたつではありません。

コントロール

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

[キーボード]

  • ユーザーが最初に操作する可能性が最も高いコントロールに初期入力フォーカスを割り当てます。これは多くの場合、最初の対話型コントロールです。 最初の対話型コントロールが適切でない場合、ウィンドウのレイアウトを変更することを検討してください。
  • 読み取り専用編集ボックスを含むすべてのインタラクティブ コントロールにタブ ストップを割り当てます。 例外:
    • ラジオ ボタンなど、1 つのコントロールとして動作する関連するコントロールのセットをグループ化します。 このようなグループにはタブ ストップが 1 つあります。
    • グループを適切に含めることにより、矢印キーでグループ内を前後に移動し、グループ内に留まります。
  • タブ オーダーは左から右、上から下になります。 通常、タブ オーダーは読み取り順序に従う必要があります。 よく使用されるコントロールについては、タブ オーダーの前の方に配置して例外を設けることを検討してください。 タブは停止することなく、両方向のすべてのタブ ストップを循環します。 グループ内では、タブ オーダーは例外なく順番にする必要があります。
  • タブ ストップ内では、矢印キーの順序は例外なく左から右、上から下へ流れる必要があります。 方向キーで停止せずに、両方向にすべての項目を切り替えられるべきです。
  • コミット ボタンを次の順序で表示します。
    • [OK]/[実行する]/[はい]
    • [実行しない]/[いいえ]
    • キャンセル
    • 適用（ある場合）

ここで、[すべきこと] と [すべきでないこと] は、メインの指示に対する具体的な応答です。

  • アクセス キーとショートカット キーを混同しないでください。 アクセス キーとショートカット キーはどちらも UI へのキーボード アクセスを提供しますが、目的とガイドラインが異なります。
  • 可能な限り、すべての対話型コントロールまたはそのラベルに一意のアクセス キーを割り当てます。読み取り専用テキスト ボックスは対話型コントロールであるため (ユーザーがスクロールしたりテキストをコピーしたりできるため)、アクセス キーを活用できます。 以下にはアクセス キーを割り当てないでください。
    • [OK] ボタン、[キャンセル] ボタン、[閉じる] ボタン。 これらのアクセス キーには Enter キーと Esc キーが使用されます。 ただし、[OK] または [キャンセル] を意味するものの、ラベルが異なるコントロールには、必ずアクセス キーを割り当ててください。
  • 最もよく使用されるコマンドにショートカット キーを割り当てます。 使用頻度の低いプログラムや機能では、ユーザーが代わりにアクセス キーを使用できるため、ショートカット キーは必要ありません。
  • タスクを実行する唯一の方法としてショートカット キーを作成しないでください。 さらに、ユーザーは、Tab キー、方向キー、アクセス キーでマウスまたはキーボードを使用できる必要があります。
  • 既知のショートカット キーに異なる意味を割り当てないでください。 よく知られているショートカットは暗記されているため、意味が一貫していないとイライラしたり、エラーが発生しやすくなります。
  • システム全体のプログラム ショートカット キーを割り当てないでください。 プログラムのショートカット キーは、プログラムに入力フォーカスがある場合のみ有効です。

マウス

  • クリック可能かどうかを判断するために、ユーザーにオブジェクトのクリックを求めないでください。 ユーザーは視覚的な検査だけでクリック可能かどうかを判断できる必要があります。
    • プライマリ UI (コミット ボタンなど) には、静的なクリック アフォーダンスが必要です。 プライマリ UI を見つけるため、ユーザーがカーソルを合わせなくてもよいようにしてください。
    • セカンダリ UI (セカンダリ コマンドやプログレッシブ開示コントロールなど) は、カーソルを合わせたときにクリック アフォーダンスを表示できます。
    • テキスト リンクはリンク テキストを静的に提案し、カーソルを合わせるクリック アフォーダンス (下線またはその他の表示の変更、ハンド ポインター) を表示します。
    • グラフィックス リンクでは、カーソルを合わせたときのみ手のポインターが表示されます。
  • テキストおよびグラフィック リンクにのみ、手 (つまり "リンク選択") のポインターを使用します。 それ以外の場合、ユーザーはオブジェクトをクリックして、リンクであるかどうかを判断する必要があります。

ダイアログ ボックス

  • モーダル ダイアログ ボックスは対話を必要とするため、タスクを続行する前にユーザーが応答する必要がある操作に使用してください。 完了する必要のある重要なタスクや、頻度の低い 1 回限りのタスクなど、中断が正当なものであることを確認してください。 それ以外の場合は、モードレスの代替手段を検討してください。
  • モードレス ダイアログ ボックスは対話を必要としないため、ユーザーがダイアログ ボックスと所有者ウィンドウを切り替える必要がある場合に使用してください。 頻繁に実行されるタスク、反復的なタスク、または継続的なタスクに最適です。 ただし、多くの場合、リボン、ツール バー、パレット ウィンドウの方が適しています。

プロパティ シート

  • プロパティが本当に必要かどうかを確認してください。 難しいデザイン上の決定を避けるためだけに、プロパティ ページを不要なプロパティによって乱雑にしないでください。
  • テクノロジではなく、ユーザーの目標の観点でプロパティを表示します。 プロパティが特定のテクノロジを構成するからといって、そのテクノロジに基づいてプロパティを表示しなければならないわけではありません。
    • 設定をテクノロジの観点から提示する必要がある場合 (ユーザーがテクノロジの名前を認識している場合など)、ユーザーにとっての利点について簡単な説明を含めてください。
  • 具体的でわかりやすいタブ ラベルを使用してください。 [全般]、[詳細]、[設定] など、任意のタブに適用できる汎用なタブ ラベルは使用しないでください。
  • [全般] ページは使用しないでください。 [全般] ページは必ずしも必要ありません。 [全般] ページは、次の場合のみ使用します。
    • プロパティがいくつかのタスクに適用され、ほとんどのユーザーにとって意味がある。 特殊なプロパティや高度なプロパティを [全般] ページに配置しないでください。ただし、[全般] ページのコマンド ボタンからアクセスできるようにすることができます。
    • プロパティがより具体的なカテゴリに適合しない。 その場合、代わりにその名前をページに使用します。
  • 詳細ページは使用しないでください。 詳細設定ページは、次のような場合にのみ使用してください。
    • プロパティが一般的でないタスクに適用され、主に上級ユーザーにとって意味がある。
    • プロパティがより具体的なカテゴリに適合しない。 その場合、代わりにその名前をページに使用します。
  • プロパティ ウィンドウにタブが 1 つだけあり、拡張可能でない場合、タブを使用しないでください。 [OK]、[キャンセル]、オプションの [適用] ボタンを含む、通常のダイアログ ボックスを使用します。 ただし、拡張可能なプロパティ ウィンドウ (サード パーティが拡張できる) では、タブを使用する必要があります。

ウィザード

  • 最初に、ダイアログ ボックス、作業ウィンドウ、単一ページなどの軽量の代替手段を検討してください。 ウィザードは重い UI であり、複数ステップで実行される頻度の低いタスクに最適です。 ウィザードを使用する必要はありません。任意の UI で役立つ情報やサポートを提供できます。
  • [次へ] は、コミットメントなしで次のページに進む場合のみ使用します。 次のページに進むと [戻る] または [キャンセル] をクリックして効果を元に戻すことができない場合、コミットメントと見なされます。
  • 間違いを修正する場合のみ、[戻る] を使用してください。 間違いを修正する以外に、タスクを進めるためにユーザーが [戻る] をクリックする必要があってはなりません。
  • ユーザーがタスクにコミットする場合、メインの指示に対する特定の応答であるコミット ボタン (印刷、接続、開始など) を使用します。 タスクをコミットする際、[次へ] (コミットメントを意味しない) や [完了] (具体的ではない) などの一般的すぎるラベルを使用しないでください。 これらのコミット ボタンのラベルは、独自の意味を持っている必要があります。 コミット ボタンのラベルは常に動詞で始めてください。 例外:
    • 特定の応答が "保存"、"選択"、"選ぶ”、"取得"などの一般的なものである場合、[完了] を使用します。
    • 特定の設定または設定のコレクションを変更するには、[完了] を使用します。
  • コマンド リンクは、コミットメントではなく、選択肢にのみ使用します。 特定のコミット ボタンは、ウィザードのコマンド リンクよりもはるかにコミットメントが優れていることを示しています。
  • コマンド リンクを使用する場合は、[次へ] ボタンを非表示にしますが、[キャンセル] ボタンはそのままにします。
  • フォローアップ ページと完了ページには [閉じる] を使用します。 ウィンドウを閉じても、この時点で行われた変更やアクションは破棄されないため、[キャンセル] は使用しないでください。 [完了] は命令動詞ではないため、使用しないでください。
  • ウィザード名に "ウィザード" を使用しないでください。 たとえば、"ネットワーク セットアップ ウィザード" ではなく "ネットワークに接続" を使用します。ただし、ウィザードをウィザードと呼ぶことは許容されます。 例: "初めてネットワークを設定する場合、ネットワークへの接続ウィザードを使用してヘルプを参照できます。"
  • ナビゲーションを使用してユーザーの選択を保持します。 たとえば、ユーザーが変更を加え、[戻る] をクリックし、[次へ] をクリックした場合、それらの変更を保持する必要があります。 ユーザーは、明示的に変更をクリアすることを選択しない限り、変更を再入力する必要があるとは予想しません。

ウィザード ページ

  • 効率的な意思決定に重点を置いてください。 ページ数を減らして、重要なことに重点を置きます。 関連するページを統合し、オプションのページをメイン フローから除外してください。 ユーザーがウィザードの最後まで [次へ] をクリックするのは、最初は良いエクスペリエンスのように思えるかもしれませんが、ユーザーが既定値を変更する必要がない場合、そのページはおそらく不要です。
  • ウェルカム ページは使用しないでください。可能な限り、最初のページを機能的なものにしてください。 オプションの "はじめに" ページは、次の場合のみ使用します。
    • ウィザードに、ウィザードを正常に完了するために必要な前提条件がある。
    • ユーザーは、最初の選択ページだけではウィザードの目的を理解できない可能性があり、さらに説明する余地はない。
    • "はじめに" ページのメイン指示は "開始する前に:" です。
  • ユーザーが選択を求められるページでは、最も可能性の高いケースに合わせて最適化します。 こうした種類のページでは、指示だけでなく実際の選択肢も提示する必要があります。
    • "はじめに" ページを使用しない場合、選択肢の最初のページの上部でウィザードの目的を説明します。
  • ユーザーがタスクにコミットするタイミングを明確にするには、コミット ページを使用します。 通常、コミット ページは選択肢の最後のページであり、コミットされるタスクを示すために [次へ] ボタンのラベルが変更されます。
    • タスクにリスクがある場合 (セキュリティ、または時間や金銭の損失が関係する場合など)、またはユーザーが選択内容を理解できず、確認が必要になる可能性が高い場合を除き、ユーザーの以前の選択内容を単に要約する概要ページは使用しないでください。
  • ウィザードを終わらせる以外に何の効果もない "おめでとうございます" ページは使用しないでください。 ウィザードの結果がユーザーにとって明らかに明らかな場合、最終コミット ボタンでウィザードを閉じます。
    • ユーザーがフォローアップとして実行する可能性のある関連タスクがある場合、フォローアップ ページを使用します。 "メール メッセージを送信する" などのよくあるフォローアップ タスクは避けてください。
    • "完了" ページは、結果が表示されず、タスクの完了に関するフィードバックを提供するより良い方法がない場合のみ使用してください。
    • "進行状況" ページがあるウィザードでは、タスクの完了を示すために "完了" ページまたは "フォローアップ" ページを使用する必要があります。 実行時間が長いタスクの場合、"コミット" ページでウィザードを閉じ、通知を使用してフィードバックを提供します。

エラー メッセージ

  • ユーザーがメッセージの結果としてアクションを実行したり行動を変えたりする可能性が低い場合、エラー メッセージを表示しないでください。 ユーザーが実行できるアクションがない場合、または問題が重要でない場合、エラー メッセージを表示しないでください。
  • 可能な限り、ユーザーが問題を解決できるよう解決策を提案します。 ただし、提案された解決策で問題を解決できる可能性があることを確認してください。 考えられるがあり得ない解決策を提案して、ユーザーの時間を無駄にしないでください。
  • 具体的であれ。 構文エラーや無効な操作など、あいまいな表現は避けてください。 関係するオブジェクトの具体的な名前、場所、値を提示してください。
  • ユーザーを責めたり、ユーザーの間違いを暗示したりするような言い回しは使用しないでください。 フレーズの中で "あなた" や "あなたの" を使うのは避けてください。 一般的には能動態が好まれますが、ユーザーが主語であり、能動態を使用するとエラーの責任を感じる可能性がある場合、受動態を使用します。
  • エラー メッセージには [OK] を使用しないでください。 ユーザーはエラーを OK とはみなしません。 エラー メッセージに直接的なアクションがない場合、代わりに [閉じる] を使用します。
  • 次の単語は使用しないでください。
    • エラー、失敗 (代わりに "問題" を使用してください)
    • に失敗しました (代わりに "できません" を使用してください)
    • 違法、無効、不良 (代わりに "正しくない" や "有効でない" を使用してください)
    • 中止、強制終了、終了 (代わりに "停止" を使用してください)
    • 破壊的、致命的 (代わりに "深刻" を使用してください)

これらの用語は不必要であり、Windows が持つ励ましのトーンに反しています。 代わりに、エラー アイコンを正しく使用すると、問題があることが十分に伝わります。

  • エラー メッセージに効果音を添えないでください。 そうすることは不快であり、不必要でもあります。

警告メッセージ

  • 警告は、将来の問題の原因となる可能性のある状態を示します。 警告はエラーや質問ではないので、日常的な質問を警告として表現しないでください。
  • ユーザーがメッセージの結果としてアクションを実行したり行動を変えたりする可能性が低い場合、警告メッセージを表示しないでください。 ユーザーが実行できるアクションがない場合、または状態が重要でない場合、警告メッセージを表示しないでください。

確認

  • 不必要な確認を使用しないでください。 確認は、次の場合のみ使用します。
    • 続行しない明確な理由があり、ユーザーが続行しない可能性も十分にある。
    • アクションが重大な結果をもたらすか、簡単に元に戻すことができない。
    • アクションに、ユーザーが気付かない可能性のある結果が伴う。
    • アクションを続行するには、適切な既定値がない選択をユーザーが行う必要がある。
    • 現在の状況を考えると、ユーザーが誤ってアクションを実行した可能性がある。
  • 確認は "はい" または "いいえ" の質問として表現し、"はい" または "いいえ" で答えます。 他の種類のダイアログ ボックスとは異なり、確認はユーザーがすぐに決定できないように設計されています。 ユーザーが応答に考慮を入れない場合、確認に値はありません。

アイコン

  • すべてのアイコンは Aero スタイルのアイコン ガイドラインに従う必要があります。 すべての Windows XP スタイルのアイコンを置き換えてください。
  • 基になる問題の重大度ではなく、メッセージの種類に基づいて標準アイコンを選択してください。
    • エラー : 発生したエラーまたは問題。
    • 警告。 将来の問題の原因となる可能性のある状態。
    • 情報。 役立つ情報。

問題に異なるメッセージ タイプが組み合わされている場合、ユーザーが対処する必要がある最も重要な側面に焦点を当てます。

  • アイコンは常にメイン指示またはその他の対応するテキストと一致する必要があります。
  • 重大でないユーザーによる入力の問題に、エラー アイコンは必要ありません。 ただし、インプレース エラーにはアイコンが必要です。そうしないと、このようなコンテキスト フィードバックを見逃しやすくなります。
  • 重大でないエラーを "緩和" するために警告アイコンを使用しないでください。 エラーは警告ではありません。代わりに、エラー アイコンのガイドラインを適用してください。
  • 質問ダイアログの場合、重大な結果を伴う質問に対してのみ警告アイコンを使用します。 日常的な質問には警告アイコンを使用しないでください。

ヘルプ

  • 特定の関連するヘルプ トピックへのリンク。 ヘルプ ホーム ページ、目次、検索結果の一覧、または他のページにリンクするページにはリンクしないでください。 よくある質問の長い一覧として構成されたページへのリンクは避けてください。クリックしたリンクに一致するページをユーザーが検索しなければならなくなるためです。 現在のタスクに関連せず、役に立たない特定のヘルプ トピックにはリンクしないでください。 空のページにはリンクしないでください。
  • 一貫性を保つため、すべてのウィンドウまたはページにはヘルプ リンクを配置しないでください。 ヘルプ リンクを 1 か所に表示するとしても、すべての場所に表示する必要があることを意味するわけではありません。
  • 可能な限り、ヘルプ リンクのテキストは、ヘルプ コンテンツで回答される主な質問に沿って表現してください。 "詳細を確認する" や "これに関するヘルプを取得する" というフレーズは使用しないでください。
  • リンク テキストには、キーワードだけでなく、ヘルプ リンク全体を使用します。
  • 完全な文を使用する。
  • 疑問符を除き、句読点や省略記号は使用しないでください。
  • ヘルプ コンテンツがオンラインの場合、リンク テキストでその内容を明確にします。 これにより、リンクの結果が予測可能になります。