ウィザード

その素晴らしい、気まぐれな名前にもかかわらず、ウィザードは実際にはユーザー インターフェイスの特別な形式ではなく、ユーティリティの特定の範囲のみを持っています。

ウィザードは、複数ステップのタスクを実行するために使用されます。

ウィザードの複数の手順は、一連のページとして表示されます。

ウィザードには通常、次の種類のページが含まれます。

• 選択肢ページは、情報を収集し、ユーザーが選択できるようにするために使用されます。
• [コミット] ページは、[戻る] または [キャンセル] をクリックして元に戻すことができない操作を実行するために使用されます。
• [進行状況] ページは、長い操作の進行状況を表示するために使用されます。

最新のウィザード設計では、効率に優れ、短い操作では [進行状況] ページが省略可能になり、多くの場合、最初と最後に従来の [ようこそ] ページ と [おめでとう] ページ が表示されます。

すべてのウィザード ページには、次のコンポーネントがあります。

• ウィザードの名前を識別するタイトル バー。左上隅には [戻る] ボタン、オプションの [最小化/最大化] ボタンと [復元] ボタンがある [閉じる] ボタンがあります。 タイトル バーには、タスク バー上でそれを識別するアイコンも含まれていることに注意してください。
• ページでユーザーの目的を説明するためのメインの指示。
• オプションのテキストと、場合によっては他のコントロールを含むコンテンツ領域。
• タスクにコミットする、または次の手順に進むコミット ボタンが少なくとも 1 つあるコマンド領域。

ウィザードには複数の手順がありますが、これらの手順はすべて、ユーザーの観点から 1 つのタスクに追加する必要があります。 これは、"1 つのウィザード、1 つのタスク" の基本的なウィザード設計原則です。

したがって、この記事では、タスクはウィザードの基本的な機能です (たとえば、セットアップ ウィザードのタスクはプログラムをインストールすることです)。 サブタスクは、大規模なタスクの側面です (たとえば、セットアップ ウィザードのサブタスクは、インストールするプログラムを構成する場合があります)。 最後に、各ウィザード ページは、特定のサブタスクまたはタスクのステップと見なされます (たとえば、プログラムの構成に 2 つまたは 3 つの手順が関係している場合があります)。

メモ：セットアップ、ダイアログ ボックス、進行状況バーに関連するガイドラインは、別の記事で示されています。

これは適切なユーザー インターフェイスですか?

ウィザードは、複数の入力ステップを必要とする任意のタスクに使用できます。 ただし、有効なウィザードには追加の要件があります。

• ウィザードは 1 つのアトミック タスクを実行しますか? 1 つのタスクではない操作は使用しないでください (1 つのタスクを実行しない限り、プログラム全体をウィザードにしないでください)。 ウィザードを使用して、独立したタスクや主に関連のない手順を組み合わせないでください。

• 必要な質問の数を減らすことができますか? ほとんどの場合に適切に機能するか、後で必要に応じて調整できる、許容される既定値はありますか? その結果、ページ数を減らすことができますか? その場合は、1 つのページ (ダイアログ ボックスなど) に表示できるようにタスクを簡略化するか、(タスクを直接実行できるように) 完全に入力する必要がなくなります。

• 必要な質問を順番に提供する必要がありますか? いくつかの可能性がありますが、オプションの質問はありますか? その場合は、ダイアログ ボックスまたはタブ付きダイアログ ボックスを検討してください。

  正確:

  

  [Microsoft PowerPoint 印刷オプション] ダイアログ ボックスには多くのユーザー入力オプションが含まれているため、ウィザードで表示できます。 ただし、それらを順番に指定する必要がないため、ダイアログ ボックスを選択することをお勧めします。

ウィザードは、比較的重い形式のユーザー インターフェイスです。適切な軽量ソリューションがある場合は、それを使用してください!

設計概念

ウィザードの過剰使用

これまで、ウィザードは通常の UI とは異なり、ユーザーが特に複雑なタスク (異なる場所に存在するステップを含む) を実行できるように設計されており、多くの場合、ユーザーの成功に役立つインテリジェンスが組み込まれています。 現在、すべての UI は、タスクを可能な限りシンプルにするように設計されている必要があるため、この目的のために特別な UI は必要ありません。

しかし、ウィザードは特別な UI であると信じられているのは、主に "ウィザード" と呼ばれるためです (たとえば、"ダイアログ" や "プロパティ ウィンドウ" よりもはるかに創造的です)。 代わりに、複数ステップのタスクと見なし、その事実に特別な注意を向けないようにすることをお勧めします。

ウィザードを作成する前に、プログラムのメイン フローからユーザーを本当に中断する必要があるかどうかを検討してください。 より軽量でインラインのコンテキスト ソリューションが存在する可能性があり、最終的にはユーザーに役立ち、効率的に感じられます。 たとえば、プログラムの不適切に設計された機能では、ウィザードで説明して簡略化する必要はありません。これは、機能自体の再設計を保証します。 プログラムに関するより基本的な問題を解決するために、ウィザードをバンドエイドとして使用しないでください。

