ユーザビリティテスト

ユーザビリティテストは、ユーザー中心の インタラクションデザインで使用される手法で、ユーザーを対象に製品をテストして評価します。実際のユーザーがシステムをどのように使用しているかを直接把握できるため、かけがえのないユーザビリティの実践と言えます。 ^[1]これは、製品のデザインの直感性を重視し、以前に製品を経験したことのないユーザーを対象にテストします。このようなテストは、最終製品の成功に最も重要です。完全に機能するアプリケーションであっても、ユーザーの間で混乱が生じると、長くは続かないでしょう。^[2]これは、専門家がさまざまな方法を使用してユーザーを関与させずにユーザーインターフェイスを評価する ユーザビリティ検査方法とは対照的です。

ユーザビリティ テストは、人間が作った製品が意図した目的を満たす能力を測定することに重点を置いています。ユーザビリティ テストの恩恵を受ける製品の例としては、食品、消費者製品、Web サイトまたは Web アプリケーション、コンピューター インターフェイス、ドキュメント、デバイスなどがあります。ユーザビリティ テストは、特定のオブジェクトまたはオブジェクト セットのユーザビリティ、つまり使いやすさを測定しますが、一般的な人間とコンピューターの相互作用の研究では、普遍的な原則を定式化しようとします。

単にオブジェクトや文書に関する意見を集めることは、ユーザビリティテストではなく、市場調査や定性調査です。ユーザビリティテストでは通常、制御された条件下での体系的な観察が行われ、人々が製品をどれだけうまく使用できるかを判断します。 ^[3]ただし、ユーザーの行動に加えて、ユーザーの動機や認識をよりよく理解するために、定性調査とユーザビリティテストの両方が組み合わせて使用​​されることがよくあります。

ユーザビリティ テストでは、ユーザーに下書きを見せて「これは理解できますか?」と尋ねるのではなく、ユーザーが意図した目的のために何かを使用しようとしている様子を観察します。たとえば、おもちゃの組み立て手順をテストする場合、被験者には手順と部品の箱が渡され、部品や材料についてコメントを求めるのではなく、おもちゃを組み立てるように求められます。手順の言い回し、イラストの品質、おもちゃのデザインはすべて、組み立てプロセスに影響します。

ユーザビリティ テストの設定には、シナリオ、つまり現実的な状況を注意深く作成することが含まれます。シナリオでは、人がテスト対象の製品を使用して一連のタスクを実行し、観察者がそれを見てメモを取ります (動的検証)。スクリプト化された手順、紙のプロトタイプ、テスト前後のアンケートなど、他のいくつかのテスト手段も、テスト対象の製品に関するフィードバックを収集するために使用されます (静的検証)。たとえば、電子メールプログラムの添付ファイル機能をテストする場合、シナリオでは、人が電子メールの添付ファイルを送信する必要がある状況を記述し、このタスクを実行するように依頼します。目的は、開発者が問題のある領域を特定して修正できるように、人々の動作を現実的に観察することです。ユーザビリティ テスト中にデータを収集するためによく使用される手法には、思考発話プロトコル、共同発見学習、視線追跡などがあります。

廊下テストはゲリラ ユーザビリティとも呼ばれ、廊下を通りかかる人などに製品やサービスを試用してもらう、迅速かつ安価なユーザビリティ テスト方法です。このテストにより、設計者は新しい設計の初期段階で「壁」、つまりユーザーが先に進めないほど深刻な問題を特定できます。プロジェクト設計者とエンジニア以外の誰でも使用できます (彼らはプロジェクトに近すぎるため、「専門家によるレビュー担当者」として行動する傾向があります)。

このタイプのテストは便宜的サンプリングの例であるため、結果に偏りが生じる可能性があります。

