1. ホーム
  2. ニールセン博士のAlertbox

フレキシブルユーザビリティテスト：
クライアントのニーズにセッションを適応させるための10のヒント

テストする課題が、クライアントの開発チームがすぐに対応策を取る気十分のものなら、参加者のセッション中および参加者間のタスクを柔軟にすることで、取り組んだ内容以上の成果を手に入れることができる。

現在、稼働中の環境やアプリケーションについて、クライアントがユーザビリティテストによる評価を希望することは多いが、そういうときに彼らが求めているのは従来からの総括的なテストである。そうしたテストとは、KPI（成功率やタスク達成時間、エラー数）測定用の少数の固定タスクから成り、1) 課題を見つけ、2) そうした課題を修正するための投資を正当化する根拠を提供すること、を目的としている。

しかしながら、アジャイルおよびリーンメソッドを採用する組織が増えるにつれて、意志決定を一元的に行うことが減り、従来的な指標ベースの根拠がそれほど重要でない場合も出てきている。組織は（社内でできるようになるまでは）ユーザビリティの専門家を雇って、ユーザビリティテストを計画実施したいと、依然として考えてはいるが、「根拠」を挙げて、変更の予算を確保することに以前ほどの関心はない。その代わりに彼らが求めているのは、対応策の取れる調査結果やアドバイスで、自分たちのところの環境やアプリケーションのなるべく広い範囲に当てはまるものである。こうしたニーズに応えるには、以下の方策を取り、テストを柔軟に行うことが極めて重要であることがわかっている：

  • セッション間及びセッション中にタスクを反復すること
  • タスクはその場で作って、カスタマイズし、個々の参加者によりよく適合させること
  • クライアントをリアルタイムで参加させること

（注意して欲しいのは、ここでの「クライアント」とは、単に、ユーザビリティの調査結果を受け、行動を起こす必要のある人、のことである。したがって、あなたがコンサルタントか代理店で働いているのなら、クライアントは従来的な外部コンサルタントかもしれないし、あなたが組織で働いているなら、組織内の利害関係者かもしれない）。

とはいえ、テストを柔軟に行うには、テストガイドを作ったほうがいい。しかし、そこでのタスクは不変の要素としてではなく、出発点として扱おう。

このことのメリットは以下の2点である：

  • モデレーターやプランナーの、初っぱなから完璧なタスクを作成しなければ、というプレッシャーの低減：　タスクは必要なら、テストされることもあるし、変更されることもある、と了解しておけば、ずっと作成しやすい。
  • クライアントのプレッシャーの低減：　クライアントチームのメンバーがユーザビリティテストを実際に見たことがないというのはよくあることだ。したがって、彼らにタスクの最終案を考えさせたり、承認させること、そうしたことが完璧に行われると期待することはばかげている。なぜならば彼らは何がわからないかもわからないからである。しかし、一度テストを観察すれば、タスクのアイデアは次々に浮かぶようになる。

テストガイドの目次サンプル：

  • 調査実行計画（日時、場所、参加者の数、セッション時間、謝礼、モデレーター)
  • 参加対象者の選択基準
  • 調査の目的
  • 調査課題
  • タスク

フレキシブルテストのためのヒント・トップ10

フレキシブルテストを最大限に活用するため、計画、進行、管理という最も重要な側面に焦点を絞り、アドバイスをしたい。

1.　テストの目的と意図を最初に定義しよう

見極めなければならないのは以下の2点である：

  • なぜクライアントはこの調査に資金を出すのか。
  • 結果を利用して、何をするつもりなのか。

クライアントにはこの両方の質問に必ず正直に答えてもらい、彼らの目的と意図を調査手法の選択とアウトプットにどう反映させるかについての話し合いにも参加してもらう必要がある。すべての議論の中で、あなた方が期待に応えることができるかどうかに最も影響する議論がこれである。

クライアントの目的及び意図とテスト手法との適合性
総括的な
テスト		 フレキシブル
テスト
統計的根拠を挙げる ○
変更や予算配分のために経営陣を説得する ○ ○
デザイン戦略を形成する ○
デザイン仕様を導き出す ○
デザイン変更をする ○
既存のデザインやコンテンツの課題を特定したり、優先順位をつける ○ ○
既存サイトの長所を特定する ○ ○
正確不変なテストプランを承認したという「安心感」を調査開始前に得る ○

2.　その調査で答えを出さなければならない質問を具体的に作ろう

