UXデザインでは、対象となるサービスにおけるユーザー体験への理解が不可欠です。
その中の1つの手法である「ユーザビリティテスト」について解説していきます。
ユーザビリティテストはUXの設計、改善に必須のプロセスです。その上で、UXデザインについて網羅的に知りたい方には以下の記事がおすすめです。
ユーザビリティテストとは
ユーザビリティテストは製品やプロトタイプなどを実際にユーザーに使ってもらい、意図した使われ方をするのか検証することで現状の課題を見つける手法です。
例えば、あるお題を協力者に伝え実際に画面を操作してもらい、引っかかる部分を記録します。その後、引っかかった部分について、なぜ引っかかったのかその時の思考や感情をヒアリングします。それが課題であれば、ブラッシュアップをする事でサービスの改善をしていきます。
なぜユーザビリティテストが重要か
ではUXデザインにおいて、なぜユーザビリティテストが重要なのでしょうか? それは人間中心設計(HCD)の観点から見た場合、ユーザーに寄り添ったサービスの実現にはユーザからの評価により改善を繰り返すというプロセスが必要になるためです。
人間中心設計とは、ユーザビリティの観点で「ユーザーにとって使いやすいシステム設計を行う」という考え方で、以下の4つを基本プロセスとしています。
- 利用状況の把握と明示
- ユーザーの要求事項の明示
- ユーザーの要求事項を満たす設計による解決案の作成
- 要求事項に対する設計の評価
人間中心設計は「プロセスの繰り返し」を原則としており、評価の結果に応じて手戻りを繰り返す事でユーザー要件を満たす設計を目指していきます。
ユーザビリティテストはこの中の「評価」にあたります。
「評価」では、これまで設計したユーザー体験が実現できているかの検証が目的です。問題点が明らかになったら、原因となるプロセスまで戻り、修正し、再びユーザビリティテストを行います。ユーザビリティテストはこの「プロセスをの繰り返し」を行うべきかどうかを判断するための、大切な指標になるのです。
ユーザビリティテストの進め方
ユーザビリティテストは以下のプロセスで進めていきます。
1.実験の計画を立てる
▼目的の設定
ユーザビリティテストで何を検証したいのか、アサンプションマップで目的を設定します。 アサンプションマップとは、「ビジネス・ユーザー体験への影響度の高/低」「未知/既知」の2軸にる4象限マトリクスで分析する手法です。
- 検証したい事を書き出し仮説を立てる
- アサンプションマップに仮説をマッピングする
- 以下の優先度で、検証する仮説を選定する ①「影響力が高く未知の仮説」 ②「影響力が高く既知の仮説」or「影響力が低く未知の仮説」 ③「影響力が低く既知な仮説」
▼シナリオ・操作タスクの設定
協力者に操作してもらうタスクとタスクの目標となるシナリオを定義し、目的に沿った主要なタスクを絞っていきます。
ユーザーはタスクを進める際、何か目標を持って行動しているため、目標が伝わるよう、利用状況の伝わるシナリオを作成します。
▼人数の検討
コストを抑えるため多くの場合は5人にほどに絞って行います。
これはニールセンが過去のユーザビリティテストの分析結果から、5人で84%ほどのユーザビリティの問題を検出できるとした考えに基づいているためですんんn。(この考えは反復的なデザインプロセスを送る事が前提なので、問題点を発見したら改善し、再びユーザビリティテストを行いましょう。)
▼モデレーターの選出
モデレータとは協力者に対して調査の目的や方法を説明し、ユーザビリティテストの進行をコントロールする役割です。モデレータには協力者との信頼関係の形成や、テストの進行に応じた臨機応変な対応などが求められます。
2.協力者の確保
▼想定ユーザーの選出
テストするユーザーとして適した協力者を選出します。ある程度の規模の会社であれば、社内で適した人材を探し協力を仰ぐ場合もあります。しかし、家事専業の方など社内では補えないユーザーが対象となる場合もあり、多くの場合は外部の専門会社に依頼する事となります。
3.テストの実施
▼環境の設定
協力者の操作はビデオ・操作記録ツールで操作を記録します。これらを元にタスク実施後に、操作に迷った場面についてインタビューを行います。
▼タスクの説明
協力者に対してモデレーターからテストの目的や操作してもらうタスクについて説明を行います。
▼タスクの実施
協力者には独力でタスクを達成するよう操作してもらいます。そのタスクがこなせない事で他の評価ができなくなってしまうような場合を除き、基本は口出しを行いません。
また操作を見ているだけでは協力者が何を考えて操作しているか分かりません。そこで、協力者には思考発話法を用いて考えている事を全て話しながら操作を行って頂きます。
▼インタビュー
タスク実施後に実施中に迷っていた部分について、なぜ迷っていたのかどんな気持ちであったのかなど質問をしていきます。
インタビューでは直接問題となっている事を聞くような質問にならないよう注意が必要です。ユーザーは基本的に自分の事を分かっていないため、相手の質問が予想できるような質問をし周りを埋めていく事で問題について明らかにしていきます。
※ユーザーインタビューについて詳しく知りたい方はこちら
4.分析
▼定性・定量データの分析
テストで得られたデータをから問題があれば改善を、問題がなければブラッシュアップをするなどサービスの改善に繋げていきます。
▼発話プロトコル分析
思考発話法で得られた発話内容を時系列に書き起こし発話プロトコルの作成を行います。発話プロトコルと実際の操作画面・協力者のふるまいを組み合わせる事で製品がどのように認知されているか分析をします。
まとめ
今回はユーザビリティテストについて解説してきました。
ユーザビリティテストは費用や時間などコストがかかる面もありますが、定量的なデータからでは分からないユーザーインサイトを探る事が出来ます。実際のデザインの場面ではプロジェクトに応じて何を知りたいかも変わってくるため、抱えている問題に対して何が最適解かを見極め、実践してみましょう。