ユーザビリティ評価者、開発者、および見込みユーザーがさまざまな国やタイムゾーンにいる場合、従来のラボでのユーザビリティ評価を実施すると、コストとロジスティックスの観点から課題が生じます。これらの懸念から、ユーザーと評価者が空間と時間的に離れた場所で行われるリモート ユーザビリティ評価の研究が始まりました。リモート テストは、ユーザーの他のタスクやテクノロジのコンテキストで評価を行うのに役立ち、同期または非同期のいずれかになります。前者では、評価者とユーザーがリアルタイムで 1 対 1 でコミュニケーションを取りますが、後者では、評価者とユーザーが別々に作業します。^[4]これら両方のアプローチのニーズに対応するツールが多数あります。

同期型ユーザビリティ テストの方法論には、ビデオ会議や WebEx などのリモート アプリケーション共有ツールが含まれます。WebEx と GoToMeeting は、同期型リモート ユーザビリティ テストを実施するために最も一般的に使用されるテクノロジです。^[5]ただし、同期型リモート テストでは、共同テスト プロセスをサポートするために求められる即時性と「存在感」が欠けている可能性があります。さらに、文化や言語の壁を越えた対人関係のダイナミクスを管理するには、関係する文化に配慮したアプローチが必要になる場合があります。その他の欠点としては、テスト環境に対する制御が弱まる、参加者がネイティブ環境で経験する気晴らしや中断があるなどがあります。^[6]同期型リモート ユーザビリティ テストを実施するために開発された新しい方法の 1 つは、仮想世界を使用することです。^[7]

非同期の方法論には、ユーザーのクリック ストリーム、アプリケーションを操作中に発生する重大なインシデントのユーザー ログ、ユーザーによるインターフェイスに関する主観的なフィードバックの自動収集が含まれます。^[6]ラボ内調査と同様に、非同期リモート ユーザビリティ テストはタスク ベースであり、プラットフォームを使用して研究者がクリックとタスク時間を取得できます。そのため、多くの大企業では、これにより研究者が Web サイトまたはモバイル サイトを訪問する際の訪問者の意図をより深く理解できます。さらに、このスタイルのユーザー テストでは、人口統計、態度、行動のタイプ別にフィードバックをセグメント化する機会も提供されます。テストはユーザー自身の環境 (ラボではなく) で実行されるため、実際のシナリオ テストをさらにシミュレートできます。このアプローチでは、組織のオーバーヘッドを抑えながら、遠隔地のユーザーからフィードバックを迅速かつ簡単に収集する手段も提供されます。近年、非同期でユーザビリティ テストを実施することも普及しており、テスターは自由時間に、自宅で快適にフィードバックを提供できます。

専門家によるレビューは、ユーザビリティ テストのもう 1 つの一般的な方法です。名前が示すように、この方法では、その分野での経験を持つ専門家 (ユーザビリティ テストを専門とする企業からの専門家など) を招き、製品のユーザビリティを評価します。

ヒューリスティック評価またはユーザビリティ監査は、1人以上のヒューマンファクターの専門家によるインターフェースの評価です。評価者は、1994年にヤコブ・ニールセンによって最初に定義された10のユーザビリティヒューリスティックなどのユーザビリティ原則に基づいて、インターフェースのユーザビリティ、効率性、有効性を測定します。 ^[8]

ユーザー調査や新しいデバイスに応じて進化し続けてきたニールセンのユーザビリティヒューリスティックには、次のものが含まれます。

• システムステータスの可視性
• システムと現実世界の一致
• ユーザーコントロールと自由
• 一貫性と基準
• エラー防止
• 思い出すよりも認識する
• 柔軟性と使用効率
• 美しくミニマリストなデザイン
• ユーザーがエラーを認識し、診断し、回復できるように支援する
• ヘルプとドキュメント

エキスパートレビューと同様に、自動化されたエキスパートレビューは、優れた設計とヒューリスティックのルールが与えられたプログラムを使用して、ユーザビリティテストを提供します。自動化されたレビューは、人間によるレビューほど詳細で洞察力のあるものではないかもしれませんが、より迅速かつ一貫して完了できます。ユーザビリティテストのために代理ユーザーを作成するという考えは、人工知能コミュニティにとって野心的な方向性です。