一番簡単にテストタスクを考え出す方法とは、その調査で答えを出す必要のある質問をまず考えることである。私も以前は、クライアントに彼らの「ミッションクリティカルなタスク」を尋ねることに力を入れていた。しかし、それだと、考えつくタスクが実際に扱っているものに限られ、テスト属性もクライアントが問題を感じているものに限定されてしまう可能性がある。
目的や意図が明確になったら、クライアントに頼んで、この調査から答えを得たい質問のリストを出してもらおう。以下の質問サンプルを利用して、アイデアを出すのもいいだろう：

ユーザビリティテストで答えを得たい質問の例
（Webサイトやアプリケーション）
ナビゲーション
グローバルナビゲーションはナビゲーションとして認識されているか？
ローカルナビゲーションが[location]で利用されているか？
ナビゲーションシステムを利用して、自分がどこにいるかを知ろうとするか？
商品やコンテンツの発見しやすさ
十分に関連性の高い結果をサイト検索で表示できているか？
概要ページによってユーザーは効果的に経路を辿れているか？
フィルターは利用されているか？ どんな状況で利用されているか？
商品情報
どんな情報が注視されているか？
どんな情報を見つけるのに苦労しているか？
どんな情報が見たいと思われているか？
どんな情報がわかりにくいか？
ユーザーは関連リンクを利用するか？
ユーザーはレビューを見つけようとするか？
決済
決済の方法はすぐに見つけられるか？
必須項目や要求している情報で、不安にさせているものはあるか？
入力フォームを埋めるにあたって、課題はあるか？

3.　質問に答えを出すためにタスクをデザインしよう

必要としていることをクライアントが確実に手に入れられるようにするには、作成するテストタスクで彼らが評価したいサイトの質を明らかにするのが一番である。これは質問ごとにタスクを作成しなければならないという意味ではない。ユーザータスクのシナリオの多くは複数の質問に別々に対処することになるが、重複して対応するものもあると思われる。しかし、それで問題ない。

4.　可能な限り多くのクライアントに観察をしてもらおう

テストは常に可能な限り多くの利害関係者やクリエイター、担当者に観察されるほうがいい。しかし、これはタスクが変更される予定ならなおさらそうである。考える人が増えれば増えるほど、アイデアは集まるし、その後の動きも取りやすくなる。

5.　競合他社の製品をテストプランに組み込もう

可能なら、タスクのうちのいくつかを競合サイトでも実行してもらいたいと考えていると思う。そこにはコンテクストがあるからだ。これは往々にして、「誰々さんがこのやり方なのだから、そのほうがよい」という方向性で動く組織で最も議論を呼びそうなテーマの1つである。どんなユーザビリティ調査であれ、競争相手の製品を観察することの1番のメリットとは、そうした発言の証明や反証を可能にすることにある。2番目のメリットはフレキシブルテスト特有のものだが、自分たちとは異なる環境を利用中の人を観察することによって、タスクのさまざまなアイデアをさらに生み出せることである。

6.　タスクの前に事前質問をして、タスクを即興で作るときに利用しよう

各セッションの開始時に聞く一連の質問を決めておき、参加者をよく理解できるようにしよう。
重点的に聞く質問には以下のようなものがあるだろう：

  • ニーズ： 何を求めているのか。
  • 経験： ある特定の情報/コンテンツ/製品をどのように利用しているのか。
  • 意図： ある特定の情報/コンテンツ/製品をなぜ利用しているのか。
  • 知識： 今回のテーマについて知っていることは何か。

7.　クライアントチームを、モデレーターや参加者と物理的に分離しよう

自分たちのチームもフィードバックや議論には入りたいと考えていると思う。そうすれば、タスクの変更についての提案もできるし、各セッションの間にモデレーター用の質問を作成することもできるからだ。しかし、もし彼らのいるのが参加者と同じ部屋なら、チーム内のやりとりは表情、あるいはメモを渡すことだけに限定される（ところで、こうしたところで参加者が気づかないということはないので、彼らを不安にさせてしまうことはありうる）。一番良いのはクライアントチームにはテストとは別の部屋にいてもらうことだ。これは従来的な「ラボ」セッションやリモートユーザーセッションでも同様であり、理想を言えば、進行役だけが室内にいるべきである。

8.　リアルタイムの参加に関する基本原則を決めよう。そうすれば、テストを妨害することなく支援できる方法がクライアントにもわかる

