RITE を使用したナビゲーションのテスト

Rapid Iterative Testing and Evaluation (RITE) は、プロトタイプを迅速かつ反復的に複数回評価するユーザビリティテストの手法です。目標は統計的妥当性を決定することではなく、行動を観察し、洞察を学び、迅速にイテレーションすることです。これは、変更を行うまで最後まで待つのではなく、テスト中にイテレーションするため、従来のユーザビリティテストとは異なります。この手法は、テスト内で行った変更の有効性を検証しながら、できるだけ多くのユーザビリティ上の問題を特定して修正することを目的としています。これにより、ユーザビリティの文脈で高い確信を持てるナビゲーションプロトタイプが得られ、提案したソリューションが利用可能かどうかに関する不確実性を取り除くのに役立ちます。

なぜこの手法を使用すべきですか？

前に進めたいナビゲーションデザインのコンセプトがあり、その基本的なユーザビリティを評価したいとします。ソリューション検証プロセスの早い段階で、プロトタイプの何がうまく機能していて、何がうまく機能していないかを知り、変更を素早くテストしたいと考えます。RITE 手法を使用すると、ナビゲーションデザインを素早く評価してイテレーションを促進できます。

目標: ユーザーが新しいナビゲーションデザインでタスクに移動できるかを学び、基本的なユーザビリティを評価し、デザインで機能する点と機能しない点を特定し、第一印象やその他の定性的フィードバックなどの追加の洞察を得ます。

この手法で答えられるリサーチ質問の種類:

• ユーザーは、ナビゲーションデザインでタスクを完了するためにどこへ行くべきかを知っていますか？なぜ、またはなぜそうではありませんか？
• ユーザーは、ナビゲーションデザインでタスクを完了できますか？なぜ、またはなぜそうではありませんか？
• ユーザーは、ナビゲーションデザインで UI の新しい何かを発見できますか？なぜ、またはなぜそうではありませんか？
• ナビゲーションデザインで提案されているレイアウトは意味をなしていますか？なぜ、またはなぜそうではありませんか？
• ユーザーは、ナビゲーションデザインでアプリケーション内の自分の位置を把握できますか？なぜ、またはなぜそうではありませんか？
• ナビゲーションデザイン内の UI 要素は、ユーザーにとって目立っていますか？なぜ、またはなぜそうではありませんか？

手法の詳細

進行の種類: このテストは、参加者から得られるフィードバック、その観察された行動、参加者自身がプロトタイプを理解する能力についてどの程度深掘りする必要があるかに応じて、モデレーターありまたはモデレーターなしにできます。参加者は思考発話法を使用する必要があります。

必要な忠実度: この種のテストには、基本的なインタラクションをテストできる十分な忠実度を持つプロトタイプを使用する必要があります。例えば、参加者がある領域に移動できるかを評価したい場合は、参加者がそのタスクを完了でき、理想的にはいくつかの「誤った」領域もクリックできるインタラクティブなプロトタイプが必要です。

推奨サンプルサイズ: 問題を引き続き発見するかどうかによって異なります。RITE 手法では、3 名の参加者から始め、初期デザインで見つかったユーザビリティ上の問題を修正し、合計 5 名となるよう追加の 2 名の参加者でテストします。追加の問題が見つからなければ完了です。追加の問題が見つかった場合は、さらなる問題が見つからなくなるまで 3 名の参加者を追加します。

記録する内容:

• 参加者がタスクを完了するためにどのようにナビゲートするか
  • 一般的な経路（正しいかどうかにかかわらず）
    • 定性的フィードバックを通じて、なぜその経路を選んだか
• 成功に影響したもの
  • タスクを難しく／簡単にしたものは何か？
  • 困難があった場合、参加者は回復できたか？できた場合、どの程度の労力が必要だったか？なぜか？
  • 参加者は何か（私たちが気づいてほしかったもの）に気づいたか？
• ユーザビリティ上の問題
  • 参加者はナビゲーション内で何かを見つけるのに苦労したか？なぜか？
  • ナビゲーション項目のラベルは参加者を混乱させたか？なぜか？
  • ナビゲーション項目は期待どおりに動作しなかったか（トップメニューでの検索など）？なぜか？
  • 問題は各セッションで、次の形式に従って分類する必要があります。

セッションで特定されたユーザビリティ上の問題は、次のカテゴリに分類されます。

体験に関する定性的フィードバック

• タスク後の質問:
  • 今取り組んだアクティビティについて、フィードバックはありますか？
  • 特に簡単または難しかったことはありましたか（まだ言及されていない場合）？なぜですか？
  • （モデレーターありの場合）、タスク中にユーザーが行っていた具体的なことを深掘りします。
• テスト後の質問:
  • その体験について、好きだった点または嫌いだった点は何ですか？
  • （モデレーターありの場合）、テスト中に観察された興味深い／不明確な行動や観察について深掘りします。

RITE 調査の実行方法

詳細は、RITE ハンドブックページを参照してください。

推奨プラットフォーム: モデレーターなしの調査には UserTesting、モデレーターありの調査には Zoom。

結果の報告

Slack または Issue で簡潔な／初期の調査結果を報告するには、次の形式を使用してください。

最初の 3 名の参加者の後:

• 見つかったユーザビリティ上の問題の数
• 簡単な説明を添えた、見つかったユーザビリティ上の問題
  • 例: 「3 名中 2 名の参加者は、新しい配置の[ボタンまたは要素名]で最近のプロジェクトを見つけるのに苦労しました。」
• ユーザビリティ上の問題につながった行動に関するテーマ
  • 例: 「2 名の参加者は、[別の場所]で見つけられると予想していました
• その他の興味深い観察またはフィードバックを記録
  • 例: 「3 名の参加者全員は、[X]の変更について混乱を表明しました。理由は…」
• 次の 2 名の参加者を実施する前に対処する予定の問題を記録します。

次の 2 名の参加者の後:

• 追加の問題が見つかった場合:
  • 見つかったユーザビリティ上の問題の数、各問題の説明、行動に関するテーマを記録します（最初の 3 名についての上記形式と同じです）。
  • その他の興味深い観察またはフィードバックを記録します。
  • 追加の 3 名の参加者を実施する前に対処する予定の問題を記録します（上記のとおり、必要に応じて参加者の追加を繰り返します）。
• 追加の問題が見つからなかった場合:
  • 追加のユーザビリティ上の問題が見つからなかったことを記録します
  • 行動に関するテーマと関連するフィードバック
    • 例: 「3 名の参加者全員が、[名前または要素名]を簡単に見つけることができました。」配置は参加者が予想した場所であり、ラベルは直感的だと感じました。

さらに、結果の解釈において役立つコンテキストがあれば提供してください。例えば、参加者が左サイドバーのマージリクエストを選択した場合、この領域での一般的な誤った最初のクリックは、タスクでマージリクエストに言及しているためかもしれないと追記できます。

ページのソースコードを見る - ページの編集 - please contribute.