こんにちは、Wantedly Advent Calendar 2024の16日目を担当する上山です。ウォンテッドリーのVisit Growth SquadというプロダクトグロースチームでPdM（プロダクトマネージャー）をしています。Visit Growth Squadでは、日々ユーザーに価値あるプロダクトを届けるために、デザイナーやエンジニアと協力してプロダクト開発を行っています。

今回は、プロダクト開発の過程で実践しているユーザビリティテストについてお話ししたいと思います。ユーザビリティテストに興味がある人、これからやろうと思っている人のヒントになれば幸いです。

ユーザビリティテストとは？

ユーザビリティテストとは、実際のユーザーがプロダクトをどのように利用するかを観察し、プロダクトの課題を明らかにする手法です。

プロダクトチームは自社のプロダクトに精通しているため、つい思い込みで機能を作ってしまったり、ユーザーが実際に直面する問題を見落としたりしがちです。ユーザビリティテストでは、ユーザーの利用状況や行動を把握することで、自分たちでは気づけなかった課題を特定できます。

ユーザビリティテストの活用シーン

実際のプロダクト開発の中でユーザビリティテストを活用するシーンは大きくわけて2つあります。

• 課題を探す時
• • ユーザーが感じているプロダクトの課題点を明らかする
• ソリューションの質を高めたい時
• • ユーザー課題を解決できるUIや機能を作れているのか？
  • 意図した通りのユーザー行動の変化をもたらしているか？
  • ユーザーにとって使いやすい機能になっているか？

この記事では、「ソリューションの質を高めたい時」に実施したユーザビリティテストを基にお話しします。

なぜPdMがユーザビリティテストをやるのか？

ユーザビリティテストは、ユーザーがプロダクトを実際に利用する様子を観察し、問題点を早期に発見・修正するための手法です。これにより、表面的なデータでは得られない深い洞察が得られ、ユーザーの真のニーズや課題を理解する助けになります。

「意図通りにユーザーの行動を変化させているのか？」「使いやすいと感じてもらえる設計になっているのか？」といった問いを持ちながらテストに取り組むことで、UIや機能のユーザビリティを改善できます。

さらに、ユーザーの行動やニーズを直接把握することは、一つの機能改善にとどまらず、プロダクト全体の方向性を決めるうえでも欠かせません。PdMが直接関わることで、ユーザー理解が深まり、プロダクトに対する自信を持てるようになります。プロダクトをより良いものにするために、ユーザビリティテストは非常に有効な手段といえます。

ユーザビリティテストのやり方

ここからは実際に行ったユーザビリティテストのプロセスについてお話しようと思います。

事前準備

目的を明確にする

ユーザビリティテストを実施する際は、まずその目的を明確にすることが重要です。ここで大切なのは、目的をしっかりと文章化しておくことです。ユーザビリティテストでは目的以外の課題が見つかることも多いため、いつの間にか目的から逸れた検証をしてしまうことがあります。

目的は、誰でも確認できる場所に記載し、常に見える状態にしておくことをおすすめします。これにより、関係者全員がテストの方向性を見失うことを防げます。また、目的が複数ある場合には、優先順位を設定するようにしましょう。「どれが一番重要か」を明確にすることで、テストの目的をブレさせることなく進められます。

比較対象を定義する

比較対象は「Apple to Apple」の原則に従い、同一条件で評価するようにします。この原則は、現行のUIと変更を加えたUIを比較する際に、変更対象以外は同じ条件やシナリオで評価することを意味します。

大事なのは、変更対象を 1 つに絞ることです。例えば、UIと機能の両方に変更がある場合、どちらがユーザー行動に影響を与えたか判断が難しくなります。同じ条件を揃えた上で 1 つの検証に集中することで、改善の効果を明確に把握でき、信頼性の高い結果を得られます。

ここを間違えるとユーザビリティテストの信頼性を大きく左右するため、注意しながら設計しましょう。

ペルソナを定義する

被験者に成り切ってもらうためのペルソナを定義します。ペルソナは、その機能を作る目的からターゲットユーザーを抽出し、具体的な人物像として書き出します。ただし、テストの目的によっては、ターゲットユーザー以外の中で、ユーザー体験が悪化する可能性のある人物をペルソナとして設定する場合もあります。

ペルソナ定義のコツは、その人の置かれている環境を示すことと、必要のない情報は外すことです。あくまで被験者に説明した際に、具体的な人物像をイメージできることが目的なので、関係性によっては「xxxさんみたいな人」という伝え方でも問題ありません。

私の場合、以下のような項目で書き出しています。

• あなた
• • 中途採用担当者
  • 全職種の採用を1人で担当している
• 所属企業
• • 都内のスタートアップ企業
  • 従業員数50人
  • 飲食業界のDX事業
• 採用したい人
• • フロントエンドエンジニア
  • 採用人数 : 1人
  • 欠員補充
• やりたいこと
• • スカウト機能を使って求職者にスカウトメッセージを送りたい