ウェブ開発とマーケティングにおいて、A/B テストまたはスプリット テストはウェブ デザイン (特にユーザー エクスペリエンス デザイン) に対する実験的なアプローチであり、関心のある結果 (バナー広告のクリック率など) を増加または最大化するウェブ ページの変更を特定することを目的としています。名前が示すように、ユーザーの行動に影響を与える可能性のある 1 つのバリエーションを除いて同一の 2 つのバージョン (A と B) が比較されます。バージョン A は現在使用されているバージョンで、バージョン B は何らかの点で変更されている可能性があります。たとえば、e コマースのウェブサイトでは、購入ファネルは通常 A/B テストに適しています。離脱率がわずかに改善されただけでも、売上が大幅に増加する可能性があるためです。コピー テキスト、レイアウト、画像、色などの要素をテストすることで、大幅な改善を確認できます。

多変量テストまたはバケット テストは A/B テストに似ていますが、2 つ以上のバージョンを同時にテストします。

1990 年代初頭、当時サン マイクロシステムズの研究者だったヤコブ ニールセンは、開発プロセスのさまざまな段階で、通常は 5 人ずつの参加者による小規模なユーザビリティ テストを多数実施するという概念を普及させました。彼の主張は、ホームページを見て 2 人か 3 人が完全に混乱していることが判明したら、同じ欠陥のあるデザインにさらに多くの人が苦しむのを見ても、得られるものはほとんどないというものです。「手の込んだユーザビリティ テストはリソースの無駄です。5 人以下のユーザーをテストし、できるだけ多くの小規模なテストを実行することで、最高の結果が得られます。」^[9]

「5人のユーザーで十分」という主張は、後に数学モデル^[10]によって説明され、カバーされていない問題の割合U

${\displaystyle U=1-(1-p)^{n}}$

ここで、p は 1 人の被験者が特定の問題を特定する確率、n は被験者 (またはテスト セッション) の数です。このモデルは、実際に存在する問題の数に対する漸近グラフとして表示されます (下の図を参照)。

その後の研究では、ニールセンの主張は経験的証拠^[11]とより高度な数学モデル[12]の両方を用いて疑問視されてきました。この主張に対する2つの主な反論は^{次のとおり}です。

1. ユーザビリティは特定のユーザーセットに関係するため、このような小さなサンプルサイズでは全人口を代表することは難しいため、このような小さなサンプルのデータは、代表する人口よりもサンプルグループを反映している可能性が高い。
2. ユーザビリティの問題はどれも同じように簡単に検出できるわけではありません。解決困難な問題はプロセス全体を遅らせることがあります。このような状況では、プロセスの進行はニールセン/ランダウアーの式で予測されるよりもはるかに遅くなります。^[13]

ニールセンは、5 人のユーザーによる 1 回のテストで止めることを推奨していません。彼の主張は、5 人のユーザーによるテスト、発見した問題を修正し、修正したサイトを 5 人のユーザーでテストする方が、10 人のユーザーによる 1 回のユーザビリティ テストよりも限られたリソースを有効に活用できるということです。実際には、テストは開発サイクル全体を通じて週に 1 回か 2 回実行され、1 ラウンドあたり 3 人から 5 人の被験者が使用され、結果は 24 時間以内にデザイナーに提供されます。したがって、プロジェクト期間中に実際にテストされるユーザーの数は、50 人から 100 人に簡単に達します。調査によると、組織が実施するユーザー テストでは、5 人から 10 人の参加者を募集することが最も一般的です。^[14]

ユーザーがすぐに問題に遭遇して立ち止まってしまう可能性が最も高い初期段階では、通常の知能を持つほぼすべての人が被験者として使用できます。第 2 段階では、テスターは幅広い能力を持つ被験者を募集します。たとえば、ある調査では、経験豊富なユーザーは最初から最後までどのデザインでも問題なく使用できましたが、初心者ユーザーと自称パワーユーザーは両方とも何度も失敗しました。^[15] その後、デザインがスムーズになったら、ターゲット ユーザー グループからユーザーを募集する必要があります。

