KNOWLEDGE
KNOWLEDGE

UXデザインに必要なユーザビリティテストの進め方・注意点

UXデザインでは、対象となるサービスにおけるユーザー体験への理解が不可欠です。
その中の1つの手法である「ユーザビリティテスト」について解説していきます。

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

ユーザビリティテストは製品やプロトタイプなどに対して、実際にユーザーを招き意図した使われ方をするのか検証する方法です。例えば、あるお題を協力者に伝え実際に画面を操作してもらい引っかかる部分を記録します。その後、引っかかった部分について、なぜ引っかかったかその時の感情を聞き、それが課題であればブラッシュアップをする事でサービスの改善をしていきます。

人間中心設計におけるユーザビリティテストの位置付け

ではUXデザインにおいてなぜユーザビリティテストが大切なのでしょうか?それは人間中心設計(HCD)の観点から見た場合、ユーザーに寄り添ったサービスの実現にはユーザビリティテストでの評価の繰り返しが必要不可欠だからです。

人間中心設計とはユーザビリティの観点から、「使う人」を尊重した設計を行うという考え方です。
人間中心設計では、

  • 利用状況の把握と明示
  • ユーザーの要求事項の明示
  • ユーザーの要求事項を満たす設計による解決案の作成
  • 要求事項に対する設計の評価

…とプロセスを進めていきます。人間中心設計は反復設計をコンセプトとしており、評価結果に応じて手戻りを繰り返す事でユーザー要件を満たす設計を目指していきます。

ユーザビリティテストはこの中の「要求事項に対する設計の評価」にあたります。このプロセスでは、サービスのレベルやコンセプトとしたUXが実現できているかの検証が目的です。問題点が明らかになったら、原因となるプロセスまで戻り修正し再びユーザビリティテストを行います。ユーザビリティテストはこのプロセスを繰り返すか判断する大切な項目なのです。

ユーザビリティテストの進め方

1.実験の計画を立てる

目的の設定
ユーザビリティテストで何を検証したいのか、アサンプションマップで目的を設定します。

  1. 検証したい事を書き出し仮説を立てる
  2. アサンプションマップに仮説をマッピング
    アサンプションマップ…横軸に「既知か未知」、縦軸に影響力が「高いか低い」をとる
  3. テストすべき課題を選ぶ
    優先度は高い順に
    ①「影響力が高く未知の仮説」
    ②「影響力が高く既知の仮説」or「影響力が低く未知の仮説」
    ③「影響力が低く既知な仮説」

人数の検討
コストを抑えるため多くの場合は5人にほどに絞って行います。
これはニールセンが過去のユーザビリティテストの分析結果から、5人で84%ほどのユーザビリティの問題を検出できるとした考えに基づいているためです。(この考えは反復的なデザインプロセスを送る事が前提なので、問題点を発見したら改善、再びユーザビリティテストを行いましょう。)

操作タスクの設定
タスクのスタートとゴールを定義し、目的に沿った主要なタスクを絞っていきます。

シナリオの作成
ユーザーはタスクを進める際、何か目標を持って行動しています。そのため目標が伝わるよう、利用状況の伝わるシナリオを作成します。

モデレーターの選出
モデレータとは協力者に対して調査の目的や方法を説明し、ユーザビリティテストの進行をコントロールする役割です。モデレータには協力者との信頼関係の形成や、テストの進行に応じた臨機応変な対応などが求められます。

2.協力者の確保

想定ユーザーの選出
テストするユーザーとして適した協力者を選出します。ある程度の規模の会社であれば、社内で適した人材を探し協力を仰ぐ場合もあります。しかし、家事専業の方など社内では補えないユーザーが対象となる場合もあり、多くの場合は外部の専門会社に依頼する事となります。

3.テストの実施

環境の設定
協力者の操作はビデオ・操作記録ツールで操作を記録します。これらを元にタスク実施後に、操作に迷った場面についてインタビューを行います。

タスクの説明
協力者に対してモデレーターからテストの目的や操作してもらうタスクについて説明を行います。

タスクの実施
協力者には独力でタスクを達成するよう操作してもらいます。そのタスクがこなせない事で他の評価ができなくなってしまうような場合を除き、基本は口出しを行いません。
また操作を見ているだけでは協力者が何を考えて操作しているか分かりません。そこで、協力者には思考発話法を用いて考えている事を全て話しながら操作を行って頂きます。

インタビュー
タスク実施後に実施中に迷っていた部分について、なぜ迷っていたのかどんな気持ちであったのかなど質問をしていきます。
インタビューでは直接問題となっている事を聞くような質問にならないよう注意が必要です。ユーザーは基本的に自分の事を分かっていないため、相手の質問が予想できるような質問をし周りを埋めていく事で問題について明らかにしていきます。

4.分析

定性・定量データの分析
テストで得られたデータをから問題があれば改善を、問題がなければブラッシュアップをするなどサービスの改善に繋げていきます。

発話プロトコル分析
思考発話法で得られた発話内容を時系列に書き起こし発話プロトコルの作成を行います。発話プロトコルと実際の操作画面・協力者のふるまいを組み合わせる事で製品がどのように認知されているか分析をします。
しかし、ユーザビリティテストはデザインプロセスの後半で行うため納期などの制約があるクライアントワークでは行わない事も多かったりします。

まとめ

今回はユーザビリティテストについて解説してきました。
ユーザビリティテストは費用や時間などコストがかかる面もありますが、定量的なデータからでは分からないユーザーインサイトを探る事が出来ます。実際のデザインの場面ではプロジェクトに応じて何を知りたいかも変わってくるため、抱えている問題に対して何が最適解かを見極め、実践してみましょう。

静岡出身。2020年にSEVEN DEXにJoinしました。普段は大学でUI/UXについて学んでます。誰かのためを考えて物作りをする事が好きです。