ウィザードには適切な機能があります

ウィザードは、ユーザー エクスペリエンスを簡素化するためのキーの 1 つです。 プログラムの構成などの複雑な操作を実行し、一連の簡単な手順に分割することができます。 プロセスの各時点で、必要な内容の説明を入力し、ユーザーが選択を行い、テキストを入力できるようにするコントロールを表示できます。

特定の種類のマルチステップ タスクは、ウィザード フォームに役立ちます。 たとえば、Windows では、複数のウィザードに接続機能 (インターネットまたは企業ネットワーク、またはプリンターや FAX マシンなどの周辺機器) が含まれます。

ネットワークへの接続は、ウィザードに適した Windows の一般的なタスクです。

ここでは、ウィザードの機能は、既知の安定したもの (すぐに使用できるオペレーティング システム) と不明で可変なもの (電話会社またはインターネット サービス プロバイダーとの接続の取り決め) を仲介することです。 コンピューティング エコシステムの複雑さは、ウィザードを使用してその複雑さを軽減するのに本当に役立つようになったので、十分に重要です。

Windows ウィザードと同様に機能するその他の種類のタスクには、ハイエンド機能 (音声や手書き認識など) やリッチ メディア エクスペリエンス (ムービーの作成と公開のオプションの構成など) があります。 ウィザードは、トラブルシューティングなど、より基本的なマルチステップ タスク用に展開することもできます。 つまり、さまざまなユーザーが広く異なる方法でプログラムを体験する必要がある場合は、ウィザードの必要性と、複数のユーザー入力ポイントの容量を示すことができます。

プログラムでは、ウィザードが提供している関数と、その関数が実際にウィザードを展開するレベルに上がっているかどうかを判断するには、少し前もって設計する価値があります。

ウィザードの長さ

デザインの質問は、ページとオプションの数とorganizationに関して自然に発生します。 次に例を示します。

• ウィザードに最適なページ数はありますか? または、少なくとも望ましい範囲ですか?
• ユーザーができるだけ早く完了できるように、ウィザードを簡潔かつ合理化する必要がありますか?
• より少ない選択肢を必要とするページが増える必要がありますか? または、より複雑なページを減らしますか? どの設計がより使いやすいと見なされますか?
• タブ付きページなどの UI 規則を適用することで、ウィザードのエクスペリエンスを高速化できますか?

Microsoft は、3 ページ以下のウィザードを単純なウィザードとして設計し、4 ページ以上のウィザードでは高度なウィザード設計を使用することを推奨しました (1999 年の Windows ユーザー エクスペリエンス ガイドラインを参照)。 しかし、現在のウィザードの設計標準では、単純なフォームと高度なフォーム (Welcome ページと Congratulations ページの使用) の主な違いの 1 つであったものが含まれているため、これらのカテゴリは不十分に感じられ、デザインの選択を決定するページ数は任意のように見えます。

ウィザードは、タスクに必要な長さまたは短い値にする必要があります。長さの固定ガイドラインはありません。 1 ページのウィザードは実際にはダイアログ ボックスとして表示される必要があるため、2 つのページがウィザードで可能な限り最も狭い形式である可能性があります。

正確:

このタスクには非常に少ないオプションがあるため、ウィザードとして表示すると無駄になります。 ダイアログ ボックスは、このユーザー インターフェイスに適したフォームです。

スペクトルのもう一方の端で、複数の決定ポイントと分岐を含むウィザードがあり、ユーザーがナビゲーション パスの追跡を失う可能性が高い場合は、実際の制限を超え、ウィザードの長さを短くする必要があります。 または、ウィザードを複数の異なるタスクに分割することもできます。

ウィザードの最も適切な長さを決定するときは、ターゲット ユーザーに特に注意してください。 家庭の消費者やオフィス ワーカーなどのエンド ユーザー向けのプログラムでは、ウィザードを使用して複雑さを隠す傾向があります。ウィザードはできるだけ短く、クリーン、シンプルなページ デザイン、および可能な限り多くのオプションに対して事前に選択された既定値を使用します。 対照的に、IT プロフェッショナル向けのサーバー ウィザードまたはプログラムは、より長く複雑になる傾向があります。 ターゲット ユーザーのこのグループは、構成の決定に対する許容度がはるかに高く、複雑さが隠されすぎると、実際には疑わしくなる可能性があります。

ウィザードが本質的に複雑なタスクを簡略化する場合は、技術的に洗練された対象ユーザーに対しては比較的最小限に、初心者のユーザーベースでは比較的積極的に行う必要があります。

正確:

このウィザード ページはエンド ユーザー向けに適切に設計されています。これは、複雑になる可能性があるサブジェクトを、単純な論理バイナリの選択 (インストールまたはアンインストール) に減らすためです。