このペルソナ設定から、マルチタスクで多忙な採用担当者であることや、採用ニーズの緊急性が高く、スカウトメッセージで積極的にアプローチしたいタイミングの可能性が高いということがわかります。このように、ペルソナを具体的に設計することで、被験者が役割に入り込みやすくなり、より実践的で信頼性のあるテスト結果を得られるようになります。

ゴールまでのタスクを書き出す

実際に被験者に実施してもらいたいタスクを書き出していきます。これにより、テスト中に被験者が予期しない行動を取った場合に、どのタスクに問題があったのかを評価しやすくなります。また、事前にタスクごとにユーザーが迷いそうな部分の仮説を立てることで、重点的に観察したい箇所を把握できます。

先ほど定義したペルソナで想定したタスクを書き出してみました。

• 被験者への指示
• • 希望勤務地に東京が含まれる、経験年数3年以上のフロントエンドエンジニアのスカウト候補者を1人見つけてください。
• 想定しているタスク
• • スカウト検索画面を開く
  • スカウト検索条件を入力する
  • 検索結果の一覧を見る
  • 気になる候補者のプロフィールを見る
  • …

プロトタイプを準備する

書き出したタスクを元にプロトタイプを作成します。プロトタイプは実際の機能として動作するものが最も理想的ですが、UIのテストを行う場合には、Figmaなどのデザインツールで作成したプロトタイプを使用するのも一般的です。

Figmaのプロトタイプを使用する際は、実装された機能ではないため操作に制限があるということを事前に被験者に伝え、操作に対する不安を軽減することも大切です。

被験者のアサイン

実際にテストに参加してもらう被験者を集めます。理想的には、定義したペルソナに近いユーザーに依頼することが望ましいですが、弊社のように社内にもユーザーがいる場合は、社内メンバーに依頼することも多いです。

社内メンバーはプロダクトを使い慣れているというデメリットがありますが、ソリューションの評価を目的とする場合、それ以上にスピード感を持ってテストを実施することを重視しています。また、心理的ハードルが低いため、はじめてユーザビリティテストを実施する際には、社内メンバーや友人・知人に依頼してテストを行うことをおすすめします。

ツールの準備や担当決め

• ツール準備
• • テストの際には、録画可能なビデオ会議ツール（弊社の場合はGoogle Meet）とドキュメントツールを用意します。ビデオ会議ツールを使用して、被験者に操作画面を共有してもらいながら実施することで、効率的に進行できます。私の場合、オフラインでのテストでもGoogle Meetを繋いで実施しています。
• 担当決め
• • テスターは、ファシリテーション担当と観察担当の2人体制で実施するのが望ましいです。1人ではファシリテーションと観察を同時に行うのが難しく、3人以上では被験者の緊張感が高まり、テストに影響を与える可能性があるためです。

スケジュール設定

必要なものが揃ったら、スケジュールを組みましょう。スケジュールを組む際は、以下の点を意識すると効率よく進められます。

• タスク量を考慮して、テスト実施時間を決める（30分〜1時間程度）
• • 被験者の負担を考慮し、長時間の場合は休憩を挟むなどの配慮を行う
• テストは連続して行わず、1回実施するごとに評価の時間を設ける
• • 記憶が新しいうちに評価を行うことで、スピード感を持ってテストに取り組むことができます。また、時間を空けることで、プロトタイプに欠陥があった場合や軽微な修正を行う時間も確保できます。

テスト実施

実際のアジェンダどおりの流れを説明していきます。

アイスブレイク

軽い雑談や、「普段はどのようなサービスを使っていますか？」といった質問でスタートすることで、被験者の緊張感を和らげます。慣れた作業でも、テスターに見られながら行うと緊張から普段と異なる行動をしてしまうことがあります。そのため、必要以上に緊張しないように場を和ませる能力がテスターには求められます。

ユーザビリティテストの説明

被験者は初めてユーザビリティテストを体験する方も多いため、テストの目的を共有し、具体的に何をしてもらうのか、どのくらいの時間で行うのか、終了予定時刻などを伝えることで全体の流れをつかんでもらいます。また、録画への同意や注意点もこのタイミングで伝えます。

ペルソナの説明

事前準備で定義したペルソナを説明します。文章だけでなく、「xxxな環境でxxxをしている人はおそらく忙しくて...」といった具体的な状況を口頭で伝えることで、より人物像をイメージしやすくなります。何より重要なのは、被験者がそのペルソナになりきれる状態にすることです。

その機能でやってほしいことを伝える

ペルソナの説明から一転して、実施してほしい行動を簡潔に伝えるようにします。やり方を連想できるような情報を提供したり、行動を誘導したりしないように注意が必要です。

テストの実施

実際にテストを行います。被験者に画面を操作してもらい、その行動を観察していきます。

テスト時の注意点

• 思ったことを口に出して話してもらう
• • 被験者には思ったことをできるだけ口に出して話してもらいましょう。この声が、私たちが見えていない改善点を見つけるきっかけになります。例: 「このボタンは何だ？」「え、操作できない」「これ簡単だな〜」など
• テスト中は極力声をかけない
• • 被験者から質問された場合は、「気になった理由を教えてください」と問いかけ、回答はしないようにします。操作ミスがあった場合でも、しばらく見守り、どうしようもなくなったら手助けします。

