ユーザテストから得られる現実行動

人工的な状況であるにも関わらず、ユーザテストは現実的な結果を出す。それはユーザのタスクに対する強い集中力と、ウソ臭さの許容によるものだ。

ユーザテストが実用的なのは、奇跡に近い。カメラで撮影されている部屋に人を連れてきて、見知らぬ人たちに囲まれながら、みすぼらしいウェブサイトで難しいタスクを行うようにいう。また多くの場合、片方の壁一面に圧迫感のあるマジックミラーが張られている。タスクがどんな内容であろうと、そのような条件の中、どうすればそのタスクを成功させられるといえるのだろうか。

これまで行ってきた全てのユーザテストで、人々がウェブサイトなどのユーザインターフェイスをそのようなテストセッション時に使用することが可能で、実際にユーザはそれを使い、そこから貴重なユーザビリティの発見を行えることを、私たちは身をもって体験してきた。どうしてそれが可能だったのだろう。

主な理由は、高い集中力と、ウソ臭さへの許容の 2 つだ。

ユーザの集中力

テスト参加者は、タスクを行うようにいわれると、普通はインターフェイスを使いこなすことに夢中になり、ユーザビリティラボ内にある障害の影響が低下するのだ。ユーザはそこにカメラがあり、もしかしたら鏡の向こう側にはさらに観察者が隠れているかもしれないということを承知しているが、彼らの意識は画面に集中されているのだ。

タスクに成功したいと思うのは、人間の基本的な欲望だ。いくらでも「あなたをテストしているのではなく、システムをテストしているのです」と説明できる。それでもなお、ユーザたちは自分自身がテストされているように感じ、成功したいと思うのだ。彼らは、コンピュータなんかに負けたくないのだ。

成功したいと思う気持ちから、ユーザは思考リソースを、部屋で何が起きているかよりも、画面で何が起きていることに割り当てる。もちろんこの集中力は簡単に途切れてしまいかねないものであるため、ユーザと同じ部屋にいる場合観察者たちは一切音を立てないということは、ユーザテストを行う上での基本だ。私は、上等なユーザビリティラボを使った時、ユーザの集中力が天井のレール上をカメラが動く音によって、途切れるのを見たことがある。そのようなことも避けたほうがよいだろう。しかし、一般的にいえば観察者たちが静かで、(ユーザの背後や、鏡の後ろなど)視界に入らない場所にいれば、ユーザたちはタスクに対する集中力を維持し続ける。

ユーザの強い集中力による欠点の 1 つは、テストセッションで実環境よりも頑張ってしまうことがあるということだ。もしユーザが「ここまでで私だったらあきらめる」と言った場合、テストでなければその数画面手前であきらめると思ったほうがよいだろう。

ウソ臭さの許容

ユーザテストでは、人々を彼らのオフィスや自宅から引きずり出し、こちらで作ったデザインであたかも日常業務や個人的なタスクを行っているようなフリをしてもらう。明らかに人工的なシナリオだ。

完全なユーザビリティのライフサイクルの中で、フィールドスタディーを行い、日常環境の中でのユーザ行動を観察することには、十分すぎるほどの正当性がある。しかし、残念ながらフィールドスタディーは、ラボでの調査よりもはるかに高くつき、よその会社内で調査を行う許可を得るのは、至難の業なのだ。デザイン行程内のユーザビリティ評価段階ではほとんどの場合、ユーザテストが行われる。ユーザたちが、ラボの人工的な環境大体においてに適応でき、家にいるふりができるのは、私たちにとって幸運なことなのだ。

ウソ臭さを許容できる傾向は、人間の性質として深く根付いているもので、原始人たちが火を囲み物語を語らい、宗教儀式を行う手助けになった。現代では、Star Trek のようなテレビ番組でしか、もうこの傾向の効果を見ることはできない。Star Trek を見ているときの嘘の数を数えてみよう。

  • 人物を、見ているのではない。ブラウン管上の光る点でできた、人物のを見ているにすぎない。
  • 本物の人物の絵を見ているのではない。Mr. Spock や Picard 艦長など、実在しない人物を演じている役者の絵を見ているに過ぎない。
  • 役者が転送機を使い、フェイザーを撃ち、光速を越えるスピードで飛ぶ宇宙船で飛ぶのを見ているのではない。全て特殊効果で作られたものを見ているに過ぎない。

これらのことを知りながら、番組を見ている人は物語に引き込まれる。

同じようにユーザビリティ調査でも参加者は、あたかも用意されたシナリオが本物で、そのデザインを実生活で使っているフリを簡単に行えるのだ。当たり前だが、このような現象を引き起こすには、リアリスティックなテストタスクを用意し、そのタスクを行う可能性が実際にあるような、典型的なユーザをリクルートする必要がある。この 2 つができれば、参加者のほとんどは、ウソ臭さを許容し、出されたタスクを行おうと試みる。

