UX DAYS TOKYOオーガナイザの大本さんが執筆した「デジタルプロダクト開発のためのユーザビリティテスト実践ガイドブック」の読書会に参加しました。

マイナビで開催された書籍イベントに引き続き、読書会ではユーザビリティテストに関する学びをさらに深めました。ユーザビリティテストを実践している方々の意見を聞くことで、書籍だけでは知り得なかったユーザビリティテストの奥深さや難しさに気づきました。加えて、難しいユーザビリティテストを組織で実施するためには仲間が必要だということを知ったのです。

ユーザビリティテストには絶大な効果がある

書籍には、ノーマンニールセングループ（NNG）の情報として、ユーザビリティテストを2人で実施すると半分、5人が実施すると80％の問題が明らかになると紹介されています。

はじめは、この事実を信じがたかったですが、ユーザビリティテストに参加した際、開発者が見落としてしまう使いづらさを限られた時間で発見できたので手軽に問題が発見できると実感しました。数字が出てくる研究結果を見ると、つい人は数字に囚われて、5人だけやればいいなどの議論になりますが、それだけ手軽で、かつ重要な問題が明らかになることを伝えていると解説があり、より数字に囚われない考え方を理解しました。

どのプロダクト開発でもテストは実施します。単体テスト、総合テスト、性能テスト、UAT（受け入れテスト）など、各フェーズでテストして、仕様通り実行可能なことを担保するのです。これらのテストを実施していれば、ユーザビリティテストが不要であるように感じていましたが、間違いであることに気づきました。

ユーザビリティテストは、誰でも実施できるが奥が深い

読書会参加者から「被験者が言葉にしない情報を読み解くのは難しい」という意見が出た時、奥が深いのだと感じたと同時に、ユーザビリティテストの難しさが、実施されない理由の一つだと感じました。

ユーザーの思考や感情を知るのはコツがいる

ユーザビリティテストでは、事前に用意したタスクを被験者に実施してもらい、「出来るか」「分かるか」という感情を検証します。被験者はタスクを実施する際、思考発話法を用いて、自分の行動や感じたことを言葉にします。モデレーターは、テストの進行を行い、被験者にどこで悩んでいるかなどの質問をします。記録者は、被験者の行動や表情、仕草などを記録します。

作業自体はルーティンで誰でもできることですが、大本さんから「感情は定性的で、状況によって変わるため、一つのフレームワークで解決することはできません。それが毎回テストをする理由です」という解説を聞いて、ユーザビリティテストが定量的ではなく定性的なテストだから難しいと理解することができました。

効果的なユーザビリティテストを実施するには

ユーザビリティテストは難しいですが、テストのスキルの向上や組織のマインドセットの改善で、効果的に実施することができます。

ユーザビリティテストを繰り返してヒューリスティックを研ぎ澄まそう

ユーザビリティテストを繰り返し行うことで知見、いわゆるヒューリスティック（専門家）の能力も身につけることができます。まずは、UXコンサルタントで世界的に有名な、ノーマンニールセンのヒューリスティック評価は、なるほど！と思う内容が凝縮されていて、知っておくべきだと感じました。

そのほか、書籍には「少なすぎる不要なステップバー」や「購入を希望しているのに必ず会員登録を要求するUI」など、すぐに使えそうなヒューリスティックの例が挙げられています。

また、ヒューリスティック評価を鵜呑みにせずその都度のUIや問題と合わせて利用するべきだと紹介されています。

どのヒューリスティック評価も原則として理解しておきながら、完全ではないことを念頭に置くべきだと感じました。

参加者から「社内で不適切なUIの例を集めているので、それをヒューリスティック評価に活かしたい」という意見がありました。ノウハウを集めることが、まさにヒューリスティック評価の第一歩だと感じました。

気軽にテストと改善を行う環境とマインドにしよう

ユーザビリティの問題は、すぐに分かるものもあれば、繰り返し使うことで分かるもの、ユーザーが使う現場でないと分からないものもあります。

「ユーザーが使う現場でないと分からない」問題があることが腑に落ちなかったのですが、読書会に参加された方が説明してくれた事例で理解できました。

「PCで実施したユーザビリティテストの結果は問題なかったが、実際の検品現場では、検品結果を音だけで判断しており、画面は見られていないことが分かった」ということでした。

図のように、検品中は「ピッと音が鳴っているから、問題なし」と判断してしまい、仮にPCの画面にエラー表示がされていても気づくことは難しそうです。結果に問題がある場合は音を変える方が、検品している人にとっては分かりやすいでしょう。この事例を聞いて、ユーザビリティテストも他のテストと同様、現場の状況に近い形で実施をすることが必要だということに気づかされました。

逆に、「初めてPCで検品結果を表示したときだけ、エラーが表示される」のような凡ミスは誰でも発見でき、実際のユーザーに近い被験者に発見してもらうまでもありません。

ペーパープロトなどの開発初期段階では、廊下テストやセルフユーザビリティテストで凡ミスをカバーし、開発の終盤では実際のユーザーに近い被験者を募って最終チェックを行います。ユーザビリティテストは1回きりではなく、各フェーズで繰り返し行う必要があるのです。

何度もユーザビリティテストを実施するためには、問題を遠慮なく指摘し合える、心理的安全性の高い環境が必要です。ユーザビリティテストの目的はプロダクトの欠陥を発見することであり、決して個人攻撃が目的ではありません。デザイナーや開発者は自身を否定されると、「そんなテストは2度とやりたくない」と感じてしまいます。このような状況になると、ユーザビリティテストの継続は困難です。

ユーザビリティテストを行う文化は共感する仲間づくりから

ユーザビリティテストの方法や持つべきマインドを学んだだけでは意味がありません。1人でユーザビリティテストはできませんし、プロダクトを組織で開発している以上、ユーザビリティテストも組織全体で実施する必要があるからです。

ユーザビリティテストを組織内に取り入れる際には、プロジェクトリーダーなどのステークホルダーに価値を理解してもらう必要があります。「ユーザビリティテストの結果をもとにWEBサイトの使い勝手を改善すると、コールセンターへの問い合わせが減って、派遣社員10人分のコスト削減になり、ユーザビリティテストのコストは2ヶ月で回収できる」など関心をひく説明も重要です。中でも私が特に印象に残ったのは、大本さんの「仲間を増やしましょう」という言葉でした。

デザインに関わっていない部署の人が突然「ユーザビリティテストは価値があるので、是非実施しましょう」と言っても怪訝に思われてしまいます。しかし、共感する仲間が増えていけば、ユーザビリティテストが組織の文化として広がっていきます。ステークホルダーも文化を無視することはできません。

立場にかかわらず、ユーザビリティテストに共感する仲間を増やすことは可能です。私は現在プロダクトのデザインに直接関わっていないため、デザインに関して意見するのは躊躇していましたが、「このサイトが使いにくい」と不満を漏らす人たちにユーザビリティテストについて話すところから始めてみようと思います。