振り返り

テストが完了したら、被験者に感想や意見を尋ねます。ユーザビリティテストや操作してもらった機能について、定性的な意見を聞いていきます。また、UIや機能に対する満足度を、「とても良かった」「良かった」「どちらでもない」「悪かった」「とても悪かった」の5段階で評価してもらうと、満足度の軸で評価しやすくなります。

評価

ユーザビリティテストが終わったら、できるだけその場に同席したテスターと共に振り返りと評価を行います。まずは定性的に、テスト中に被験者の行動や発言から気づいたことをできるだけ書き出しましょう。ここで書き出した内容に加えて、実際のユーザーの行動を、国際規格のISO 9241-11で定義されたユーザビリティ評価軸である「有効さ」「効率」「満足度」に基づいて評価します。

• 有効さ
• • ユーザが目的達成する際に、正確さと完全性に費やした資源
  • 例 : 全体・タスク毎の成功率、課題が解消されているか。
• 効率 
• • ユーザが目標を達成する際に、正確さと完全性に費やした資源
  • 例 : 成功までの操作数や時間、迷った回数などを定量化
• 満足度 
• • 製品を使用する際の、不快感のなさ、および肯定的な態度。
  • 例 : UIや機能に対しての満足度を5段階評価するなど、定性意見を活用

検証したい内容によって、これらの評価軸のどれを重視するかは異なりますが、多くの場合は「有効さ」や「効率」を中心に評価することになります。現行のUIと変更後のUIを比較し、どの指標が満たされていないかを可視化し、先に書き出したメモと照らし合わせながら課題のある箇所を特定します。そして、これらの課題に優先順位をつけて対応策を考えていきます。

課題への対応

誰が見ても修正すべき箇所については、次のテストまでに修正するようにしています。修正すべき箇所をそのままにしてテストを続けると、どの被験者も同じ箇所でつまづき、他の課題を見落とす可能性があるからです。また、スピード感を持って改善を進めるためにも、修正が必要な箇所には早めに対応します。

その一方で、特定の被験者にのみ発生した再現性の低そうな課題については、複数回のテストを通じて確認するようにしています。また、こうした課題については、振り返り時に被験者から定性意見を聞くことで、ユーザーがなぜその行動を取ったのかをより深く理解し、解決すべき課題か判断します。

このようにユーザビリティテストの評価は、定量的なデータと定性的な意見の両面からアプローチすることで、効果を最大化できるのです。

ユーザビリティテストの落とし穴

ここまでユーザビリティテストの方法をお話してきましたが、最後にユーザビリティテストで陥りやすい点について話そうと思います。

すべての課題を網羅できるわけではない

ユーザビリティテストは、N=1の行動観察を繰り返し行うことで課題を特定するテスト手法です。そのため、アサインした被験者によって結果が偏ることもありますし、何十人とテストを実施しても見落としが発生する可能性があります。これを踏まえ、ユーザビリティテストはあくまで定性調査の一手段と捉えて実施することが大切です。

被験者の発言ではなく、行動を見る。ただし、行動もすべてが真実ではない

ユーザビリティテストの基本は、ユーザーの発言ではなく行動を観察することです。しかし、テストの際には、普段とは異なる環境でテスターに見られながら行動するため、緊張などが影響し、通常とは異なる反応を示すことがあります。難しいポイントではありますが、迷った場合は複数人の行動を観察するなどして、臨機応変に判断する必要があります。

本番環境との差分により判断を誤ることも

Figmaなどのデザインツールを使用したプロトタイプでは、実際の環境とは異なる挙動が見られることがあり、その違いが判断を誤る原因になることがあります。これを避けるために、本番環境との違いを十分に理解しておくことが重要です。

最終的なUIや機能に責任を持つ

ユーザビリティテストの結果を基に改修したUIや機能について、最終的に「これで良いのか？」という判断は必ず自分自身で行うようにしましょう。ユーザビリティテストで得られた多くの意見や行動を反映させた結果、機能が「キメラ的」になってしまうことがあります。テスト結果をそのまま反映させて「完璧」とするのではなく、目的に沿っているか、機能が必要最低限か、また特定の利用者に対して体験の悪化を招かないか、などの視点から最終的な判断をすることが重要です。

最後に

ユーザビリティテストは、さまざまな要因によってうまく評価できないことがあります。最初から完璧に出来ることはほとんどないため、毎回テスト結果の評価だけでなく、実施したテスト自体を振り返ることが重要です。そうすることで、自分に合ったやりやすい進め方の「型」が見つかるはずです。また、うまく評価できなかったテストが無意味だというわけではなく、別の機能を開発する際に、過去のテストで得た被験者の行動や発言が役立つこともあります。ユーザビリティテストを繰り返し行うことで、ユーザーへの理解が深まり、より質の高いプロダクト開発ができるようになるはずです。

この記事を読んで、ユーザビリティテストを実践してみようと思う方がいれば嬉しいです。最後までお読みいただき、ありがとうございました。