正確:

Microsoft SQL Server 2008 のセットアップ ウィザードでは、ページデザインは複雑であり、多くの選択肢でさらに検討が必要になりますが、対象ユーザーは、機能の選択を厳密に制御するデータベース管理者です。

最後に、特定のタスクを実行する頻度に注意してください。 頻度の低いタスクでは、より長いウィザードが展開される場合があります。一方、頻繁なタスクは簡潔さを優先する必要があります。

分岐

より長いウィザードでは、"アップストリーム" に指定されたユーザー入力に応じて、一連のページが異なる可能性があるタスク フローのブランチを作成する必要がある場合があります。分岐は本質的にユーザーに対して割り当て解除されるため、安定性を伝えるためにユーザー エクスペリエンスを設計する必要があります。 ウィザード全体で分岐を引き起こす決定ポイントは 2 つ以下にすることをお勧めします。また、1 つのブランチ内に入れ子になったブランチは 1 つ以下にすることをお勧めします。

分岐ウィザード内での安定したユーザー エクスペリエンスの作成に関するガイドラインについては、この記事の「ガイドライン」セクションの 「分岐 」を参照してください。

ナビゲーション ガイドの提供

ナビゲーション ガイドは、タスクに多くの手順があり、ユーザーが順番に自分の位置を失う可能性がある場合や、完了にどれくらいの時間がかかるかを知りたい場合に便利です。

ナビゲーション ガイドは、多くの場合、ウィザードのページまたはセクションの一覧として表示され、目次のように、各ページの左側の列またはペインに表示されます。 リストはウィザード全体で保持されますが (各ページに同じページの一覧が表示されます)、ユーザーが現在シーケンス内の場所を示す視覚的な手段がいくつかあります (たとえば、太字を使用してアクティブなページまたはセクションを区別します)。

ナビゲーション ガイドは、シーケンシャルでも非シーケンシャルでもかまいません。 シーケンシャル型は、過去のページと既知の将来のページを示します。 ステップが既知で、ページが依存している場合は、ページではなくステップの観点から将来を提示できます。 その後、ページが認識されると動的にページを設定できます。 ナビゲーション シーケンスは固定されているため、ナビゲーション ガイドは対話型ではありません。

シーケンシャルでないナビゲーション ガイドは対話型であるため、ユーザーは以前に表示したページを直接見直すことができます。 また、省略可能に設計されたページのナビゲーション シーケンスの前にスキップすることもできます。 省略可能なページには、ほとんどの状況で許容される既定値が必要です。 この種類のガイドでは、次の操作を行います。

• 以前に表示したページは、いつでも直接表示できます。
• 今後のページには、前提条件がある場合は表示されない場合があります。
• アクセスできるページは、(アクティブまたは無効になっているリンクを使用するなど) できないページと、必要なページまたはオプションのページと目に見えて区別する必要があります。

このシナリオでは、[戻る] ボタンの意味についてユーザーが混乱する可能性があります。 [戻る] をクリックすると、ナビゲーション ガイドの前のページまたはセクション、または最後に表示されたページまたはセクションが表示されますか? Windows ウィザードでは、他のコミット ボタンと共に右下隅ではなく、ウィザード ページの左上隅に [戻る] ボタンが配置されるようになったため、ユーザーは Back 機能を Web 上と見なします。 そのため、最適な解決策は、[戻る] ボタンに Web ナビゲーションの意味を与え ([戻る] をクリックすると、最後のページまたはセクションが表示されます)、ウィザードのナビゲーション ガイドを使用して順次ナビゲーションを行います。

ページの整合性

ウィザードの設計には、ナビゲーションや分岐エクスペリエンスの処理方法など、タスク フロー全体に関する決定だけでなく、ウィザードを構成する個々のページに関連する決定も含まれます。 優れたウィザード ページを設計するための最も重要な原則は、整合性の原則です。ページの内容は一緒に属している必要があります。

ウィザード ページは、それぞれが概念的にハングアップし、タスク全体の 1 つの側面のみを処理する場合に、はるかに使い勝手が高くなります。 メイン命令は、これを実現するための主な手段です。 ユーザーにページの目標または目的を明確に特定します。 補足命令とページ上のコントロールはすべて、メイン命令に直接関係します。 ウィザード ページでは、何らかの考え方が必要なオプションをユーザーに提示する必要がありますが、ページ自体の整合性に重点を置いているため、その作業はうまくいきません。

残念ながら、ウィザードのデザイナーは、ページの使いやすさ、シンプルさ、整合性を示す証拠として、ユーザーの [次へ] ボタンの急速なクリックを間違えることがよくあります。 究極のウィザード エクスペリエンスは、[次へ]、[次へ]、[次へ]、[完了] ではありません。 このようなエクスペリエンスは、既定値が適切に選択されたことを示唆していますが、すべての選択肢が省略可能であるため、ウィザードが本当に必要ではなかったことも示唆しています。

