ウィザード

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

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

のスクリーン ショット

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

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

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

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

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

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

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

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

注:セットアップ、ダイアログ ボックス、および 進行状況バーに関連 ガイドラインについては、別の記事で説明します。

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

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

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

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

• 必要な質問を順番に指定する必要がありますか? 考えられる質問がいくつかありますが、省略可能な質問はありますか? その場合は、ダイアログ ボックスまたはタブ付きダイアログ ボックスを検討してください。

  正解:

  [印刷オプション] ダイアログ ボックスのスクリーン ショットを

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

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

設計の概念

ウィザードの過剰使用

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

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

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

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

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

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

接続ウィザードのスクリーン ショット

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

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

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

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

ウィザードの長さ

デザインの質問は、ページとオプションの数と編成に関して自然に生じます。 例えば：

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

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

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

正解:

[ディスクの作成] ダイアログ ボックスのする

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

一方、複数の決定ポイントと分岐を含むウィザードがあり、ユーザーがナビゲーション パスを頻繁に追跡できなくなる場合は、実用的な制限を超えているので、ウィザードの長さを減らす必要があります。 または、ウィザードを複数の異なるタスクに分割することもできます。

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

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

正解:

表示言語ウィザードの

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

正解:

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

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

分岐

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

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

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

ナビゲーション ガイドは、タスクに多くのステップがあり、ユーザーが順番に自分の位置を失う可能性がある場合や、完了にどれだけ時間がかかるかを知りたい場合に役立ちます。

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

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

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

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

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

ページの整合性

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

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

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

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

不正解:

sql server セットアップ ウィザードの

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

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

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

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

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

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

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

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

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

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

Before:

クリアタイプ ウィザードのスクリーン ショット

後:

クリアタイプ ウィザードのスクリーン ショット

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

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

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

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

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

ガイドライン

全般

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

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

  正解:

  のスクリーン ショット

  診断ダイアログ フィードバックの

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

ウィンドウ サイズ

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

• タスクを快適に実行するのに十分な大きさのウィンドウのサイズ。 ページ レイアウトを不注意にしたり、ユーザーが過度にスクロールしたりサイズを変更したりする必要はありません。

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

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

  正解:

  Visual Studio のセットアップの

  良い:

  Visual Studio のセットアップの

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

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

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

ウィザードの長さ

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

分岐

• 分岐以外のウィザードの設計は、分岐よりも優先されます。 分岐しないウィザードは、簡単で短く、簡単に移動できる傾向があります。 分岐ウィザードを使用すると、ユーザーはタスクのステップ数とシーケンス内のステップの位置を判断することが困難になります。

• 分岐する必要がある場合は、次のいずれかの手法を使用して、ユーザーが自分の方向を向けるのに役立ちます:

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

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

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

    正解:

    ステップ ベースのウィザード組織のスクリーン ショット

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

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

  • ウィザードで単一の分岐を使用し、タスクの早い段階で分岐が発生する場合は、その時点でシーケンスを開始し、分岐しないアプローチを使用します。 つまり、分岐の時点から、分岐の最後まで順番に進行します。

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

コミット ボタン

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

[キャンセル] ボタン

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

閉じるボタン

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

その他のコントロール

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

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

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

ウィザード ページ

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

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

• ウェルカム ページを使用しないでください。可能な限り、最初のページを機能させないでください。 オプションの [作業の開始] ページは、次の場合にのみ使用します。

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

  不正解:

  mappoint セットアップのウェルカム ページの

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

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

  • [作業の開始] ページを使用しない場合は、選択肢の最初のページの上部にあるウィザードの目的について説明します。

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

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

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

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

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

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

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

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

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

航法

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

ヘルプ

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

テキスト

全般

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

タイトル

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

ボタン

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

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

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

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

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

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

    例外:

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

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

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

• 終了句読点は使用しないでください。

ドキュメンテーション

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