ウィザードとは?

ウィザードとは基本的に、ユーザーの作業を終了まで導く一連の画面あるいはダイアログ・ボックスのことです。一般に各ウィザード画面では、選択するか、またはフィールドに記入するかして情報を入力するようユーザーに求めます。必要なデータを入力した後、ユーザーは「戻る」および「次へ」といったナビゲーション・オプションをクリックし、作業を進めます。最終ステップで、ユーザーは「終了」をクリックして、ウィザードでの作業を完了します。

上に戻る

ウィザードを用意すべき場合

ユーザー・インターフェース・エンジニアリングのエキスパートによると (参考文献を参照)、ユーザーに関し、以下のことが想定できる場合、ウィザードを用意すべきです。

• 目的地に辿り着くまで、多くのステップを踏まなければならない場合
• 行う作業内容に関連した知識を十分に備えていない場合
• 各ステップを特定の順序で完了させる必要がある場合

上に戻る

ウィザードのべからず集

ウィザードの作成にあたり、回避すべき点をいくつか紹介します。

目的が不明瞭

ウィザードの目的を明確にするには、次の2点が肝要です。1つは、すべての画面に明確かつ簡潔なウィザード・ラベルを付けること、もう1つは、最初の画面に目的に関する短い説明を用意することです。信じられないような話ですが、ユーザーの中には、他の人から言ってもらわなければ、ウィザードを開始することにした理由を忘れてしまっている方もいるのです。Homesite Home Insurance (参考文献を参照) では優れたウィザード機能をふんだんにそろえていましたが、設計者はトップ画面にウィザード・ラベルと趣意説明を含めるのを忘れています（図1を参照）。ウィザードがマイホーム所有者の保険見積もりをユーザーに提供することは、誰の目にも明らかだとはいえません。ユーザーが別のサイトからこのページに直接アクセスした場合には、このウィザードが何の作業を助けてくれるのか理解するのに苦労することでしょう。前もってウィザード・ラベルとウィザードの目的に関する短い説明を用意しておくと、混乱を未然に防ぐことになります。

画面の数が多すぎる

ウィザードをあまり多くの画面に分割しないように気をつけてください。ユーザーは、プロセスが長すぎると感じ始めるとイライラするもので、終了まで我慢できずにやめてしまう可能性もあります。ウィザードは、従来の方法に比べて作業を簡単に完了できるようにするものだということを念頭に置いてください。ウィザードが扱いにくいと感じられれば、ユーザーは往々にして慣れ親しんだ方法をとるものです。新刊のDesigning Effective Wizards: A Multidisciplinary Approach (参考文献を参照) で、著者は、1つのウィザードで画面数を10以下に抑えるよう勧めています。ウィザードをユーザビリティー・テストにかけると、無難な画面数を確認することができます。

ウィザード画面が長い

ウィザードで、ユーザーがデータを入力するのにスクロールしなければならないような場合は、その作業効率が台無しになっています。ウィザードでは、ユーザーはスクロールすることなくデータを入力して、ナビゲーション・オプション(次へ、戻る、あるいは終了など) を選択できなければなりません。長いウィザード画面は、ウィザード・タスクをサブタスクとサブ・サブタスクに十分に分割しなかったことが原因で生じるものです。ウィザード画面が長くならないようにするには、各画面ごとに必ずユーザーが単一のサブタスクを完了できるようにします。サブタスクが著しく複雑であれば、これをさらにサブ・サブタスクに分割して、追加の画面を作成することを検討してください。

代替手段がない

ユーザーが作業を完了する方法が、ウィザードしかないという状況は避けてください。一般にウィザードとは別に、たとえより複雑であっても、同じ作業を完了するための別の方法が存在するべきです。たとえば、Microsoft Word 97では、コーディングせずにWebページを簡単に手早く作成したいユーザー向けに、Webページ・ウィザードが提供されています (図2を参照)。ただし、より経験豊富なWebページ開発者は、ウィザードが提供する機能よりも、さらに高い柔軟性を求めるかもしれませんし、そのためraw codeを使ってWebページを作成したいと考える可能性もあります。もしWebページ・ウィザードを提供するだけだとすれば、Microsoftは、もっと上級のユーザーにひどい仕打ちをしてしまうことになります。

専門用語

ウィザードのコンテンツ(インストラクション、フィールド・ラベルなど) を記述する際には、対象となるユーザーを常に念頭においてください。たいていの場合、ウィザードは初心者ユーザー向けにあるので、作業に関する専門用語にはなじみが薄い可能性もあることを忘れないでください。専門用語を使わないように気をつけ、常に門外漢を意識して表現するよう心がけます。

「取り消し」オプションなし