ビジュアルとテキストの観点から、これらの要素をベアの要点に置き留めます。 1 つのページ ("ブリトー ウィザード") に複数のサブタスクをまとめるか、複雑な入力要件を提示するためのタブに頼る必要があります。 1 つのページには、ウィザードのタスク全体の 1 つのサブタスクが含まれている必要があります。

正しくない:

非常に密度の高いユーザー入力の 3 つのタブが必要な場合、このウィザード ページでは実行が多すぎます。

ほとんどの場合、ウィザード全体で各ページのサイズを維持して、一貫した外観を実現します。 Windows ウィザードでは、ページのサイズがコンテンツの量と一致するようにサイズ変更可能なページを使用できますが、このオプションを使用するのはごくわずかです。

最後に、各ウィザード ページの構造要素をシーケンスを通じて保持します。 たとえば、左上隅の [戻る] ボタンを 1 つまたは 2 つのページのコミット ボタン領域に移動しないでください。 このレベルのレイアウトの一貫性は、ユーザーがウィザード内で安定した感じを得るのに役立ちます。 これは、ページの視覚的整合性のベースラインと考えてください。

適切なレベルのコミュニケーションを見つける

ユーザーは、画面上で大きなテキスト ブロックを読み取るための許容度が低く、タスクを迅速に移動することを目的とする UI サーフェイス内では、それほど許容されません。

ウィザードには、過剰に通信する傾向があります。 彼らは画面に多くのスペースを占有し、ドライブがスペースを埋めるように促しているようです。 これは、パーキンソンの法則のバリエーションのようなものです。UI テキストは、使用可能な領域を埋めるために拡張されます。

この過剰な原因の 1 つは冗長性です。 ウィザードの初期設計で使用されるテンプレートのため、タイトル バー、見出し、本文テキスト、コントロール ラベルなど、ページ上の複数の場所に同じ言語が表示される場合があります。

ウィザードのテキストを無情に排除するには、プロのエディターを雇う価値があります。 個々のページで不要な質問やオプションを削除し、ウィザード全体 (たとえば、従来の [ようこそ] ページと [おめでとう] ページ) からページ全体を削除します。 ユーザーまたはチームが内部的に使用するテクノロジや機能の専門用語ではなく、ターゲットユーザーがタスクを説明するために使用する言語を使用して、簡潔に記述されたメイン命令を使用して、ページのポイントにアクセスします。 このユーザー中心のアプローチは、プログラムのウィザードの通信を改善するために不可欠です。

ウィザードのトーンに特別な注意を払う:時にはプログラムの最も永続的な印象は、あなたが言うことではなく、どのように言うかの結果です! ウィザードでは、ユーザーは、プログラムが入力を求めるときに 2 人称代名詞 ("you") を自由に使用して、わかりやすい会話のトーンに慣れている。 ガイドラインの詳細については、「 スタイルとトーン」を参照してください。

ウィザード ページの文字数を減らすことは一般的に評価できますが、行き過ぎないように注意してください。 タスクが重要であり、ウィザードを保証する場合、ユーザーは賢明な選択をするのに十分な情報を持っていることに感謝します。 次の例は、意味を損なうことなくウィザードのテキストを圧縮する方法を示しています。

前:

後:

このウィザード ページの編集バージョンでは、タスク指向のメイン命令が提供され、メイン命令の下にある不要な説明の段落が削除され、チェック ボックスの目的を明確にするためにチェック ボックス ラベルが修正されます。

3 つの操作のみを行う場合...

1. 実行しようとしているタスクを適切な UI でマップし、ジョブを実行します。ユーザーから多くの入力を収集する必要があると思う場合は、単にウィザードを既定値にしないでください。

2. ウィザードの長さと構造について慎重に検討してください。ユーザーが自分の主要なタスクやプログラムへの関心に戻ることができるように、短い分岐しないウィザードを使用して、エクスペリエンスを可能な限りシンプルに保つ必要があります。

3. ウィザードの各ページの整合性を確認します。ページの内容は明確に一緒に属している必要があります。

ガイドライン

全般

• 最初に、ダイアログ ボックス、作業ウィンドウ、単一ページなどの軽量の代替手段を検討してください。 ウィザードを使用する必要はありません。任意の UI で役立つ情報と支援を提供できます。

• 複数ステップのタスクにウィザードを使用します。 フィードバックを含むシングルステップ タスクには、複数ページのダイアログ ボックスを使用します。 ガイドラインの詳細については、「 ダイアログ ボックス」を参照してください。

  正確:

  

  

  この例では、Windows ネットワーク診断は進行状況ページと結果ページで構成されています。 タスクは 1 つのステップだけなので、ユーザーがウィザードで必要とするナビゲーション ボタンは必要ありません。 これは、実質的に複数ページのダイアログ ボックスとして表示されます。

ウィンドウ サイズ