ウソ臭さの許容によるユーザの集中力の強さは、ユーザインターフェイスがただの紙であるペーパー・プロトタイプでさえ、テスト可能にする。目的に向かって画面の中を突き進むことができれば、そのシステムがシュミレーションされたものでなくとも、あたかも本物であるような行動をとれるのだ。

実の所、時にはウソ臭さを許容しすぎ、自ら役者になって他のユーザのポテンシャルでテストを行ない始めてしまうことがある。ユーザが「人によっては」行うこと、知らないことについてしゃべりはじめた場合、直ちにそれをやめさせなければいけない。礼儀正しく、そのテストに他のユーザも沢山参加していて、彼らを呼んだのは、彼ら各自の体験がそのプロジェクトにとって大切だからだということを伝えよう。または、そのようなユーザには、「自分自身」になり、「自分が知っていることが、そのユーザの知識」だと仮定し、自分自身がいつも行っている業務の中でそれを使うように、と言うこともできる。

集中できず、ウソ臭さを許容できなかった場合

ユーザテストは、普通は機能するが、例外もある。たまに参加者が怠けて、ウソ臭さを許容せずにタスクに実際取り組んでいるとはいえないほど、集中してくれない場合がある。例えばそのようなユーザに、問題を解決してくれる製品を選ばせると、実際にタスクで設定された問題を抱えているならば絶対に買わないような、根本的に適していないものであっても、関連性が少しでも見られる最初の製品を見つけた時点でタスクを終えてしまうことが多い。

まれに非現実的な観測は、結果に重大な欠陥を導いてしまうため、その参加者を帰し、そのセッションで採取されたデータを捨てなくてはいけなくなる。ユーザがウソ臭さを許容し、テストに協力的でない限り、そのユーザのとった行動全てを現実の使用を反映したものだと認めるわけにはいかないのだ。

もっと一般的なケースでは、そのような状況になっても現実的な使用に軌道修正するためのテクニックを、いくつか使うことができる。

最も一般的で、簡単な方法は、日常業務(または消費者向けであれば日常生活)でも同じことをするかと質問することだ。ユーザの集中力を高めるには、多くの場合このようなちょっとした注意だけで十分だ。このテクニックのバリエーションをいくつかあげておく。

  • 判断をするに足りる情報が得られたか、質問する(関連性が少しでも見られる情報を見つけた時点で、探すのをやめてしまった場合)。
  • 最適な製品を選んだかどうか、質問する(購入候補に入れられる製品を見つけた時点で、探すのをやめてしまった場合)

もしセッションはじめの数タスクで、ユーザにタスクをまじめに行ってもらえなかった場合、タスクの内容またはタスクの指示を変えることによって、そのセッションを救済することが可能なことがほとんどだ。例えば「最適な解決法を見つけるだけでなく、その選択を上司に対して正当化しなければいけないと思ってください」といったような言葉をつけ加えるだけで、十分なことが多い。

その場にはいない上司をテストシナリオに組み込むことによって、ウソ臭さの許容を促し、普通は機能するようになる。また、それ以外にも「その製品の利点と欠点を 5 項目、上司に説明するために箇条書きを作ってください」と言うのも、効果的だということがわかった。(利点と欠点を 3 項目ずつでもよい。)

企業ウェブサイトの投資家向け情報のテストでは、このテクニックのバリエーションの 1 つを使い、金融アナリストや個人投資家に、その企業が市場平均よりよくなるかどうか判断してもらい、主な理由を述べてもらった。

または、ユーザが感情移入できるように、制限を設けることができる場合もある。例えば私たちは、事務用品を扱うeコマースのサイトをテストしたことがある。プリテストの管理者アシスタントに与えられたタスクは、新人用の事務用品一式を購入することだった。不幸にも、このプリテスト参加者は、架空の新人にとても親切で、一番高級なペンや椅子を購入したのだ。この場合でも、上司へ報告義務があると思ってタスクをやってもらうこともできたが、その代わりに予算制限を設ける方法を選んだ。ユーザに各商品を注意深く検討させるには、これだけで十分で、私たちは商品クオリティーと商品価値を彼らがどのようにして評価するか、観察することができた。

ユーザテストの人工的な性質にも関わらず、私たちは現実ユーザにとってインターフェイスの価値が無になってしまうようなデザイン欠陥を、簡単に見つけだすに十分足りる現実使用を観察することができるのだ。何かを実際に使うことができるのは、体験としてとても強いもので、ほとんどのユーザはよいデータを提供してくれる。そうならなければ、ユーザに軽く注意を与えるか、タスクに少し変更を加えることによって、ユーザの集中力を引き出すことができる。

2005 年 2 月 14 日