時にはテストユーザーになってみよう

もしあなたがユーザーエクスペリエンスにかかわる何らかの業務に携わっているなら、あるいはウェブサイトやイントラネットのようなユーザーインタフェースを持つ企業を経営しているとしても、ときどきはユーザビリティ調査でテスト協力者になってみるべきである。

こうするための理由は4つある：

• 自分が新しい、慣れていないユーザーインタフェースに苦しむと、平均的な顧客のことをより理解できるようになる。
• 普段のユーザビリティ調査のときのテストユーザーの気持ちがわかるようになる。 タスクに失敗すると、自分のことをどれだけばかで恥ずかしいと感じるかがわかれば、テスト協力者をテスト中に居心地よく感じさせることの重要性を理解するのに役立つ。
• 違う角度からテストを観察することによって、テストの司会者としてのスキルを磨ける。
• 最後になるが、パイロットテストの時間枠を埋める「役立たず」を提供して、実際の調査のための本物のユーザーを捕まえる必要性をなくし、結果的にリクルート費を節約することができる。

パイロットテスト＝緩和されるリクルート条件

ユーザーテストでは、テスト協力者となるターゲットオーディエンスを代表する人々をリクルートする必要があることを、私は過去のコラムで延々としつこく言ってきた。この条件が妥当なテスト結果を得るのに不可欠であることには変わりはない。適切でない人々でテストするというのは、間違った結果を手にすることを意味するからである。

もう一つ繰り返し言ってきたのが、デザイナーはユーザーではないし、ましてや、副社長はユーザーではないということである。実際、あなた方の組織で働いている人は、たとえその人がターゲットオーディエンスのプロフィールの条件を満たしていようとも、知っていることが多すぎて、テストユーザーを代表していると見なすことはできない。（例外：　イントラネットの調査では当然、自分のところの従業員でぜひテストしたいと思うだろう。とはいえ、イントラネットチームやIT部門のメンバーでテストをするのはやめておこう）。

こうした条件を前提にしながら、どうしてあなた方がテスト参加者になることを推奨できるのか。

それは、テストユーザーとして関係者を使うことはパイロットテストでは機能するが、それがうまくいくのはパイロットテストの時のみだからである。

パイロットテストと通常のテストとの違いは、パイロットテストが重視するのはテスト方法の改善のみということだ。ユーザーインタフェースを改善するための、実際のユーザビリティ上の発見を求めているわけではないのである。我々の希望は、テスト自体を改善したいということである。その結果、実ユーザーを連れて来たときに、調査のために与えられた限られた時間内で可能な、最大限の洞察を引き出すことができるようになるからである。

それでも、パイロットテストの協力者としては、代表的なユーザーを使うのがベストではある。なぜならば、そうすることで、そのテスト計画をより現実的に評価することが可能になるからである。例えば、知りたいことが、利用可能な時間に対してタスクの数が適切かどうか、という場合もあるだろうが、内部のユーザーは外部ユーザーよりも相当速くタスクを完了してしまうのが普通である。

したがって、もしターゲットオーディエンスにあたる人を多数リクルートすることが可能であれば、そのまま進めて、彼らのうちの何人かをパイロットユーザーとして「犠牲にすれば」よい。こうすれば、パイロットセッションで得られたいくつかの定性的な結果を実際のユーザビリティの結果として利用することもできる。しかしながら、パイロットセッションと普通のテストセッションの定量データを組み合わせることはしてはならない。2つのテストの間でテストスクリプトを改善するからだ。もちろん、これは重要なことである。

パイロットテストの終了後にテストプランを変更することになると考えてみるとよい。実際のところ、ユーザビリティの専門家としての経験が浅ければ、あるいは、リスクの高い、または注目を浴びるような特定の調査を実施しているのなら、パイロットテストを何度も行い、テストセッション終了後に、毎回、そのテストプランを改善していくべきである。UI設計ではなく調査設計をテストしているからといって、質を向上させるための反復デザインの基本的価値は変わらないのである。

ユーザーテストの倫理

私の知っている限り、我々のユーザーテストについてのトレーニングコースは人間を被験者として扱うときの倫理を取り扱う数少ないものの1つである。

そこでの倫理上の重要な必要条件の1つが、参加者を精神的苦痛から守ることである。「見ればわかるような」コンピューターシステムの利用に繰り返し失敗していたからといって、我々の調査によって人々を憂鬱にしたり役立たずのような気持ちにさせてしまいたいわけではないからである。ユーザーは典型的なユーザビリティ調査で直面する、多数のエラーや誤解をいとも簡単に自分のせいにしてしまう。

もちろん、我々はいつも最初に、「我々がテストしているのはそれのデザインであって、あなたではありません」と言っている。しかし、難しいユーザーインタフェースに取り組んでいるとき、人々はこの点を忘れてしまうことが多い。

したがって、重要なのは、テストの司会者が参加者を居心地よく感じさせるための積極的手段を講じることである。我々の希望は、いつか実際に利用するかもしれない重要なデザインの改良の手伝いをすることを、楽しくてやりがいのあるものとして、彼らに感じてもらうことにある。これは倫理的な義務からだけではない。ユーザーの友人や同僚の中から今後の調査で有力なテスト候補者になりうる人を紹介してもらえるという実用的な面からも有益なのである。

我々のコースでユーザーテストの感情的側面を強調するのは簡単だ。しかし、ユーザーに優しくする必要性を理解させるには、本人が恥をかくこと以上に有効な手段はない。

定期的に役割を変えてユーザーになってみることには明らかにメリットがある。頻度としては2年に1回くらい、そうした経験をするのが良いだろう。しかし、それ以外のときは、たとえ、パイロットテストのためであっても、実際のユーザーに協力してもらうのに勝るものはない。