• 垂直または水平のページ スクロールなしですべてのウィザード ページを表示できるウィンドウ サイズを選択します。 ページ上のコントロールにはスクロールが必要な場合があります。ウィザード ページ自体はスクロールできません。

• ウィンドウのサイズを、タスクを快適に実行するのに十分な大きさにします。 ページ レイアウトを狭くしたり、ユーザーに過度にスクロールやサイズ変更を要求したりしないでください。

• ただし、ウィンドウを過度に大きくしないでください。 ウィンドウを大きくすると、タスクはより複雑になり、対話のために追加の移動が必要になります。

• サイズ変更可能なウィンドウは、より多くの画面領域からメリットを得られるが、不要なウィザードに使用します。 適切な最小サイズを割り当てます。 サイズ変更可能なウィンドウは、ページが大きなリスト ビューなどのサイズ変更可能なコンテンツを操作する必要がある場合に役立ちます。

  正確:

  

  より適切な例:

  

  この例では、ウィンドウのサイズを変更すると、ユーザーは完全な一覧を表示できます。

• コンテンツの必要に応じてページ サイズが変更される動的サイズのウィザードを使用することを検討してください。 これにより、ウィザードは、さまざまなコンテンツを含むページ レイアウトに対応できます。

• ユーザーがウィザードのエクスペリエンスの安定性の欠如として変更を認識する可能性がある場合は、動的よりも静的なサイズ設定を優先します。 視覚的な安定性は、多くの場合、コンテンツの宿泊施設を切り捨てる。 ほとんどのウィザードでは、標準の静的ウィンドウ サイズを採用し、特別なケース用に動的サイズ設定を予約する必要があります。

ウィザードの長さ

• ウィザードをできるだけ簡潔かつ合理化します。 不要なオプションと質問を取り除き、スマートな既定値を使用して、ユーザー入力に必要なページ数を減らします。
  • 例外： IT プロフェッショナルやその他の技術ユーザーは、より長いウィザードと詳細な入力要件に対する許容度が高くなります。
• ウィザードを少なくとも 2 ページにする。 代わりに、1 ページウィザードをダイアログ ボックスとして再設計する必要があります。
• 各ページの複雑さを増やすだけで、ウィザードのページ数を減らさないでください。 たとえば、ユーザー入力を必要とする 3 つのタブを含むウィザード ページは、3 つの個別のページとして再設計する必要があります。
• 各ページを単純にして、ユーザーが無意識にシーケンス全体を通じて [次へ] をクリックするようにして、ウィザードのページ数を増やさないでください。 これは、ウィザードの設計上の一般的な欠陥です。 ウィザード ページに少なくともある程度の考え方が必要ない場合は、ウィザードにまったく含める必要がない可能性があります。

分岐

• 分岐よりも非分岐ウィザードの設計を優先します。 分岐しないウィザードは、より単純で短く、簡単に移動できる傾向があります。 分岐ウィザードを使用すると、ユーザーはタスク内のステップの数と順序の場所を判断することが困難になります。

• 分岐する必要がある場合は、次のいずれかの方法を使用して、ユーザーの方向を設定できるようにします。

  • ページを列挙します。 一般的な手法は、各ページのシーケンス内のユーザーの位置を示す方法です。たとえば、手順 X は Y です。エンドポイント (Y) が安定していることを確認します。 値を変更すると、ユーザーの信頼度が損なわれます。

  • サブステップ ( 手順 2a/6 など) の概念を含めます。

  • 各ステップに複数のページが含まれる場合があるページに関係なくステップを作成します。 たとえば、旅行サービスでは、業界向けの確立された e コマース規則に基づいてウィザード organizationを使用する場合があります。

    正確:

    

    論理ラベルを使用すると、分岐ウィザードのユーザーに適切な方向を提供できます。

  • 列挙シーケンスでは、省略可能なステップを永続的として扱います。 たとえば、ブランチが省略可能な手順をいくつかスキップしているだけの場合は、番号を付け直すのではなく、フィードバックの手順もスキップするだけです。 したがって、ユーザーがページ 2 で選択を行い、ページ 3 と 4 を省略可能にする場合は、手順 1、2、5、および 6/6 を示します。 手順 5 と 6 の番号を付け直さないでください。

  • ウィザードで 1 つのブランチが使用されていて、その分岐がタスクの早い段階で行われる場合は、その時点でシーケンスを開始してから、分岐しない方法を使用します。 つまり、分岐の時点から、分岐の最後まで順番に進行します。

• 分岐する必要がある場合は、1 つのウィザード内でブランチの数を 1 つまたは 2 つに制限します。 ブランチ内に複数のブランチ ("入れ子になった" ブランチ) を含めてはいけません。

コミット ボタン

