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

Rapid Iterative Testing and Evaluation（RITE）は、プロトタイプを素早く反復的に複数回評価する ユーザビリティテスト手法 です。目標は統計的な妥当性を判断することではなく、行動を観察し、インサイトを学び、素早くイテレーションを回すことです。これは伝統的なユーザビリティテストとは異なります。なぜなら、最後まで変更を待たずに、テスト中にイテレーションを行うからです。この手法は、テスト中に行った変更の効果性を検証しながら、できるだけ多くのユーザビリティ問題を特定し修正することを目的としています。これにより、ユーザビリティの観点で非常に自信を持てるナビゲーションのプロトタイプができ上がり、提案するソリューションが利用可能かどうかについての不確実性を取り除くのに役立ちます。

なぜこの手法を使うべきか？

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

目標: 新しいナビゲーション設計でユーザーがタスクへナビゲートできるかを学び、基本的なユーザビリティを評価し、デザインで機能している／していない側面を特定し、初期印象などの定性的フィードバックといった追加のインサイトを得る。

この手法で回答できるリサーチ課題のタイプ:

• ユーザーは、あなたのナビゲーション設計でタスクを完了するためにどこへ行けばよいか分かるか？なぜそうなのか？
• ユーザーは、あなたのナビゲーション設計でタスクを完了できるか？なぜそうなのか？
• ユーザーは、あなたのナビゲーション設計で UI 内の新しいものを発見できるか？なぜそうなのか？
• あなたのナビゲーション設計で提案されたレイアウトは納得できるものか？なぜそうなのか？
• ユーザーは、あなたのナビゲーション設計でアプリケーション内の自分の現在地が分かるか？なぜそうなのか？
• ユーザーにとって、あなたのナビゲーション設計の UI 要素は目立つか？なぜそうなのか？

方法論の詳細

ファシリテーションのタイプ: このテストはモデレートありでもモデレーターなしでも実施可能で、参加者から得たフィードバック、観察された行動、参加者がプロトタイプを自分で理解できる能力に対してどれだけ深掘りする必要があるかによります。参加者には思考発話法（think-aloud）を使ってもらいましょう。

求められる忠実度: このタイプのテストには、基本的なインタラクションをテストできるだけの忠実度を持つプロトタイプを使うべきです。例えば、参加者が特定の領域へナビゲートできるかを評価したい場合、参加者がそのタスクを完了できるインタラクティブなプロトタイプが必要で、理想的にはいくつかの「誤った」領域をクリックできるようにします。

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

取得する内容:

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

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

エクスペリエンスに関する定性的フィードバック

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

RITE 調査の実施方法

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

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

結果の報告

Slack や Issue で簡単な／初期の知見を報告するには、次の形式を使ってください。

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

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

次の 2 名の参加者の後:

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

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

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