Document Actions
プログラマのためのUXチートシート
http://msdn.microsoft.com/ja-jp/library/aa511258.aspx
はじめに
の
- 「Windows ユーザー エクスペリエンス ガイドライン」
- 「ガイドライン」
- 主に「コントロール」
の抜粋です。
以下の基準で抜粋しました
- Web UIに応用可能
- 実用的かつ具体的
- 自明ではない
プライマリUIを目立たせる
プライマリ UI 要素を強調するには、以下に従います。 - プライマリ UI 要素は、視線の通り道に配置します。 - タスクを開始する UI 要素は、左上隅または中央上に配置します。 - コミット ボタンは、右下隅に配置します。 - 残りのプライマリ UI は、中央に配置します。 - コマンド ボタン、コマンド リンク、アイコンなど、注意を引き付けるコントロールを使用します。 - 大きなテキストや太字のテキストなどの目立つテキストを使用します。 ユーザーが必ず読む必要があるテキストは、対話型コントロール内に配置するか、アイコンを付けるか、またはバナー上に表示します。 明るい背景に濃い色のテキストを使用します。 要素の周りの間隔は広めにします。 強調している要素をユーザーが確認するために、マウスでポイントするなど、対話操作が必要になるような設計はしないでください。
セカンダリUIをプライマリUIより目立たせない
セカンダリ UI 要素を目立たなくするには、以下に従います。 - セカンダリ UI 要素は、視線の通り道の外に配置します。 - ユーザーが通常確認する必要がない要素は、ウィンドウの左下隅または下部に配置します。 - コマンド ボタンの代わりに、注意を引き付けないタスク リンクなどのコントロールを使用します。 - 通常のテキストまたは灰色のテキストを使用します。 - 暗い背景に明るい色のテキストを使用します。濃い灰色や青い背景に白いテキストを使用すると効果的です。 - 要素の周りの間隔は最小限にします。 - セカンダリ UI 要素を隠すために段階的表示の使用を検討します。 セカンダリ UI に対しては、アフォーダンスの比重を下げます。 アフォーダンスとは、オブジェクトの使用方法などを示唆する視覚的特性です。ユーザーがその場で対話的に操作できる UI が好まれる傾向にありますが、こういった UI すべてが "ここをクリック!" などと主張するように設計すると、視覚的にひどく乱雑になります。多くの場合、セカンダリ UI のアフォーダンスは目立たせず、マウス ポインターを重ねたときに全効果を発揮させることが有効です。
耳が痛い言葉
詳細に注意し、すべてが洗練された状態になるようにします。ユーザーは細かいことには気付かないものなどと思ってはなりません。必ず気付かれます。 スキンを提供することで平凡な外観をフォローできると考えないでください。ユーザーの多くはスキンにこだわりがありません。ほどほどの外観が大量に提供されているよりは、優れた外観が 1 つある方が良い印象を与えることができます。 プログラムのエラー メッセージを 1つの "エクスペリエンス" と考えて、適切に設計してください。プログラマが場当たり的にエラー メッセージを作成することは避けるようにします。
コマンドボタンの原則
コマンド ボタンが、すぐに操作を開始するために使われるものであるかどうか。該当しない場合は、別のコントロールを使用します。 状態の設定にはコマンド ボタンを使いません。代わりにラジオ ボタンやチェック ボックスを使います。コマンド ボタンは操作を開始するためだけに使います。
リンクの原則
従来、リンクには下線も付いていましたが、この下線は不要な場合が多く、見た目をすっきりさせるために使われなくなってきています。 リンク上にマウス ポインターを合わせると、リンク テキストに (まだ付いていなかった場合) 下線が付けられて表示され、ポインターが手の形に変化します。
コマンドボタン or リンク; 原則
従来、コマンド ボタンは操作を開始するために使われ、一方でリンクは他の場所に移動するために使われていました。ウェブの普及に伴いリンクの用途が広がり、コマンドの開始やオプションの選択にも使用されるようになってきました。どのコマンドにコマンド ボタンを使うか、またはリンクを使うかをここで検討します。アフォーダンスの概念や、主コマンドと副コマンドの違いに着目すると、いくつかのガイドラインが浮かび上がります。 主コマンドか副コマンドか 主コマンドとは、ウィンドウの主たる目的のために必要なコマンドのことです。たとえば、[印刷] ダイアログ ボックスでは、"印刷" が主コマンドになります。コマンド ボタンを使用すると、主コマンドであることがユーザーにはっきりわかります。副コマンドは、便利ではあるが、そのウィンドウの目的の本質ではない周辺的な操作です。たとえば、[印刷] ダイアログ ボックスでは、"プリンターの検索"、"プリンターのインストール" が副コマンドです。副コマンドには、あまり強調されないようにリンクを使用することを検討します。 情報収集か関連ウィンドウの表示か 情報入力を求めたり、タスクをすぐに選択するための、ウィンドウを表示することが目的の場合は、コマンド ボタンを使います。このような操作は、コマンドに似た感じがあります。これに対し、関連はあっても独立するウィンドウを表示するのであれば、リンクを使うことができます。このような操作には、移動のような印象を受けるからです。したがって、[開く]、[保存]、[参照] などのコマンドについては、副コマンドであっても、リンクではなくコマンド ボタンを使用します。使い分けに迷う場合は、モーダル ウィンドウを表示するのであればコマンド ボタンを、独立したウィンドウであればリンクを使用してください。 元の状態に戻せなくなる操作か、いつでも元に戻れる移動か ユーザーはリンクを見ると、ウェブのページ移動を思い浮かべます。安全性レベルに関してもウェブと同様に考えます。つまり、ブラウザーでは、ユーザーはいつでも [戻る] ボタンを使って元に戻ることができます。さらに、ブラウジングの際、重要な確認のほとんどは、リンクではなくコマンド ボタンを使って行います。このような予測に合わせるため、リスクのある操作や元の状態に戻せない操作など、重要な結果を伴うコマンドにはリンクを使いません。同様に、ウィザードやタスク フローでは、確認にはコマンド ボタンを使用し、リンクは選択や次の手順への移動に使うようにします。
コマンドボタン or リンク
次の場合には、コマンド ボタンを使用します。 - コントロールがウィンドウの表示などの即時的な操作を開始し、そのコマンドはウィンドウの主な目的に関連している。 - 副コマンドであっても、情報の入力や選択を行うためにウィンドウが表示される。 - ラベルが短く、4 語あるいは12文字以下で構成されているので、ボタンを使用しても見苦しい外観にならない。 - コマンドがインラインではない。 - コントロールがその他の関連するコマンド ボタンのグループ内に表示されている。 - リスクのあるアクションや取り消しできないアクションである。リンクは戻ることも可能な移動の手段と考えられているため、重要な結果をもたらすコマンドには適していません。 - コマンドが確定を表すウィザードまたはタスク フロー。これらのウィンドウでは、コマンド ボタンは確定を示し、リンクは次のステップへの移動を示します。 次のような場合はリンクを使ってください。 - 他のページ、ウィンドウ、またはヘルプ トピックに移動するための操作である場合。 - 例外: ウィザードでは [戻る]、[次へ] のコマンド ボタンを使います。 - コマンドがテキスト本文内に埋め込まれる場合。 - コマンドが副次的な性質のものである場合。つまり、ウィンドウの主目的に関連しないコマンドである場合。この場合は、軽量コマンド ボタンまたはリンクの方が適切です。 - コマンドがメニューまたは関連するリンク グループの一部である場合。 - ラベルが長い (5 語あるいは15文字以上) ため、コマンド ボタンの外観が不自然になる場合。
複数のコマンドボタンを並べる or ラジオボタン+コマンドボタンの組み合わせ
以下のいずれかに該当する場合、特定のコマンド ボタンのセットの代わりに、ラジオ ボタンを汎用コマンド ボタン ([OK]、[キャンセル]) と組み合わせて使用することがよくあります。 - 5 つ以上の操作が考えられる場合。 - ユーザーが判断の前に追加の情報を確認する必要がある場合。 - ユーザーが決定前に (追加情報を見るなど) 選択肢について何らかのやり取りを行う必要がある場合。 - ユーザーが別のコマンドの代わりに、オプションとして選択肢を確認する場合。 - ほとんどのユーザーに選択を強く推奨する既定オプションがある場合。ラジオ ボタンの場合、コマンド リンクに比べ、ユーザーは既定値を変更しようとしない傾向があります。特にウィザードの場合、既定値をそのまま受け入れて[次へ] をクリックすることに慣れています。これに対し、明示的な選択を促す場合は、コマンド リンクの方が向いています。
チェックボックスの原則
チェック ボックスを並べる方向は、横ではなく縦にします。横方向に並べると読みにくくなります。 チェック ボックスのラベル ラベルには語句または "...する" などの言い切りの文を使用し、末尾に句読点は付けません。 例外: チェック ボックスのラベルが従属コントロールのラベルでもあり、ラベルの後ろに従属コントロールが続く場合は、ラベルの末尾にコロンを使用します。 チェック ボックスのグループでは、同じ文法構造の表現を使用し、すべてのラベルの長さがおおよそ同じになるようにします。 肯定文を使用します。チェック ボックスをオンにするとあるアクションが実行されないなどの言い回しはラベルに使用しません。 例外: [今後、この <アイテム> を表示しない] チェック ボックス。
ラジオボタンの原則
相互に排他的な一連の選択肢から 1 つのオプションを選択するために使用するかどうか。該当しない場合は、別のコントロールを使用します。オプションを複数選択できる場合は、代わりにチェック ボックス、複数選択リスト、またはチェック ボックス リストを使用します。 オプションの数が 2 個以上 7 個以下か。使用する画面領域はオプションの数に比例するので、グループ内のオプション数は 2 個以上 7 個以下になるようにします。8 個以上のオプションがある場合は、ドロップダウン リストまたは単一選択リストを使用します。 値が数値以外かどうか。数値データの場合は、テキスト ボックス、ドロップダウン リスト、またはスライダーを使用します。 十分な画面領域を確保でき、画面領域を多く使用するだけの重要性を持つオプションであれば、ラジオ ボタンを使用します。それ以外の場合は、チェック ボックスまたはドロップダウン リストを使用します。
チェックボックス or ラジオボタン
チェック ボックスが適しているのは、オプションのオン/オフを切り替える場合のみです。オプションがまったく別の内容である場合は、ラジオ ボタンを使用できます。チェック ボックスとラジオ ボタンの両方が考えられる場合は、以下に従います。 - チェック ボックスがオフになっていることによって示される意味がはっきりしない場合は、ラジオ ボタンを使用します。 オンにしたときの状態とオフにしたときの状態が正反対で、選択肢があいまいではないかどうか。該当しない場合は、ラジオ ボタンまたはドロップダウン リストを使って、それぞれの状態ごとにラベル付けできます。 チェック ボックスがオフになっていることによって示される意味がはっきりしない場合は、ラジオ ボタンを使用します。
チェックボックス or チェックボックスリスト
グループ内のオプションの数が 10 項目以下であるかどうか。使用する画面領域はオプションの数に比例するので、チェック ボックスの数は 10 個以下になるようにします。オプションが 10 項目を超える場合はチェック ボックス リストを使用します。
ドロップダウンリストとコンボ ボックスの原則
ドロップダウン リストとコンボ ボックスは、オブジェクト (名詞) や属性 (形容詞) に使用し、コマンド (動詞)には使用しません。
ドロップダウンリストの原則
ほとんどの状況下で大多数のユーザーに推奨される既定のオプションがあるかどうか。選択されているオプションが見えることが、他のオプションが見えることよりもはるかに重要かどうかを判断します。該当する場合は、ドロップダウン リストを使用して他のオプションを隠すことを検討します。 画面領域が貴重か。該当する場合は、必要な画面領域が一定でリスト アイテム数に依存しない、ドロップダウン リストを使用します。
ドロップダウンリスト or ラジオボタン
オプションに注意を引く必要があるかどうか。該当する場合は、ラジオ ボタン、単一選択リスト、または編集可能なリスト ボックスの使用を検討します。これらのコントロールは占める画面領域が広いので、注意を引きやすくなります。ドロップダウン リストは小さいので、あまり目立たせる必要のないオプションに向いています。 各オプションが注意を引かないようにする場合、またはユーザーに変更を勧めない場合は、ドロップダウン リストの使用を検討します。ドロップダウン リストでは現在選択されているオプションに注意が向けられるのに対し、ラジオ ボタンではすべてのオプションが等しく強調されます。 選択対象がデータではなく、プログラム オプションかどうか。オプションの値は、コンテキストや他のデータに基づかない値である必要があります。データの場合は、ドロップダウン リストまたは単一選択リストを使用します。
リストボックス or チェックボックスリスト
複数選択がタスクに不可欠、または複数選択の使用頻度が高いかどうか。該当する場合は、対象が詳しい知識のあるユーザーではないときは特に、チェック ボックス リストを使用して、複数選択であることを明確にします。多くのユーザーは標準的な複数選択リストで複数選択がサポートされていることを知りません。チェック ボックスを使用すると複数選択が強調される、または画面が煩雑になるときは、標準の複数選択リストを使用します。
リストボックス or リストビルダーおよび追加/削除リスト
選択したアイテムの順序が重要かどうか。該当する場合は、リスト ビルダーおよび追加/削除リストで順序の変更がサポートされますが、その他の複数選択パターンでは順序の変更はサポートされません。
リストビュー(いわゆるレコード一覧表示)の原則
適切な列順を既定にします。 一般に、次の順序で列を並べます。 1. 最初に、アイテム名またはデータ ID を配置します。 2. 次に、リスト アイテムの区別に役立つデータを配置します。 3. 次に、最も有用なデータを配置します (短い、または固定長のデータが望ましい)。 4. 次に、それより有用性の低いデータを配置します (短い、または固定長のデータが望ましい)。 5. 最後に、長く、可変長のデータを配置します。 長く、可変長のデータを最終列に配置し、水平スクロールを使用する頻度を下げます。これらのカテゴリ内に、関連する情報も合わせて論理的な順序で配置します。
スライダーの原則
その設定が相対量のように見えるかどうか。該当しない場合は、ラジオ ボタン、ドロップダウン リスト、または単一選択リストを使用します。 ユーザーの文化を反映する向きにします。たとえば、西洋文化では文字を左から右へ読むので、横型のスライダー場合、バーの左側を低い値、右側を高い値にします。文字を右から左へ読む文化では、この逆にします。 横向きのスライダーでは、スライダーの下に目盛りを配置します。縦向きのスライダーの目盛りは、西洋文化では右側に、文字を右から左に読む文化では左側に配置します。 同じ設定に対して、スライダーと数値テキスト ボックスの両方を使用しないでください。より適切なコントロールだけを使用します。 例外: すぐにフィードバックが必要で、かつ明確な数値を設定可能にする必要がある場合は、両方のコントロールを使用します。
スピンコントロールの原則
コントロールを数値の入力に使用するかどうか。該当しない場合は、ドロップダウン リスト、スライダーなど、固定値のセットから選択を行う別のコントロールを使用します。スクロールにはスクロール バーを使用します。 コントロールをテキスト ボックスと対にするかどうか。該当しない場合は、スピン コントロールは使用しません。 連続した値で構成される範囲が有効かどうか。該当しない場合は、代わりに有効な値を列挙したドロップダウン リストを使用します。
テキストボックスの原則
一般的なルールとしては、使用できる中で最も制約のあるコントロールを使用します。テキスト ボックスのような制約のないコントロールを使用するのは、最後の手段にします。ただし制約を考える際には、ローカライズを想定する必要があります。たとえば、米国の郵便番号を入力するように制約するコントロールは、ローカライズ向きではありません。一方、どのような郵便番号形式も受け入れる制約のないテキスト ボックスは、ローカライズにも対応します。
ツリービューの原則
階層データがあるからといって、必ずしもツリー ビューを使用する必要はありません。リストビューの方が簡単で効果的な場合も数多くあります。 リスト ビューを使用する場合は、以下に示す方法で階層情報を消化できます。 - ルート ノードがある場合は、不要なことが多いので削除します。 - 最上位のコンテナーは、リスト ビュー グループ、タブ、ドロップダウン リスト、または展開可能な見出しで置き換えます。 ユーザビリティ調査によると、ユーザーは、レベルの深いツリーよりも 1 レベルのアイテム数の多いツリーでオブジェクトを簡単に見つけることができることがわかっています。このため、ツリーを設計するときには、レベルを深くするよりも 1 レベルのアイテム数を多くします。理想的には、ツリーに含めるレベルはルート ノードを除いて 4 つ以内とし、よくアクセスされるオブジェクトは最初の 2 レベル以内に表示します。 接続線を再検討します。接続線はコンテナー ノードとリーフ ノードの関係を明示するものですが、大幅な理解の向上につながるわけではありません。接続線があると表示は煩雑になります。特に、ノードどうしが近い場合や、スクロールするほど遠く離れている場合は、接続線は役に立ちません。
グループボックス(いわゆるグルーピング)の原則
グループ ボックスは関連性を示す有効な視覚的手段ですが、使いすぎると見た目が乱雑になり、利用できるスペースが大幅に減ります。グループ ボックスは視覚的に場所を取るため、他に良い解決策がない場合に限り、控え目に使用する必要があります。 レイアウトだけで効果的に関連性を伝えることができるか。該当する場合は、代わりにレイアウトを使用します。コントロールが互いに関連する場合は並べて配置し、関連しない場合は余分に間隔を空けます。インデントによって階層関係を示すこともできます。 区切り記号を使用して効果的に関連性を伝えることができるか。該当する場合は、代わりに区切り記号を使用します。区切り記号とは、コントロールをまとめる横線のことです。区切り記号を使用すると、外観がすっきりします。グループ ボックスとは異なり、区切り記号は領域いっぱいの幅にすると最も効果的です。 グループ ボックスを入れ子にしないようにします。グループ ボックス内の関連性を示すには、レイアウトを使用します。
段階的表示コントロール(いわゆる折りたたみ表示)の原則
段階的表示コントロールのアフォーダンスは非常に微弱です。言い換えると、微弱ながらも視覚的特性によって使用方法が示されているということです。 シェブロンは、全部または部分的に非表示になっているコンテキスト内の残りのアイテムを表示したり、非表示にしたりします。 矢印は、ポップアップ コマンド メニューを表示します。 階層構造を参照するときに、プラス/マイナス コントロールを使ってコンテナーの内容をインプレースで展開または折りたたみます。 回転する三角形で、個別アイテムに対する追加情報の表示/非表示をインプレースで切り替えます。これらは、コンテナーの展開にも使用されます。 インプレースでの表示/非表示には一重のシェブロンを使用します。ポップアップ メニューを使用しての表示/非表示には二重のシェブロンを使用します。ただし、内部ラベルを持つコマンド ボタンに対しては、常に二重のシェブロンを使用してください。
タブの原則
次のような場合は、水平タブを使用します。 - ウィンドウのタブが 7 個以下の場合。 - ユーザー インターフェイス (UI) がローカライズされても、すべてのタブが 1 行に収まる場合。 次のような場合は、垂直タブを使用します。 - プロパティ ウィンドウのタブが 8 個以上の場合。 - 水平タブを使用すると 2 行以上になる場合。 タブを入れ子にしたり、水平タブと垂直タブを組み合わせることはしません。代わりにタブの数を減らすか、垂直タブのみを使用するか、またはドロップダウン リストなど別のコントロールを使用します。 水平タブはスクロール型にしません。水平スクロールは見つけにくいものです。垂直タブはスクロール型にしてもかまいません。 タブ ページでスクロール バーは使用しません。タブは、ウィンドウの有効領域を拡大するという点でスクロールバーと類似しており、タブがあればスクロール バーは不要です。 限定的で意味のあるタブ ラベルを使用します。"全般"、"詳細設定"、"設定" など、どのタブにも当てはまるような汎用的なタブ ラベルの使用は避けます。
進行状況バーの原則
ユーザビリティに関する調査で、応答時間が 1 秒を超えると気になりだすという結果が出ています。この理由から、完了まで 2 秒以上かかる処理を長いものと見なし、何らかの形で進行状況をフィードバックすることを検討する必要があります。 不要なアニメーションは使用しません。アニメーションは、通常、実際のタスクとは別のスレッドで実行され、処理がロックアップしても進行中であるものと表示される場合があり、誤解を招くことがあります。また、処理が予想よりも遅い場合に、ユーザーがその一因としてアニメーションを疑うこともあります。したがって、明白な根拠がある場合にのみアニメーションを使用し、ユーザーを楽しませるためには使用しないようにします。 残り時間に情報を集中します。これこそユーザーが最も気にする情報です。合計経過時間は、タスクが繰り返されそうなときなどの、経過時間が役立つシナリオのみで提示します。残り時間の見積もりが進行状況バーと共に表示される場合は、完了率のパーセントは表示しません。この情報は進行状況バー自体で表現されます。 赤または黄色の進行状況バーは、タスクの最終結果ではなく、進行のステータスを示すためにのみ使用します。赤または黄色の進行状況バーは、タスク完了のためにユーザーが何らかのアクションを起こすことが必要であることを示します。状況を回復できない場合は、進行状況バーを緑のままにしてエラー メッセージを表示します。 取り消すことで、何の副次的な影響もなしに環境が以前の状態に戻される場合は、ボタンに "キャンセル" というラベルを付けます。これ以外の場合は、部分的に処理が完了した状態のままになることを示すために、ボタンに "停止"というラベルを付けます。
進行状況バー or ビジーポインタ
5 秒以内に処理が完了するかどうか。該当する場合は、進行状況バーを表示するには処理時間が短すぎるので、代わりにビジー ポインターを使用します。ほとんどの場合は 5 秒以下で完了するが 5 秒を超えることもある処理に対しては、まずビジー ポインターを表示し、5 秒経過後に進行状況バーに切り替える方法を使用します。 進行状況バーとビジー ポインターを組み合わせて使用しません。どちらかのみを使用し、両方を同時に使用しないでください。
ことば
5 つの重要な点 1. 早期からテキストに取り組みます。テキストの問題からデザインの問題が明らかになることが多いためです。 2. 流し読みに適したテキストをデザインします。 3. 重複するテキストを削除します。 4. わかりやすいテキストを使用し、語数が多くならないようにします。 5. 必要であれば、詳細な情報を提供するためにヘルプ コンテンツへのリンクを用意します。
わたし or あなた (メッセージの人称)
直接的、間接的にユーザーの行動に言及する場合は "you" を使用します (英語の場合)。 ユーザーに操作を説明するには、二人称 (you/your) を使用します。多くの場合、二人称が黙示的に含まれています。 例: Choose the pictures you want to print. (印刷する画像を選択します。) Choose an account (アカウントを選択します。) (黙示的) ユーザーがプログラムに指示を与える場合は、一人称 (I/me/my) を使用します。 例: Print the photos on my camera. (カメラの写真を印刷します。) "we" の使用は慎重に行います。一人称の複数形は、高圧的な組織や団体の存在を思わせます。ただし、アプリケーション名を使用するよりは好ましいといえます。"it is recommended (推奨されます)" よりも "werecommend (推奨します)" を使用します。 三人称でユーザーに言及しないようにします。よそよそしくなり、当事者である感じが失われてしまいます。 エラーメッセージ ユーザーに責任を押し付けたり、ユーザーに非があるような言い回しを避けます。"あなた" という表現は使わないようにします。一般には能動態が好まれますが、ユーザーを主語にすることでエラーの責任がユーザーにあるかのように感じさせてしまう可能性がある場合は受動態を使用します。
能動態 or 受動態
能動態を使用すると、人や物がその操作を実行することが強調されます。わかりにくく、型にはまったように聞こえる受動態よりも、より直接的で暖かみがあります。 受動態は、語数が多くなったり構造上の不都合が生じるのを避けるためにのみ使用します。文の焦点が行為者よりも行為の方にある場合、主語が不明である場合、または、エラー メッセージ内で、能動態を使用すると主語であるユーザーがエラーを責められているように感じる場合に使用します。
肯定文
肯定文で記述し、実行できないことよりも、実行できることを強調します。
簡単に謝らない
"sorry (申し訳ございません)" は、ユーザーにとって重大な問題をもたらすエラー メッセージ内でのみ使用します (データ損失の場合、コンピューター使用を続行できない場合、技術サポートに問い合わせが必要な場合など)。プログラムの正常な動作の範囲内で発生した問題 (ネットワーク接続の検出に一定時間かかるなど) の場合は、謝罪表現は使用しないでください。
エラーメッセージの原則
問題を引き起こしたユーザーの操作ではなく、問題そのものに焦点を当てます。必要に応じて受動態を用いるなど、間接的な表現を心がけます。 8 つの重要な点 1..エラー処理を考慮したプログラム設計を行う。 2.不要なエラー メッセージは表示しない。 3.必要なエラー メッセージを表示して、ユーザーの混乱を防ぐ。 4.エラー メッセージには、問題、原因、および解決策を必ず明記する。 5. 適切なエラー メッセージの条件 (関連性が高い、実行性が高い、簡潔、明確、具体的、丁寧、めったに表示されない) を満たす。 6.プログラムの視点ではなく、ユーザーの視点からエラー メッセージを設計する。 7.ユーザーにトラブルシューティングをさせない (検出可能な原因ごとに異なるエラー メッセージを用いる)。 8.目的を果たすことができる範囲で最も控えめな表示方法を使用する。 次の言葉は使用しないでください。 - エラー、障害 (代わりに "問題" を使用) - 失敗しました (代わりに "できません" を使用) - 不正な、無効な、悪い (代わりに "正しくない" を使用) - 中止、キル、強制終了 (代わりに "停止" を使用) - 壊滅的な (代わりに "重大な" を使用) 対応する英語 Don't use the following words: - Error, failure (use problem instead) - Failed to (use unable to instead) - Illegal, invalid, bad (use incorrect instead) - Abort, kill, terminate (use stop instead) - Catastrophic, fatal (use serious instead) テクニカル サポートへの問い合わせは提案しません。テクニカル サポートに問い合わせて問題を解決するという選択肢はいつでも利用できます。エラー メッセージを通じて促す必要はありません。むしろ、ユーザーがテクニカル サポートに頼らずに問題を解決できるような、有益なエラー メッセージを作成することを目指します。
メイン指示テキストのテンプレート
表現に関して厳密な規則はありませんが、メイン指示テキストには、可能な限り次のテンプレートを使用してください。 <主語 (省略可)> は <動作を実行> できません <理由> のため、<主語 (省略可)> は <動作を実行> できません <主語 (省略可)> は "<オブジェクト名>" に対して <動作を実行> できません <理由> のため、<主語 (省略可)> は "<オブジェクト名>" に対して <動作を実行> できません <動作を実行> するのに十分な <リソース> がありません <主語> には、<目的> に必要な <オブジェクト名> がありません <デバイスまたは設定> がオフになっているため、<予期しない結果> になります <デバイスまたは設定> が <利用できません | 見つかりません | オンになっていません | 有効になっていません> "<オブジェクト名>" は現在利用できません ユーザー名またはパスワードが正しくありません "<オブジェクト名>" へのアクセス許可がありません <動作を実行> する権限がありません <プログラム名> で重大な問題が発生したため、直ちに終了する必要があります 文法的に正しく、ガイドラインに従う限り、必要に応じてメイン指示テキストのテンプレートを変更してかまいません。
文の原則
文の流れに従って操作した結果、予期せぬ事態に陥るということのないよう、操作よりも結果を先に記述します。 正しい例: Windows を再起動するには、[OK] をクリックします。 間違った例: [OK] をクリックして Windows を再起動します。
視線の原則
一般にユーザーは、静的テキストよりも、コマンド ボタンのラベルを優先的に読む傾向があります。 ユーザーは、初めにウィンドウ全体をざっと見渡し、主に次のような順序で UI 要素を読み取ると想定します。 1. 中央の対話型コントロール 2. コミット ボタン 3. 中央以外の対話型コントロール 4. メイン指示テキスト 5. 補足説明 6. 警告アイコンが付いたテキスト 7. ウィンドウ タイトル 8. UI 内のその他の静的テキスト 9. 脚注 ある操作に関する特定のテキストをユーザーが必ず読むようにするには、そのテキストを対話型コントロールに配置します。
配置(UIレイアウト)の原則
- タスクを開始する UI 要素は、左上隅または中央上に配置します。 - タスクを完了する UI 要素は、右下隅に配置します。 - 可能な場合、重要なテキストは静的テキストにするのではなく、対話型コントロールに配置します。 - スクロール可能な長いコントロール/ページの左下角や下部には、重要な情報を配置しないようにします。 - 大きなテキスト ブロックは提示しないようにし、不要なテキストは削除します。逆ピラミッド型の提示スタイルを使用します。 - 何らかの手段でユーザーの注意を引き付ける場合は、注意を引くことに正当な根拠があることを確認します。
焦点の原則
フォーカル ポイントは、1 つだけにします。現実世界では、視線は一度に 1 つのものだけに焦点を合わせます。ユーザーは複数の場所に同時に焦点を合わせることはできません。 UI 要素をフォーカル ポイントにするには、以下の方法で視覚的に強調します。 - UI 画面の左上または中央上に配置します。 - 重要かつわかりやすい対話型コントロールを使用します。 - メイン指示テキストなどの目立つテキストを使用します。 - コントロールが既定で選択され、初期入力フォーカスが置かれているようにします。 - コントロールの背景を異なる色にします。
ラベルの原則
一般的なラベルの配置には以下のような 4 つのスタイルがあり、それぞれにメリットがあります。 - 左揃えのラベルをコントロールの上に配置 - 左揃えのラベルをコントロールの左に配置 - 左揃えのラベルをコントロールの左に配置、コントロールを左に寄せる - 右揃えのラベルをコントロールの左に配置
色の原則
ユーザーがどのように色を解釈するかは、文化によって違うことがよくありますが 赤、黄、緑が示す状態の解釈は、世界中で一貫しています。これは、UNESCO の道路標識および信号に関するウイーン協定によるものです。この協定では、交通信号に関する世界共通の決まりとして、赤は止まれ、緑は進め、黄は注意を意味するということが定められています。これらの状態の色は、文化による解釈の違いを気にすることなく使用できます。 赤、黄、緑の純色は、デザインに使用しないようにします。混乱を避けるために、これらの色は状態を伝えるためにのみ使用します。状態を伝える目的以外に使用する必要がある場合は、純色ではなく控えめな色調の色を使用します。