• ユーザーがタスクにコミットする場合は、メイン命令 (印刷、接続、開始など) に対する特定の応答であるコミット ボタンを使用します。 タスクをコミットするために、Next (コミットメントを意味しない) や Finish (特定ではない) などの汎用ラベルを使用しないでください。 これらのコミット ボタンのラベルは、独自に理にかなっている必要があります。 常に動詞を使用してコミット ボタンのラベルを開始します。 例外:
  • [保存]、[選択]、[選択]、[取得] など、特定の応答がまだ汎用的な場合は、[完了] を使用します。
  • [完了] を使用して、特定の設定または設定のコレクションを変更します。
• 1 つのウィザードに複数のコミット ポイントを含めることができますが、1 つのポイントを使用することをお勧めします。
• 必要に応じて、ページのコミット ボタンの名前を変更したり非表示にしたりできます。 この柔軟性は、以前のウィザードでは使用できなかった Windows の新しいウィザード設計の利点の 1 つです。 コミット ボタンを非表示にすることは、コミット ボタンの無効化とは異なる点に注意してください。
• 正のコミット ボタンを無効にしないでください。 それ以外の場合、ユーザーはコミット ボタンが無効になっている理由を推測する必要があります。 コミット ボタンを有効のままにし、問題が発生するたびに役立つエラー メッセージを表示することをお勧めします。 ボタンを無効にできるのは、その理由が明確で明確な場合のみです。
• ナビゲーション ボタン ([次へ] と [戻る]) とコミット ボタンを混同しないでください。 次は、コミットメントなしでウィザードを進行することを意味します。[戻る] は常に次のページで使用でき、[戻る] をクリックすると、最後の [次へ] ボタンの効果が元に戻ります。 それが不可能な場合、ユーザーはコミットメントを行っており、コミット ボタンの特定のラベルを使用して示されます。 [次へ] ボタンと [戻る] ボタンの詳細については、「 ナビゲーション」を参照してください。

[キャンセル] ボタン

• 実際にキャンセルする予定があるかどうかをユーザーに確認するように求めないでください。 そうすると迷惑になる可能性があります。 例外:
  • アクションには大きな影響があり、正しくない場合は簡単に修正できません。
  • このアクションにより、ユーザーの時間や労力が大幅に失われる可能性があります。
  • アクションは、他のアクションと明らかに矛盾しています。
• 誤って取り消された場合に備えて、ユーザーがウィザードを再起動できるようにします。
• [キャンセル] ボタンを無効にしないでください。 例外:
  • 取り消しが有害な場合は、自己完結型ウィザードでタスクを実行する場合に当てはまります。
  • 取り消しが不可能な場合は、ウィザードですべての手順を制御できない場合があります。

閉じるボタン

• Follow-Upページと入力候補ページには Close を使用します。 ウィンドウを閉じても、この時点で行われた変更やアクションは破棄されないため、Cancel を使用しないでください。 Done は命令型動詞ではないので、使用しないでください。
• タスクが実行されると、[キャンセル] は [閉じる] になります (自己完結型ウィザードの場合)。 [閉じる] の効果は、ウィンドウを閉じるだけです。

その他の制御

• コマンド リンクは、コミットメントではなく、選択肢にのみ使用します。 特定のコミット ボタンは、ウィザードのコマンド リンクよりもはるかに優れたコミットメントを示します。
• コマンド リンクを使用する場合は、[次へ] ボタンを非表示にしますが、[キャンセル] ボタンはそのままにします。

ページの使用 (ダイアログ ボックスまたはインライン UI と比較)

• 一般に、ダイアログ ボックスよりもページを優先します。 ユーザーは、ウィザードがページベースであると想定しています。
• ダイアログ ボックスを使用すると、 オブジェクト ピッカーやブラウザーなど、ページの完成に役立ちます。
• ダイアログ ボックスを使用して、ページ全体に適用されるエラー メッセージを表示し、コミット ボタンをクリックした結果を表示します。
• インライン プレゼンテーションは、 プログレッシブ開示やコンテキスト UI などの単純な動的動作に使用します。
• 特定のコントロールに適用されるエラー メッセージにはインライン プレゼンテーションを使用します。

ウィザード ページ

• 効率的な意思決定に重点を置く。 要点に焦点を当てるページの数を減らします。 関連ページを統合し、オプションのページをメインフローから除外します。 ウィザードを使用してユーザーが [次へ] を完全にクリックすると、最初は適切なエクスペリエンスのように見えるかもしれませんが、ユーザーが既定値を変更する必要がない場合は、ページが不要になる可能性があります。

• 各ページを 1 つの目的と視覚的な一貫性を持つよう設計します。 詳細については、「ページの 整合性」を参照してください。

• ウェルカム ページを使用しないでください。最初のページは可能な限り機能します。 省略可能なはじめに ページは、次の場合にのみ使用します。

  • ウィザードには、ウィザードを正常に完了するために必要な前提条件があります。
  • ユーザーは、最初の [選択肢] ページに基づいてウィザードの目的を理解できない場合があり、さらに説明する余地はありません。
  • はじめに ページのメイン命令は、"始める前に: " です。

  正しくない:

  