場合によっては、さまざまな理由で、ユーザーがウィザードを開始してから、それを途中でやめようとすることもあります。脱出法を探しているユーザーのイライラを募らせることのないよう、「取り消し」ボタンをウィザード・インターフェースに用意しておきます。このボタンは通常、他のウィザード・ナビゲーション・ボタンのそばに配置されます。Homesite Home Insuranceのウィザードは、こうした柔軟性をユーザーに提供していませんでした (図1を参照)。

終了する時の警告がない

ユーザーが「取り消し」ボタンをクリックするか、あるいはことによるとウィザードに含まれていない他のナビゲーション・オプションをクリックしようと決めた場合に、その時点までに入力してあるデータが失われてしまうことを知らせる警告を表示してください。中には、後でウィザードに戻って、先ほど中断した地点から始められると考えているユーザーもいます。(そう、これは名案!) データを失う可能性があるということの重大性から、現在のウィザードの結果を知らせて確認を求めるメッセージをユーザーに提示する必要があります。

外部タスク

ウィザードは、まとまっていて順番に進めて完了できるような作業に最も適しています。ユーザーがウィザードを利用する場合、あるタスクを完了させるためにウィザードを一旦終了しなければならないということがあってはなりません。サイト内の別のロケーションから情報を検索することは、外部タスクの例といえるかもしれません。外部タスクは通常、タスク・フローが十分に工夫されていなかった、あるいは作業をウィザードに組み込むために追加の作業を行わなかったことの現れです。外部タスクはまた、まとまりのある順序正しいフローに作業が適していないことを示すこともあり、そのような場合はウィザードが最善の方法とはならない恐れもあります。ウィザードを終了させる必要のある作業はすべて、ウィザードの内部に収めておかなければなりません。

上に戻る

ウィザードのすべし集

この次にウィザードを設計する際、その効果を確かなものにするため考慮すべき事項をいくつかご説明しましょう。

ダウンロード時間を最小限に

ウィザードを利用する人々は、特定の作業をできる限り素早くかつ簡単に終えることに強い関心を示すものです。ウィザード画面を設計する場合は、最低速の、つまり最も一般的なインターネット・アクセス速度を用いていかに迅速にページをダウンロードするかに細心の注意を払います。ユーザビリティーの権威Jakob Nielsenによれば、28.8 bpsでは1 KBのファイルをダウンロードするのに1秒かかるということです。Nielsenの調査では、10秒を過ぎるとユーザーは辛抱できなくなるという結果が示されています (参考文献を参照)。ユーザーが辛抱できなくなってウィザードを終了してしまうことのないように、画面のファイル・サイズは30 KB未満に抑える必要があります。これはつまり、グラフィックスの活用をかなり控えるということになります。

ヘルプを追加

ユーザーが立ち往生した場合や、あるいはウィザードの一部が機能しない場合に備えて、追加ヘルプを利用する簡単な方法を加えておくことをお薦めします。これは、ウィザードのプロセス全体を通して電話番号を表示しておく、といった形でもよいでしょう。予算が許すのであれば、容易にアクセスできるチャット・ヘルプも便利なオプションとなります。1日24時間電話あるいはチャット・ヘルプにスタッフを配置することが不可能であれば、もっと簡単なオプションは各画面にコンテキスト依存ヘルプを加えておくことです。これには、ユーザーがヘルプ・リンクをクリックするとウィザードの隣に表示されるテキスト、あるい第2のウィンドウに表示されるテキストが考えられます。Homesite Home Insuranceのサイトでは、設計者は表示を簡潔にすることを心がけながらも、すべてのウィザード画面に電話番号を加えることで効果を高めています (図1を参照)。

タスクを論理的に分解

効果的なウィザードは、タスクをサブタスクとサブ・サブタスクに分解し、ユーザーになじみのある快適な方法でこれを順序づけます。効果的なタスクの分割は、タスク分析を通じて実現されます。タスク分析が最大の効果を発揮するのは、実際のユーザーが自分の作業場で業務を行うのを観察した場合です。このアクティビティーは、画面設計が開始される前に実施する必要があります。タスク分析の結果には、タスク分解 (概略の形で) とウィザードの情報アーキテクチャーを含める必要があります。タスク概略と情報アーキテクチャーについては必ずユーザーとともに検討し、正確さと完全を期すようにします。タスク分析方法の詳細については、JoAnn HackosおよびJanice Redishの名著User and Task Analysis for User Interface Design (参考文献を参照) をお読みください。

進ちょく状況をユーザーに通知