クライアントチームには、今、何が起きていて、どのようにプロセスを最適化すればメリットが得られるかを伝えよう：

  • このテストは融通が利く、変更を目的にしたものだ、と彼らには伝えよう。
  • そうしている理由を伝えよう。つまり、テストを見ていて、追加のタスクを思いついたり、ある特定の参加者に良さそうな別の機能やコンテンツについて知りたくなってもいいためである（そのサイトを一番よく知っているのはあなた方だからだ！）。
  • 最初のセッション中にタスクの提案や変更をしてはならない。チームには最初のセッションを見ている時、リアルタイムでフィードバックをするのはやめてもらおう。
  • 最初のセッション後、時間をたっぷり（最低1時間）確保して、デブリーフィングをしよう。そこでフィードバックをまとめて、テストプランの変更をしよう。
  • チームの代表者を1人選んでもらい、2回目のセッション開始後、そのメンバーに責任を持って、タスクへの提案をリアルタイムで伝えてもらおう。
  • 彼らに何が有益で何がそうではないかを言おう：
    • ユーザーの意見を聞いてほしいという依頼はしてはならない（たとえば、「このロゴを良いと思いますか？」）。
    • このユーザーにとって有益そうな、扱っている商品に関するアイデアをしっかり教えてもらおう（「このユーザーはゴルフが好きだそうだ。我々はゴルフシューズのシリーズを扱っている。彼女がそのことを知っているかどうか、また、彼女のニーズを満たす1足を見つけることができるかどうかを確認できないだろうか」。
    • 事前テストでの回答や行動をベースに、そのユーザーに合いそうな機能やコンテンツについてのアイデアをしっかり教えてもらおう (「このユーザーはピアレビューばかり見ていたようだ。どうやったらQ&Aのコンテンツへの反応の仕方を見ることができるだろうか」)。

9.　モデレーターとクライアントとのやりとりに、ユーザーがなるべく邪魔されないように気をつけよう

電話会議の技術(たとえば、GoTo MeetingやWebex)を使って、セッションの中継や記録をするなら、そのチャンネルはクライアントチームとあなたとの会話には利用しないようにしよう。携帯電話のメールを（消音にして）使うほうが邪魔にならず、ユーザーの思考回路を乱すこともなければ、彼らが調査チームやクライアントチーム用の情報を目にすることもない。

10.　各セッションの間にデブリーフィングと次回の準備をしよう

各セッションの間には十分な時間を確保して、クライアントチームと話をし、進行や抽出された情報についてのフィードバックをもらって、タスクの変更をしよう。

  • 1つ1つのタスクを再検討し、変更したいことがないか聞こう。
  • やめたいタスクがないかを聞こう。こうしたことが起こりうるのは、たくさんのユーザーが同一タスクで失敗するのをチームが見たときである。そうしたことを2、3回見れば、その時間を使って、より広い範囲の調査をしたいと彼らも考える。
  • 次の参加者のタスクの概要をさっと説明しよう。
  • （自分が進行役なら）自分用のタスクシートを作ろう。プリンターが利用可能なら、それをタイプして清書しよう。とはいえ、時間が迫っているなら、ペンと紙を使って、問題ない。

フレキシブルテストの最大限の活用

フレキシブルテストの手法を採用すれば、サイトの機能をより広範囲で観察することが可能になる。クライアントの質問に答えたり、個々の参加者に適合したものにタスクを調整したり、新しく作成したりするとき、タスクが変更できるからである。この手法が有効な組織とは、ユーザビリティテストから指標を作成することにはあまり関心がないが、すぐに対応可能なアイテムには興味があるところである。

理想的には、こういうふうに変わり続ける行動計画に対応可能で、それを楽しめる、経験豊かなユーザビリティ専門の進行役を使うとよい。ここでは経験が役に立つ。パイロットテストで変更案を試す時間がまったくないため、いきなりうまくやる必要があるからだ。しかしながら、スタッフに経験がないなら、フレキシブルユーザビリティテストの変形版を用いることもできる。そこでは調査全体を反復パイロットテストの訓練の延長ととらえ、タスクとテスト手法を徐々に適切なものにしていく。もちろん、こちらのほうがやり方としては劣る。とはいうものの、これこそが最初は経験がなかった人が、徐々に腕を上げて、熟練したユーザビリティの専門家になる唯一の方法である。フレキシブルテストなら短期間で腕を上げることが可能である。

さらに学ぶ

調査レポート（英文）

関連記事

—

Original image by: Rodolphe Courtier

キーワード