• 最新のウィザードでは、機能する最初のページを選択します。 ここでは何もする必要はありませんが、[次へ] をクリックします。 ユーザーが貴重な時間にこのトークン税を支払うことを強制する理由

• ユーザーが選択を求められるページでは、最も可能性の高いケースに合わせて最適化します。 これらの種類のページは、指示だけでなく、実際の選択肢を提示する必要があります。

  • はじめに ページを使用しない場合は、選択項目の最初のページの上部にあるウィザードの目的について説明します。

• [コミット] ページを使用して、ユーザーがタスクにコミットするタイミングを明確にします。 通常、[コミット] ページは選択肢の最後のページであり、[次へ] ボタンはコミット中のタスクを示すようにラベルが付け直されます。

  • タスクが危険な (セキュリティや時間やコストの損失を伴う) 場合や、ユーザーが選択内容を確認する必要がある可能性が高い場合を除き、ユーザーの以前の選択を要約するだけの [概要] ページは使用しないでください。

• [進行状況] ページを使用して、長い操作の状態を表示します。 正常に完了すると、進行状況ページは自動的に次の手順に進みます。 ユーザーに表示する必要がある問題がある場合にのみ、進行状況ページに残る必要があります。 [進行状況ページに戻る] をクリックしても、副作用はありません。

  • 1 つの確定進行状況バーを使用します。 次を含む 確定的な進行状況バーのガイドラインに従います。
    • 完了が明確に示されます。 操作が完了していない場合は、進行状況バーを 100% にしないでください。
    • 進行状況を再起動しないでください。 進行状況バーが再起動すると (操作のステップが完了した場合など)、その値は失われます。これは、ユーザーが操作がいつ完了されるかをユーザーが知る方法がないためです。 代わりに、操作のすべてのステップで進行状況の一部を共有し、進行状況バーを 1 回完了するようにします。
  • 進行状況バーの上にある現在のステップの簡潔な説明を入力します。 迅速な操作を行う場合、このようなテキストは不要です。プログレス バーだけで十分です。 1 分以上必要な操作では、テキストが役立ちます。
    • 通常は動詞で始まり、省略記号で終わる文のフラグメントを使用します。 例: ファイルのコピー...、必要なコンポーネントのインストール....
    • 下ではなく、バーの上にテキストを配置します。
    • 正しくない:
    • 
    • この例では、説明テキストが進行状況バーの上に表示されます。
    • 不要な詳細を含む進行状況ページを乱雑にしないようにします。 このページはテクニカル サポート用ではありません。これはユーザー向けです。
    • 正しくない:
    • 
    • この例では、GUID などの技術的な詳細は、ユーザーにとって意味がありません。

• ウィザードを終了する以外に何も行わない [おめでとう] ページは使用しないでください。 ウィザードの結果がユーザーに明らかな場合は、最後のコミット ボタンでウィザードを閉じます。

  • ユーザーがフォローアップとして実行する可能性が高い関連タスクがある場合は、Follow-Upページを使用します。 "電子メール メッセージを送信する" などの使い慣れたフォローアップ タスクは避けてください。
  • [完了] ページは、結果が表示されず、タスクの完了に関するフィードバックを提供するより良い方法がない場合にのみ使用します。
  • [進行状況] ページがあるウィザードでは、[完了] ページまたは [Follow-Up] ページを使用してタスクの完了を示す必要があります。 実行時間の長いタスクの場合は、[コミット] ページでウィザードを閉じ、通知を使用してフィードバックを送信します。

• [概要] ページは、入力が複雑で、ユーザーが確認する必要がある場合、タスクに重大なリスク (財務上の切り替えなど) が含まれている場合、または(透明性を通じて信頼を築くために) 明確ではないユーザー入力に基づいてウィザードがアクションを実行する場合にのみ使用します。 多くの場合、概要ページはこの関連性バーを満たせず、省略できます。

• 回復できない問題が原因でウィザードを完了できない場合は、エラー ページを使用します。 このページでは、技術的な専門用語のユーザーが理解できない、明確な言語で問題が何であるかを説明します。 また、ユーザーが問題を解決するために実行できる実用的な手順を提供します。 その他のガイドラインについては、「 エラー メッセージ」を参照してください。

  • 例外： 回復可能な軽微な問題がウィザードで完了した場合は、エラーではなく追加のタスクとして問題を提示します。 エラー、失敗、問題などの用語ではなく、成功指向の肯定的で励ましの言語を使用します。 エラー アイコンは使用しないでください。

「ナビゲーション」

