2023年11月29日にオンラインセミナー『UX/UI改善に貢献するユーザーテストとは？ 基礎知識から実施のプロセスまで解説』を開催いたしました。
この記事では当日用いた資料を公開し、ポイントを解説しています。
目次
ユーザーテストとは？
ユーザーテストとは、ユーザーにサービスやプロダクトを体験してもらい、要件と設計についての問題を発見して改善のためのフィードバックを得る手法です。
例えば、PCでソフトウェアをユーザーに操作してもらい、それを観察したり、操作の感想をヒアリングしたりすることでユーザーにとって使いにくい点がないかを確認します。
ユーザーが「この作業をするためには今画面に出ていない別の情報が見えた方が便利だな」と考えたと仮定します。後に説明する発話法を用いてユーザーテストを行えばこのような意見を設計者が把握できますが、テストなしでは設計者が同じ情報を得ることは難しいといえます。
なお、ユーザーテストは大量のサンプル数を集めて行う定量評価ではありません。目に見えないもの、数字では表せないものを評価する定性評価なので、テストの設計の良し悪しや評価を行う側のスキルが結果に影響します。効果に関しては、5人のユーザーにテストを行うことで、潜在するユーザビリティの問題のうち8割を発見できるという調査結果も出ている有効なものです。
ユーザーテストのタイミング
一般的なウォーターフォール型のソフトウェア開発プロジェクトにおいてユーザーテストを行う場合は、要件定義、基本設計、詳細設計、製造、テストという手順の中で「基本設計」の中頃までに実施するのが有効です。
（このセミナーではソフトウェア開発プロジェクトを主な対象としてユーザーテストを解説しています）
詳細設計以降にテストを行うことも不可能ではありませんが、詳細設計以降にテスト結果受けて変更を行うと手戻りが増えて、プロジェクト全体への影響が非常に大きくなってしまうため、影響が小さい初期のうちに行うことをお勧めします。
なお、これは新規開発をイメージしていますが、リリース後の改修でもユーザーテストは有効です。
アジャイル型の開発の場合、スプリントという短期の開発を繰り返すことでシステム全体をつくっていくのでウォーターフォール型と流れは異なりますが、アジャイルではスプリントごとにつくったものを確認するのでそこでユーザーテストを行うのは有意義です。もちろんすべてのスプリントで行うのは難しいですが、重要なマイルストーンにあたる機能を開発しているときだけはユーザーテストに時間を割くなどの計画を事前に立てれば実践可能だと思います。
UXデザインプロセスにおけるユーザーテスト
NCDCが関わるソフトウェア開発プロジェクトではよく要件定義など初期の段階でUXデザインの手法を取り入れています。その場合、下図のようにユーザーテストにより要件や設計の最後の評価が行われるので、結果に応じて前⼯程に戻り、要件や設計をブラッシュアップしていきます。
ユーザーテストの結果からペルソナやジャーニーマップが間違っていたと気づくこともあるので、その場合は必要なところまで戻って、再度ペルソナやジャーニーマップを用いたUXの検証を行います。
ユーザーテストの基礎知識
ユーザーテストの構成要素
ユーザーテストの準備には次のものが必要です。
- 参加者（被験者）：プロトタイプを体験する人物（ユーザーと同じ属性の方が望ましい）
- モデレーター：テスト進行担当者。通常はテスト設計者が兼任
- プロトタイプ：サービスやプロダクトを体験できる試作品
- テストシナリオ：参加者に依頼するプロトタイプの操作内容などを決めた資料
- 記録デバイス：参加者の行動を記録するためのもの（Web会議室の録画や、モバイルデバイス用書画カメラなど）
- テスト会場：テストを実施する空間（オンライン会議室を含む）
テストを行う側から見ると「被験者」という表現はわかりやすいのですが、被験者という言葉は相手を警戒させてしまうので、参加者本人に対して被験者という言葉は使わないようにします。
プロトタイプには紙に手書きで画面のイメージを書いただけのペーパープロトタイプを使うこともあれば、デザイナーが画面の完成イメージを完成させたデザインモックアップをユーザーテストに用いることもあります。
ユーザーテストの成果物
ユーザーテストから次のような成果物が得られます。
- プロブレムマトリクス：画面とその操作タスクごとに成否を一覧化して問題箇所を明示する資料
- 事象・発言一覧：画面とその操作タスクごとに得られた出来事やユーザーの発言を整理し、問題点を示唆する資料
- 事後アンケート・インタビュー：内容について理解してもらった上で直接意見を収集した資料
プロブレムマトリクスは下図のようなかたちでつくられます。
下図で赤いところはユーザーが作業を完遂できなかったことを示します。オレンジは完遂したが時間がかかったことを示しています。こうした資料によって、画面と操作タスクごとにどこに問題があったかを特定しやすくなります。
ユーザーテスト実施のプロセス
ユーザーテストの主な手順は以下の通りです。
- プランニング：プロジェクトごとの状況・制約に応じた計画を立てる
- プロトタイプ作成：テストに必要なプロトタイプを作成
- 参加者の確定：テストの参加者の属性を定義し、スケジュールする
- テストシナリオ・タスク準備：参加者に依頼するテスト内容の文章を作成
- パイロットテスト：プロトタイプやシナリオに問題がないか内部テストを実施
- テスト：実施思考発話法を用いてテスト本番を実施
- 分析・改善内容の導出：得られた情報を分析し、改善内容を導き出す
重要な「思考発話法」
思考発話法とはユーザー（参加者）にプロトタイプを操作しながら思ったことを漏らさず発話してもらい記録する手法です。ユーザーを観察するだけでなく、目に見えないユーザーの考えを言語化して聞くことで改善内容を検討するためのフィードバックとして活用します。
モデレーターは操作中の参加者に発話を適宜促し、できるだけ多くの情報を得られるように働きかけます。
思考発話法を行う際はラポール（⼼理的信頼関係）形成がとても重要です。テストの内容や趣旨について丁寧に説明したり、参加人数を絞ってテストを行ったり工夫することで、参加者の緊張感を和らげてから実施します。
観察からわかることだけではなく、ユーザーの思考まで理解するために思考発話法はとても重要なのですが、リラックスして思考を発話してもらうためには信頼関係が欠かせないと考えてださい。
続いて各プロセスの要点を説明します。
ユーザーテストのプランニング
- テスト回数：問題点の洗い出しのためのテストと、その改善検証のためのテストの計２回行うことを推奨します
- テスト時期：実施自体は1〜2日程度が基本ですが、設計修正期間を含めるのを忘れずに計画します
- 参加者人数：5人程度にテストを行うのが有効ですが、1〜2名でも充分な効果が見込めます
- プロトタイプ精度：どの程度の精度でテスト用のプロトタイプを作成するか事前に決めます
- テスト場所：参加者がいる場所へ訪問するのか、テスト会場に来てもらうのかを検討します
- テスト範囲：機能が多い場合は優先順位をつけてテスト範囲を策定します
ユーザーテストの参加者について
ユーザーテストの参加者は、基本的に実際のユーザーと同じ属性の人物に参加してもらうことが重要です。
コンシューマーや一般的な業務を担うビジネスユーザーを対象とする場合は、リサーチ会社にモニター募集を頼んだり、社内でユーザー像に近い属性の人物を集めたりすることで、比較的容易に属性の参加者を集めることができます。
一方で、たとえば危険物の管理など専門的な業務を行う特定のユーザーを想定してテストを行いたい場合、実際のユーザーと同じ属性の人物を見つけるのが難しくなります。その場合は、社内で少しでも業務のことを知っている人物や、できるだけ属性の人物を探すことで代用することもあります。
プロトタイプ作成
プロトタイプにもさまざまなものがありますが、一般的なソフトウェア開発プロジェクトにおいてはFigma等のデザインツールによるデザインプロトタイプを用いるのがトレンドです。デザインプロトタイプとは、画面デザイン上のボタンなどにリンクをつけて、擬似的に実装したのと同じ挙動をもたせた紙芝居のようなもので、エンジニアがコードを書いて画面を作るよりもスピーディに低コストで用意できます。
もちろん目的によっては実装レベルのプロトタイプを用いてユーザーテストを行うケースもありますが、ソフトウェア開発においてUX/UI上の課題を発見することが目的の場合は、実装を伴わない紙芝居レベルのプロトタイプでも十分なユーザーテストが可能です。
テストシナリオ・タスク作成
参加者にプロトタイプの操作をしてもらう上で必要になる次の2つを文章として作成します。
- シナリオ：仮の状況設定
- タスク：作業の内容
大型ホームセンターのスタッフが使う商品発注アプリのユーザーテストを行う際のテストシナリオとタスクの例をご紹介します。
シナリオ（仮の状況設定）の例
ホームセンターのマネージャーであるあなたは日常的にたくさんの商品を発注しています。
今までエクセルによる発注票で商品発注を行っていたところ、新しく商品発注アプリが導入されました。このアプリを使って次の業務を行ってください。
シナリオやタスクはユーザーの立場で表現されている必要があります。この例の場合は「マネージャーの業務」として当人にわかりやすい平易な言葉で表現されてなくてはいけません。要は一般的なユーザーが使わない設計者側の言葉で説明してはいけないということです。
タスクのOK例（ユーザーが行うべき業務として表現）
在庫切れになった商品の追加発注を行なって下さい
タスクのNG例（画面名などを用いてシステムの設計者視点で表現）
在庫数表示が空になっている商品の詳細画面から外部発注サイトに遷移して追加発注を行なって下さい
パイロットテスト
ユーザーテスト本番の前に、用意したプロトタイプやシナリオ・タスクが問題なく機能するかを確認しておく必要があります。そのために、できるだけ本番同様の環境で事前テストを行います。
パイロットテストでは、用意したプロトタイプに問題がないか、シナリオ・タスクが意図した通りに参加者に伝わるか、テストにかかる時間はどれくらいかなどを確認します（タスクの説明がわかりにくかったり、ひとりのテストに要する時間が長すぎたりすぎると結果に悪影響が出てしまいます）
テスト（本番）
下図はモバイルアプリのユーザーテストを実施する際の環境セッティングの例です。このような観察や記録のための環境準備をしてから参加者を会場に迎え、次の手順で1回分のテストを行います。
- 事前説明：録画する旨やテストの趣旨、思考発話の依頼を伝えます
- 事前インタビュー：関連する業務や日常行動についてインタビューします
- テスト：シナリオとタスクを提示し、操作してもらいます
- 事後インタビュー：サービスの内容についてインタビューします
テスト実施のポイント
事前説明では、以下の内容を丁寧に話して参加者の不安・緊張感を和らげることが大切です。
- あくまでサービス・プロダクトのテストであり、参加者を試すテストではないこと
- 収録する音声や映像はプロジェクトに関係する限られた人数のみ視聴すること
- 独力でタスク達成可能かどうかを確認したいため、途中質問には応えられないこと
事前インタビューでは、サービスやプロダクトに関係する普段の行動について軽く会話を行い、シナリオやタスクへの導入をスムーズにします。
用意したシナリオやタスクはテストの実施中にユーザーにいつでも確認してもらえるように印刷して提示します。
事後インタビューはユーザーの行動を観察したり発話を聞いたりしたあとでユーザーの意見を聞くものであるため、ユーザーの行動によって質問も変化しますが、その場で急いで考えても良いフィードバックは得られません。
事後インタビューとはいえ、ある程度は事前に質問を設計しておくことも必要です。
分析・改善内容の導出
ユーザーテストのゴールはテストで得られたフィードバックを要件定義や設計に活かすことです。ユーザーテストが済んだら、そこで得られた各種資料から改善箇所と内容を導き出します。
先述した成果物の例で説明すると、まずプロブレムマトリクスで参加者がタスクを達成できなかった箇所と達成に時間がかかった箇所を特定して、そのユーザーがそのタスクに取り組んだときの観察結果や発話の内容を分析することで、改善すべき点を発見します。
ユーザーテストの注意事項
事後インタビューで具体的なユーザーの声を聞くとそれが正しいと考えてしまいがちですが、ユーザーの意見はあくまで参考情報として扱うべきものです。
仮にテストに協力してくれたユーザーが「こんな機能は必要ない」と言ったとしてもそれが正解とは限りません。大切なのは「なぜこの機能が必要ないと言われたのか？」と疑問を持ち、その要因を探ることです。そのユーザーの観察結果や発話を分析して「何が足りないのか？」「どうすればよいのか？」を考えることに大きな意味があるのです。
UX/UI改善のご相談はNCDCへ
NCDCは、業務用システムからコンシューマー向けのモバイルアプリまで豊富なUX/UIデザインの実績を有しています。
新規プロダクトのUX/UIデザインや既存プロダクトのUI改善、それらに関するユーザーテストの取り入れ方などについてお悩みの方は、ぜひ一度NCDCにご相談ください。