この方法をプロジェクトの過程で十分な人数に適用すると、上記の異議は解決されます。サンプル サイズは小さくなくなり、たまにしか使用しないユーザーで発生するユーザビリティの問題が見つかるようになります。この方法の価値は、特定の設計上の問題が一度発生すると、すぐに排除されるため、二度と発生しないという点にあります。一方、成功しているように見える部分は何度もテストされます。設計上の最初の問題は 5 人のユーザーによってのみテストされるかもしれませんが、この方法を適切に適用すると、最初のテストでうまくいった設計の部分は 50 人から 100 人のユーザーによってテストされることになります。

1982年にアップルコンピュータが開発者向けに発表したマニュアルでは、ユーザビリティテストについて次のようにアドバイスしている。^[16]

1. 「対象読者を選択します。ヒューマン インターフェイスの設計は、まず対象読者を特定することから始めます。ビジネスマン向けですか、それとも子供向けですか?」
2. 対象ユーザーが Apple コンピュータとソフトウェアの主題についてどの程度知っているかを判断します。
3. ステップ 1 と 2 では、対象ユーザーのニーズに合わせてユーザー インターフェイスを設計できます。会計士向けに作成された税務申告準備ソフトウェアでは、ユーザーはコンピューターについては何も知らないが、税法の専門家であると想定されます。一方、消費者向けに作成されたソフトウェアでは、ユーザーは税金については何も知らないが、Apple コンピューターの基本については精通していると想定されます。

アップルは開発者に「招集した友人、親戚、新入社員を使ってできるだけ早くテストを始めるべきだ」とアドバイスした。^[16]

私たちのテスト方法は次の通りです。5～6 台のコンピュータ システムを備えた部屋を用意します。一度に 5～6 人のユーザーからなる 2～3 のグループにシステムを試用してもらいます (テストしているのはシステムではなくソフトウェアであることをユーザーに知らせないことがよくあります)。部屋にはデザイナーが 2 人います。デザイナーが 2 人より少ないと、何が起こっているのかをほとんど見逃してしまいます。デザイナーが 2 人より多いと、ユーザーは常に誰かに監視されているように感じてしまいます。

デザイナーは人々が実際にプログラムを使用する様子を観察しなければならない。なぜなら^[16]

95% のつまずきは、ユーザーのボディ ランゲージを観察することで発見できます。目を細めたり、肩をすくめたり、首を振ったり、深く心のこもったため息をついたりしていないか注意してください。ユーザーが行き詰まると、それは「自分があまり賢くないから」だと考えます。報告せず、隠します... ユーザーが混乱した理由について推測しないでください。ユーザーに尋ねてください。ユーザーが迷ったときにプログラムが何をしていると考えていたかを知ると、驚くことがよくあります。

ユーザビリティテストは、さまざまな分野で正式な学術教育のテーマとなっています。^[17]ユーザビリティテストは、作文研究やオンラインライティング指導（OWI）にとって重要です。^{[18]学者のコリン・ビョークは、ユーザビリティテストは「}デジタルレトリックの理論と組み合わせない限り、効果的なOWIを開発するには必要だが不十分である」と主張しています。^[19]

調査製品には、紙とデジタルの調査、フォーム、調査回答者が単独で、またはデータ収集者と一緒に完了または使用できる機器が含まれます。ユーザビリティテストは、Web調査で最もよく行われ、調査の操作、調査回答の入力、ヘルプ情報の検索など、人々が調査とどのようにやり取りするかに焦点を当てています。ユーザビリティテストは、認知事前テスト（人々が製品をどのように理解するか）、パイロットテスト（調査手順がどのように機能するか）、調査方法の専門家による専門家レビューなど、従来の調査事前テスト方法を補完します。^[20]

翻訳された調査製品では、ユーザビリティテストにより、文や単語レベル、データ入力やナビゲーションの設計において「文化的適合性」を考慮する必要があることが示されています。 ^[21]また、一般的な機能（タブ、ハイパーリンク、ドロップダウンメニュー、URL）の翻訳と視覚的なヒントを提示すると、ユーザーエクスペリエンスが向上することが示されています。^[22]

• ユーザビリティ.gov