• [次へ] は、コミットメントなしで次のページに進む場合にのみ使用します。 次のページに進むと、[戻る] または [キャンセル] をクリックして効果を元に戻すことができない場合、コミットメントと見なされます。
• [戻る] を使用して間違いを修正します。 間違いを修正する以外に、ユーザーはタスクを進行させるために [戻る] をクリックする必要はありません。
• ナビゲーションを使用してユーザーの選択を保持します。 たとえば、ユーザーが変更を加え、[戻る] をクリックしてから [次へ] をクリックした場合、それらの変更は保持されます。 ユーザーは、明示的に変更をクリアすることを選択しない限り、変更を再入力する必要はありません。
• 手順の繰り返しが有害でない限り、[戻る] ボタンを無効にしないでください。
• ユーザーが次のナビゲーション シナリオで選択内容を参照または修正することを許可します。
  • ユーザーが入力を与え、[コミット] ボタンをクリックし、[戻る] をクリックして以前の変更を確認し、何も変更せず、もう一度 [コミット] ボタンをクリックします。 通常、これは可能であり、2 番目のコミットは次のページに進むだけです (タスクは既に完了しているため)。
  • ユーザーが入力を行い、[コミット] ボタンをクリックし、[戻る] をクリックして以前の変更を確認し、何かを変更してから、もう一度 [コミット] ボタンをクリックします。 通常、これは可能であり、2 番目のコミットは変更された入力でタスクをやり直す必要があります (最初のコミットの効果を置き換えるか元に戻します)。

ヘルプ

• プログラム ヘルプのドキュメントを参照する必要がないように、十分な情報を提供するようにウィザード ページを設計します。 ウィザードは既にユーザーをプログラムと直接やり取りしています。ユーザーが外部ヘルプを探す必要がある場合、この状態からさらに削除されます。 ヘルプは、ルールではなく例外である必要があります。
• ヘルプにアクセス ポイントを指定する必要がある場合は、ページのコンテンツ領域の左下部分 (コマンド領域の上) にリンクを使用します。 このリンクは簡潔で、通常はユーザーが回答を求める可能性が最も高い質問の形式で表現する必要があります。
• 正確:
• 
• このような基本的な背景情報がウィザード ページを乱雑にするため、ヘルプへのこのリンクが適切です。

Text

全般

• ユーザーとユーザーのコンピューター、ドキュメント、設定などを参照するには、ユーザーと ユーザーを使用します。 最初のユーザー (I、my) を使用して、コンピューターまたはウィザードを参照しないでください。 ただし、ユーザーが選択したオプションで最初のユーザーを使用することは許容されます。 例: [使用するチェックボックスのみ] です。
• すべてのウィザード ページには、メイン命令が必要です。

タイトル

• ウィザードの名前をタイトル バーに配置します。 タイトルスタイルの大文字と小文字を使用します。
• タイトルには句読点を含めてはいけません。ただし、疑問符が付いているタイトルを除きます。
• ウィザードのタイトルにウィザードという単語を含めないでください。 たとえば、ネットワーク セットアップ ウィザードではなく、ネットワークへの接続を使用します。

ボタン

• [戻る] ボタンにテキストを含めないでください。 代わりに、ラベル付けされていない矢印グリフを使用します。

• [次へ] ボタンにテキストを含めます。 "次へ" という単語に加えてグリフ (や >>など>) を使用しないでください。

• 独自に意味があり、メイン命令への応答である特定のコミット ボタン ラベルを使用します。 ラベルを理解するために、ユーザーが他の情報を読む必要がないのが理想的です。 ユーザーは、静的テキストよりもコマンド ボタン ラベルを読み取る可能性がはるかに高くなります。

• 可能であれば、コミット ボタン ラベルに "Finish" という単語を使用しないでください。通常は、より具体的で具体的なコミット ボタンがあるためです。

  • ボタンをクリックするとタスクにコミットする場合 (タスクがまだ実行されていない場合)、メイン命令への応答である動詞で始まる特定のラベルを使用します (例: Print、Connect、Start)。

  • タスクがウィザード内で既に実行されている場合は、代わりに [閉じる] を使用します。

    例外:

    • [完了] は、特定のラベルがまだ汎用の場合 (保存、選択、選択、取得など) に使用できます。
    • タスクで設定または設定のコレクションを変更する必要がある場合は、[完了] を使用できます。

• 動詞を使用してコミット ボタンラベルを開始します。 例外は[OK]、[はい]、[いいえ] です。

• 文形式の大文字を使用します。

• 末尾に句点を付けません。

ドキュメント

• ほとんどの Windows ウィザードでは、タイトルに "ウィザード" という単語は含まれなくなりましたが、ドキュメントではウィザードをウィザードとして参照できます。 この参照は小文字にする必要があります。
• 正確:
• 初めてネットワークを設定する場合は、 ネットワークへの接続 ウィザードを使用してヘルプを表示できます。
• 以前のバージョンの Windows のレガシ ウィザードには、タイトルに Wizard が含まれる場合があります。 これらのウィザードの 1 つを参照する場合は、[X] ウィザードを使用して、[X] ウィザードが表示されないようにできます。
• ウィザード内の個々の画面をページとして参照します。