ウィザードによる作業の区切れごとには、明確な開始および終了ポイントを含める必要があります。ウィザードのユーザーは、こうしたポイントとの相対的な位置関係を知ることができると助かるものです。こうした理由から、多くのウィザード設計者は、ウィザード・インターフェースに何らかの進度メーターを組み込んでいます。進度メーターは、ウィザード・プロセスのどこに位置するかをユーザーに知らせ、終了までにどのくらいかかるのか判断できるようにします。進度メーターには、おおよそのロケーションを示すものもあれば、正確なロケーションを示すものもあります。Homesite Home Insuranceでは、設計者はウィザードの進ちょく状況を知らせるという仕事を見事にこなしました (図3を参照)。Homesiteの進度メーターは、ウィザードにどのくらいのステップがあり、すでにどれだけ終了したか、さらに現在プロセスのどこに位置するのかをユーザーに知らせてくれます。

必要なフィールドを指示

ウィザードは、ユーザーがフィールド・ボックスにテキストを入力する、あるいはドロップダウン・メニュー、ラジオ・ボタン、またはチェック・ボックスで選択を行う必要があるという点でフォームと似ています。オンライン・フォームの場合と同様に、どの項目が必要か必ず指示するようにします。必須フィールドを終えていない不案内なユーザーを、エラー・メッセージでびっくりさせるようなことはしないでください。あらかじめ何が必須であるかについて明確にしておくに越したことはありません。必須フィールドは、特殊記号 (アスタリスクなど) または太字フォントを用いることで示すことができます。カラーは必ずしもモニターに鮮明に表示される、あるいは視覚障害者にはっきり見えるとは限らないので、必須フィールドを示すのにカラーを使わないようにしてください。さらに、必須フィールドがどのように示されているか明確にする注意書きをすべてのウィザードのトップ画面に加えるようにします。

ナビゲーション・オプションを制限

ユーザーがウィザードで作業を進めている場合、当面の作業に意識を集中できるようにしてください。この理由から、ウィザードの外部から提供されるナビゲーション・オプションを最小限に抑えることをお薦めします。しかし少なくとも、そのサイトのホーム・ページに戻るリンクは含めておいてください。それ以上のものをそろえておくと、ユーザーがうっかりウィザードを終了させてしまったとき、データを失う原因となります。

ウィザードのデータを要約

ウィザード・プロセスの終わりにさしかかった時点で、ユーザーはこれまでの画面で入力してきたデータの要約を検討できる必要があります。要約が、ユーザーの提示したい情報を正確に反映している場合は、「終了」ボタンによりウィザードを最終的に完了することができます。「終了」をクリックする前に、ユーザーは、以前の画面に戻り、変更を行い、容易に要約画面に戻ることができなければなりません。ウィザード・プロセスが10画面よりも少なければ (大変結構です)、データを変更できるようにするには「戻る」ボタンでこと足りるはずです。ウィザード・プロセスが長くなれば、特定の画面に戻る直接のハイパーリンクを含めることもできます。

上に戻る

結論

ウィザードは部外者には簡単そうに見える必要がありますが、設計者と開発者はそのように見せるための苦労を知っています。ウィザードを作成するには、数多の計画、試行錯誤をしながらの設計、そして複雑な開発が必要です。テクノロジーが引き続き我々の暮らしのあらゆる側面に入り込んでくるにつれ、ウィザードによって提供される"困難の除去"が、ますますありがたいものになってきます。さらに多くの研究と経験の共有が必要ですが、以上の注意事項が皆さんのウィザード作成技術を高めるきっかけとなれば幸いです。

参考文献

• ユーザビリティーの権威Jakob Nielsenのuseit.com サイトには「Why This Site Has Almost No Graphics」というエッセーが掲載されており、このエッセーでは、ファイル・サイズがダウンロード時間にどのように影響するか説明しています。
  
  
• ウィザードの設計に携わっているのなら、JoAnn HackosおよびJanice RedishによるUser and Task Analysis for Interface Design をぜひご覧ください。
  
  
• Homesite Home Insuranceサイトには、効果的なウィザード設計を考える適例が掲載されています。
  
  
• リリースされたばかりのIBMのDaina Pupons Wickham、Dr. Debra Mayhew、Teresa Stoll、Kenneth June Toley III、Shannon RouillerによるDesigning Effective Wizards: A Multidisciplinary Approach をご覧ください。
  
  
• IBMのEase of Useサイトでは、新たな技術革新、ユーザー中心設計、ガイドライン、エピソード、テクノロジー、他の参考文献を紹介し、皆様の製品とサービスに対する総合的なユーザー体験を高めるお手伝いをしています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ウィザードとは?
• ウィザードを用意すべき場合
• ウィザードのべからず集
• ウィザードのすべし集
• 結論
• 参考文献
• 著者について
• コメント