ユーザビリティテストにまつわる「誤った通念」
ユーザビリティテストについては、いくつかの通念があります。元来それらはある条件下における経験則だったりするのですが、その通念が広く伝搬する過程で、通念を言い表わす言葉が独り歩きしてしまい、誤解を招くこともあります。
「ユーザビリティに関する10のヒューリスティクス (問題解決に役立つ知見) / Ten Usability Heuristics」のオリジナル版 (1990年) を Jacob Nielsen 氏と共に作った人として知られているデンマークのユーザビリティコンサルタント、Rolf Molich 氏が、2013年2月27日に「Usability testing myths」という記事を発表しています。ユーザビリティテストにまつわる「誤った通念 (myths)」がコンパクトにまとめられていて、とても興味深いので、ご紹介したいと思います。
なお、今回ご紹介する「誤った通念 (myths)」は、Rolf Molich 氏が1998年から独自に行なっている「CUE (Comparative Usability Evaluation)」という研究から導き出されたものです。ユーザビリティ評価を比較して見る研究ですが、以下のような形で行なわれています。
- あるひとつの特定のサイトを対象として採り上げて、そのサイトを、複数のチームで別個に (同時期に) 評価してもらう。
- 各チームには経験豊富なユーザビリティ専門家が入り、ユーザビリティテストまたはヒューリスティック評価による評価が行なわれる。
- 評価終了後、ワークショップで評価結果を持ち寄り、比較する。
CUE の主な目的は、ユーザビリティテストで導き出される結果が「再生可能 (reproducible)」か否か (つまり、一定以上の経験を積んだユーザビリティ専門家であれば、同一の対象サイトに対して同じようなユーザビリティ上の問題点を抽出することができるか) を検証することですが、早い段階で既に「再生可能 (reproducible)」ではないという結論に達しているようです (経験豊富なユーザビリティ専門家であっても、得られるユーザビリティ評価の結果にはバラツキがあることが、証明されています)。
これを踏まえ、Rolf Molich 氏の言う、ユーザビリティテストにまつわる「誤った通念 (myths)」を見てゆきましょう。
5つの「誤った通念 (myths)」
1. あらゆる製品において、5人のユーザーにテストすれば、ユーザビリティ上の問題の85％を抽出することができる。
(Five users are enough to catch 85% of the usability problems in practically any product)
CUE では毎回、総計200件以上の問題点が指摘されますが、1つのチームによって抽出される問題点は、30件以下であることがほとんどです (多くのチームは8人以上のテスターをリクルートしてテストしますが、抽出できる問題点の数はこの程度です)。また、問題点の大半 (60％ほど、つまり総計200件とすると120件程度) は、それぞれ1チームからのみ抽出される、という傾向が見られます。
指摘された問題点の総数のうち半数ほど (つまり総計200件とすると100件程度) は、重要 (serious or critical) な問題であると位置づけられますが、これらも「複数のチームから共通して抽出された」わけではありません。
以上から考えると、「5人のユーザーにテストすれば十分」とは言えなさそうです。
Jacob Nielsen 氏の「5人のユーザーにテストすれば十分」という説に対しては、「ユーザビリティテストだけで、ユーザビリティ上の問題点をすべて抽出することは到底不可能。であれば初めからその前提に立ち、5人程度でテストして抽出された問題点をまずは改善して、また5人程度でテストして改善...を繰り返すことで、少しでもユーザビリティを改善してゆく」くらいに考えるのがよいというのが、Molich 氏の考えです。
2. ユーザビリティテストの主目的は、ユーザビリティ上の問題を発見することである。
(The main goal of a usability test is to discover usability problems)
上述のように、CUE の研究結果からは「ユーザビリティテストで、ユーザビリティ上の問題点をすべて抽出することは到底不可能」と言えます。
ユーザビリティテストを実施する主目的は、ユーザビリティ上の問題を発見することよりはむしろ、ステークホルダー、プログラマー、デザイナー、といったプロジェクト関係者に「自らの製品には深刻なユーザビリティ上の欠陥がある」という気づき/実感を与えることである、というのが Molich 氏の考えです。「ユーザビリティを改善しよう」という動機付けを、共に働くプロジェクトメンバーに与えるきっかけとして、ユーザビリティテストという機会を活かそう、というわけです。
3. ユーザビリティテストによる結果は、専門家によるヒューリスティック調査よりも信頼できる。
(Usability tests provide results that are more reliable than those from expert reviews)
「ユーザビリティテストは客観的」「ヒューリスティック評価は主観的」というイメージがあるのでしょうか、このように考える人は少なくないと思います。実際、ヒューリスティック評価が妥当であっても、それがクライアントの意に沿わない場合、「それはあなたの意見でしょう？」と受け入れてもらえなかったりすることもあります。
CUE-4 (2003年)、CUE-5 (2005年)、CUE-6 (2006年) では、ユーザビリティテストを実施するチームとヒューリスティック評価 (Molich 氏は「エキスパートレビュー」と表現しています) を実施するチームを立て、出てきた評価結果を比較しています。両者の評価結果のクオリティにはあまり違いは見られず、むしろ、ヒューリスティック評価 (エキスパートレビュー) のほうが、低コストで良質な評価結果を得られたそうです。
ユーザビリティテストを実施しても、ユーザビリティ上の重要な問題点が見落とされてしまうケースが、CUE でもしばしば見られますが、その理由としては、テスト手法が十分練られていなかったり、タスク設計が不適切だったり、実際のユーザー像に近い人をテスターにしていなかったり…が挙げれれます。少なくとも CUE においては経験豊富と認められたユーザビリティ専門家がユーザビリティテストを実施していますが、それでも、入念なヒューリスティック評価 (エキスパートレビュー) を併用する必要性がある…と Molich 氏は感じているようです。
4. ユーザビリティテスト中に寄せられた肯定的なコメントは、改善行動につながらないので、役に立たない。
(Positive comments in a usability test report are useless because they are not actionable)
ユーザビリティテストの結果には否定的な発見と肯定的な発見がバランスよく存在しているとよい、というのが Molich 氏の考えです (少なくとも25％は、肯定的な発見であるとよい)。
開発する側も感情を持った人間ですので、ネガティブな問題点ばかり挙げられると、うんざりしてきます。肯定的な発見があることで「自ら手がけている設計やデザインは、ユーザーに喜んでもらえる/ユーザーの役に立つものだ」という気持ちが芽生えれば、指摘された問題点も前向きに受け入れられるようになるでしょう。
また、肯定的な発見があることで、ユーザーが欲している機能やユーザーインターフェース (UI) 要素が誤って削除されてしまうことを防ぐ効果もあります。
5. ユーザビリティテストは、誰でも行なうことができる。
(Usability testing can be conducted by anyone)
たしかに、テストすること自体は誰にでもできるのですが、質の高いテストをするには、相応のスキルが求められます。このスキルには、テスターのリクルーティング、タスク設計、テストの進行、テスト結果からユーザビリティを改善するための提案をまとめること、テスト結果や改善提案をステークホルダーに伝えること...などが含まれます。
ユーザビリティテストの限界を知る
上記の「誤った通念 (myths)」を読むと、ユーザビリティテストだけでユーザビリティ上の問題点を抽出することには限界があることがわかります。今回採り上げた記事「Usability testing myths」の中で最後に Molich 氏が言っていますが、「ユーザビリティテストで問題点を抽出し修正すること (cure : 治療) に依存しすぎるのではなく、設計/開発の段階でユーザビリティ上の問題をあらかじめ潰しておくこと (prevention : 予防) が大事」だと思います。そのためには、設計/開発に携わる人 (インフォメーションアーキテクト、デザイナー、プログラマー、など) のユーザビリティのセンス (ユーザビリティに関する直感力や洞察力) を高める必要があるでしょう。
上記「2. ユーザビリティテストの主目的は、ユーザビリティ上の問題を発見することである。」の中で述べたように、ユーザビリティテストには、プロジェクト関係者に「自らの製品には深刻なユーザビリティ上の欠陥がある」という気づき/実感 (「ユーザビリティを改善しよう」という動機付け) を与えるという側面もあります。ユーザビリティテストの限界を知ったうえで、問題点をぜんぶ抽出することにこだわりすぎず、プロジェクト関係者も一緒に参加する形で、素早く、コストを掛けずに、繰り返しやってみる...というのも一考だと思います。