成功率：
もっとも単純なユーザビリティ指標
ユーザビリティの数値指標は、測定するのにお金がかかるだけでなく、デザイン上の判断に役立つ定性的洞察を集めるという目的の妨げにもなる。この妥協策としては、ユーザのタスク達成能力を測定するのがいいだろう。成功率は理解しやすく、ユーザビリティの総決算と考えることができる。
数字は説得力抜群だ。ユーザビリティ調査の結果を一般大衆に伝えるには、これがもっとも簡単なやり方である。例えば、「Amazon.comはEコマース・ユーザビリティ・ガイドラインの72％に適合している」と言う方が、「Amazon.comはユーザビリティが高いが、まったく抜けがないというわけではない」と言うよりも明確な言い方だ。
以前のAlertboxで、タスク達成時間のようなユーザビリティ数値指標の測定と比較の方法について論じた。こういった数値測定は、長期的なプロジェクトの成長を計る上で非常に有益だ。例えば、「サイトのユーザビリティは、最低でも年20％以上向上しているか？」といった使い方ができる。さもなければ、競争相手にも、また、今後新たにネットに参入してくる技術にうといユーザにも遅れをとることになるだろう。
残念ながら、数字への要求と、洞察への要求は矛盾することがある。ユーザビリティの現状を伝え、改善を要求する上で数字は役に立つが、本当のユーザビリティの目的はデザインの方向性を決定するところにある。報告書やプレゼン用の数字を作り出すためではない。さらに、ユーザビリティ・テストのもっともよい方法は、数値測定の要求と矛盾するものなのだ。
大規模な調査をわずかな回数やるのではなく、頻繁に小さなテストを繰り返すのが、ユーザビリティ・テストのベストの方法だ。4～5ユーザを対象にして、テストの間中、考えたことを口に出して言ってもらう。ユーザが見つけた問題は、（どれくらい悪いかわかるまでテストを続けるのではなく）すぐに修正する。その後、今度はその「修正」で問題が解決できたかどうか、またテストしてみよう。
小さなテストでは、デザイン改善のための洞察がたくさん得られるが、この種のテストでは、伝統的な測定規準に要求される狭い信頼区間を達成することはできない。ユーザが何を考えているかを知り、彼らにぴったりのデザインにするにはどうしたらいいか理解するには思考発話法が一番だが、思考を言語化するのに余計な時間がかかるため、タスク時間の測定に影響を与えてしまう。
よって、最良のユーザビリティ方法論が、詳細な数値を得るにはもっとも不適格な手法ということになる。
成功率の測定
数字を集めたい人に、ぜひお薦めしたい非常に単純なユーザビリティ指標がある。それは、ユーザの成功率だ。私はこの数字をユーザが正しく達成できたタスクのパーセンテージと定義している。確かにかなり大雑把な指標ではある。この数字からは、どうしてユーザが失敗したのか、あるいは、達成できたタスクはどの程度うまくできたか、といったことは何もわからない。
しかしながら、成功率がいいと思うのにはわけがある。それは、数字が収集しやすく、また非常に有効な統計だからだ。つまるところ、ユーザがターゲットタスクを達成できなければ、それ以外がどうであろうと関係ない。ユーザ成功率は、ユーザビリティの総決算なのだ。
成功率は、簡単に測定できる。ひとつだけ難しいのは、部分的な成功をどう考えるか？という問題だ。タスクの一部は達成できたが、それ以外で失敗したという場合、これをどう算定するか？という問題である。
例えば、黄色いバラを12本、母の誕生日に配達してもらうよう注文するというタスクがユーザに与えられたとしよう。本当の成功と言えるのは、まさにそれ自体、つまり誕生日に1ダースのバラを受け取ったお母さんである。これが現実となるようにして、テストユーザがサイトを後にした場合、このタスクは確かに成功だったと言えるだろう。もしユーザが何も注文できなかったら、このタスクが失敗だったと判断するのは同じくらい簡単だ。
だが、その他にも可能性がある。例えば、ユーザは…
- 12本の黄色いチューリップや、24本の黄色いバラや、あるいはそれ以外の見当違いのブーケを注文するかもしれない
- 配達先の指定を間違って、請求先である自分の住所に花が配達されるかもしれない
- 住所はあっていても、日付を間違うかもしれない。あるいは…
- 他のことはすべてうまくできたのに、配達物に添えるギフトメッセージを入れ忘れ、誰から来た花束なのか、お母さんは首をかしげることになるかもしれない
いずれのケースも、程度の差はこそあれ、何らかの意味で失敗といえる（ただし、1番目のケースでは、ユーザは、バラの代わりに、意図的に例えばチューリップを要求したわけだから、これを成功に数えることもできる）。
ユーザが指定されたとおりのタスクを達成できなかったら、厳格に失敗と数えることもできよう。これは確かに単純なモデルだ。ユーザはすべてをきちんとこなすか、あるいは失敗か。中間はない。成功は成功、条件などない。
だが、私は部分的に成功したタスクを部分的な得点と見ることが多い。何もできなかったユーザと、かなりのタスクを達成できたユーザを同じ得点（ゼロ）にするのは、あんまりだと思うからだ。部分的成功をどれくらいの得点にするかは、ユーザ・エラーの度合いによる。
花の例で言えば、正しく注文できたがギフトメッセージを忘れた場合を80％、間違った花を注文したり配達日を間違えた場合を50％の得点とする。配達先を間違えた場合、わずか25％の得点にしかならない。もちろん、正確な数字はドメイン分析によって変わってくるだろう。
部分的な成功にどれほどの得点を与えるかを決めた確固たるルールはない。部分的な得点は見積りに過ぎないが、それでもこの方が、成功か失敗かの絶対的アプローチよりは、現実的なデザイン品質を示唆してくれるだろう。
ケーススタディー
下記の表は、私が最近行った調査でのタスク成功データを示したものだ。ここでは、かなり大規模なコンテンツサイトを対象に、4人のユーザに6つのタスクを行ってもらった。
| タスク1 | タスク2 | タスク3 | タスク4 | タスク5 | タスク6 | |
|---|---|---|---|---|---|---|
| ユーザ1 | × | × | ○ | × | × | ○ |
| ユーザ2 | × | × | △ | × | △ | × |
| ユーザ3 | ○ | × | ○ | ○ | △ | ○ |
| ユーザ4 | ○ | × | ○ | × | △ | ○ |
凡例： ○＝成功、△＝部分的成功、×＝失敗
合計で、複数のタスクに対して24回の試行を観察した。このうちで、成功は9件、4件が部分的成功であった。このサイトに関しては、部分的成功を半分に数えた。一般に、ある種のエラーを特に高得点にしたり低得点にしたりする理由のない限り、50％の得点にしておくのがいいだろう。
この例では、成功率は(9+4*0.5)/24 = 46％となった。
そのサイトがどれくらいユーザをサポートできているか、有効なサイトにするにはどれくほどの改善が必要かといったことを大まかに知るには、単純化した成功率が見るのが一番だ。こういった数字は、あまり細かいことにこだわってもしかたがない。観察数が少なく、部分的成功の得点も大まかな見積りであるような場合には、なおさらそうだ。例えば、あなたのサイトの得点が46％、他のサイトが47％だったとしても、必ずしも向こうの方がいいサイトとは限らない。
気持ちのいい話ではないが、成功率46％という数字はまったく珍しい数字ではない。実際には、ほとんどのサイトが50％以下の得点しか出せないのだ。ということは、平均するとインターネット・ユーザは失敗ばかり経験しているということになる。ウェブ上で初めて何かをやろうとしたユーザは、たいてい失敗するのだ。
数値指標だけでは、このジレンマは解決できない。だが、よりよい、より使いやすいデザインにどれだけ近づいているかを知るひとつの手段としては役に立つだろう。
2000年2月18日
