ユーザビリティテスト

ユーザビリティテストは、参加者のUIの操作を観察し、UIの問題と原因を特定し、改善につなげます。

ユーザビリティテスト（ユーザーテスト）とは、サイトやアプリの想定ユーザーによる操作を観察し、ユーザビリティ（UIの操作性）の問題を発見し、原因を究明する手法です。

目的・やり方・わかること

ユーザビリティテストには、定性的なものと定量的なものとがあります。一般的なのは定性的なものです。これは、ユーザビリティ上の課題の所在や原因を特定して改善策を探るという、形成的な目的で行います。

評価対象物の想定ユーザー像と一致するテスト参加者に、モデレーターがタスク（課題）を提示します。参加者は評価対象物を利用し、その際の行動や発話をモデレーターや観察者が観察・記録し、分析します。

参加者のタスク実行過程での行動や発話から、問題（ユーザーが、どこでどのようにつまづいたのか）や、問題が発生した原因（なぜその問題が起きたのか）を把握します。

たとえば、スマートフォンアプリやウェブサイトのUIデザインが、ユーザーの思考・利用状況・目的に沿ったものになっているか、また、ビジネス側の目的を達成できるものになっているかをテストします。

調査結果をゆがめない（バイアスをかけない）ようにテスト参加者の思考内容を引き出すには、専門的な技量と細心の注意が必要です。

評価対象物：簡易なプロトタイプでもテスト可能

評価対象物は、弊社の場合、スマートフォン・PCの、アプリ・ウェブサイトであることが多いですが、テレビ・自動車・キオスク端末などの組み込みシステムを評価することもあります。

評価対象物は、参加者が簡易的にでも操作できるものが必要です。現行版のアプリやウェブサイトでも、FigmaのUIプロトタイプでも評価可能です。極端な例では、紙に手描きしたワイヤーフレームでも可能です。

プロトタイプは見た目や挙動を作り込んだものでもテスト可能です。時間をかけて作り込むと、「変更したくない」という心理が生まれます。しかし、形成的なテストの目的は、UIの問題を見つけてよりよく作り変えることですから、この点と矛盾する恐れがあります（UXプロトタイプ：低忠実度か高忠実度か）。

また、大きな問題が見つかっても開発スケジュールに余裕がなくて変更ができない、ということもあります。開発フェーズの早い段階でアイデアを簡単にかたちにして早めに失敗すれば、改善に時間を割けます。

また、開発スケジュールの終わりで大きな問題が見つかっても、時間切れで変更できないこともあります。開発の早い段階でアイデアを簡単な形にしてテストして早めに失敗すれば、改善に十分な時間を割けます。

タスク：あいまいすぎず、具体的すぎず

タスクとは、評価対象物を使ってテスト参加者に行ってもらう課題のことで、実際に行う可能性のあることを設定します。タスクは、参加者の思考や行動をゆがめないよう、内容・指示説明・順序を設計します。

人がアプリやウェブサイトなどを利用するときには何かしらの背景・文脈や目的・動機があります。それらを端的にまとめたシナリオを作成します。また、「どこから始めるのか」と「どうなれば完了なのか」というスタートとゴールを明確にします。ここをあいまいにしてはいけません。

逆に、「Aした上でBしてください」などと、操作する箇所や手順を具体的に指示してはいけません。ヒントを与えたり、誘導してしまってはユーザビリティテストになりません。

モデレーター：参加者にバイアスをかけないことに細心の注意を

モデレーターとは、ユーザビリティテストの司会進行役のことです。タスクの内容をテスト参加者に説明し、参加者が評価対象物を操作する様子を観察し、参加者の思考発話（何を考えながら操作しているのかを言葉にすること）を促し、操作の意図など疑問に感じた点を質問します。

また、タスクの実行前に参加者のプロフィールを確認したり、すべてのタスクの終了後に評価対象物の印象や使ってみた感想などの総括的な質問をしたりします。

モデレーターは参加者の信頼を得る必要があります。そのため、評価対象はUIであり、参加者の操作スキルを測るものではないことを伝えます。また、UIのわかりにくい点や操作しにくい点を正直に話してもらうことで、改善につながることも説明します。こうして、参加者が安心してテストに参加できるようにします。

ネガティブなことを言うのは申し訳ない、と考える参加者もいます。モデレーターは、自分は評価対象物の開発者ではないこと、率直によくなかった点を教えてもらえるほうが改善につながることを伝えます。

タスクの指示の際や、参加者のタスク実行中には、参加者の思考や行動をゆがめないよう細心の注意が不可欠です。参加者が操作方法を尋ねても答えてはいけません。参加者の行動の観察と思考の理解に徹します。

テスト参加者：どのような人を何人集めるか

評価の目的と対象物に合わせて、その想定ユーザーに近い条件の人を主にインターネットアンケートを実施して探し（スクリーニング）、指定した日時に参加してもらうように調整（リクルート）します（ユーザビリティテスト参加者のリクルーティング）。

評価対象物のユーザーとして想定する条件（年代、評価対象物や類似品の利用経験・意向など）に合致する人を探し出すアンケートを設計・作成し、アンケートパネルに配信して回答を集めます。想定ユーザーとは考え方や持っている知識が異なる人だとテスト結果が変わりますので、この設計には慎重さが必要です。

ユーザビリティテストでは、テスト参加者5人で全体の約85%の問題を発見できるとされています（Nielsen and Landauer, 1993）。ユーザビリティの向上には、一度に数十人でテストするよりも、5人程度の小規模なテストを繰り返したほうが効果があります（ユーザビリティテストのユーザー数が5人で十分な理由）。

実施方法：対面でもオンラインでも

ユーザビリティテストは、従来から対面で行われてきましたが、最近ではオンライン（ZoomやMicrosoft Teamsなどのウェブ会議）でも行われるようになりました。

対面でのテスト

対面でのテストでは参加者の表情や手の動きを直接観察でき、非言語的な戸惑いや違和感にも気づけます。

ただ、テスト会場に来てもらう必要があるため、参加者は会場の近くに居住・勤務する人に限定され、移動時間や交通費がかかるという、物理的なハードルがあります。

オンラインでの（ウェブ会議による）テスト

一方、ウェブ会議によるテストにはインターネットにつながればどこからでも参加してもらえます。対面での実施では必要な会場費が（地域によってはモデレーターの出張費も）かからないメリットもあります。

ただ、対面のテストでは可能だった表情や手の動きを直接観察することができなくなりますので、たとえば、スマートフォンでの指の迷いや誤タップ（タップ可能だと思ったが反応しなかった）はわかりません。

そして、ウェブ会議では、通信が途切れる、参加者の音声が聞こえない、画面が共有できないなどの技術トラブルが発生することがあります。弊社では事前の接続テストでこのようなトラブルを極力防いでいますが、その分、対面でのテストより実施までに追加の日数が必要、という時間的なデメリットがあります。

また、公開前のプロトタイプを見てもらう場合、参加者と秘密保持契約を結ぶとはいえ、スクリーンショットを撮影される恐れがあるなど、情報のコントロールが対面の場合より難しい、という欠点もあります。