迅速反復テストと評価（RITE）
Rapid Iterative Testing and Evaluation (RITE)は、ユーザビリティの問題に対するソリューションを、迅速かつイテレーション的な方法で複数回評価するユーザビリティテスト手法です。目的は、ユーザビリティの問題を特定するだけでなく、特定された問題に迅速に対応し、それらに対応する新しいソリューションをテストすることです。RITE 調査の最終結果は、完全にユーザビリティテストされた体験（ユーザビリティの問題のソリューションを含む）です。これは、提案されたソリューションが使えるかどうかについての不確実性を取り除くのに役立ち、（ユーザビリティの文脈で）出荷について高い確信を持つことができる体験につながります。
RITE 調査の仕組み
RITE 調査の実施は非常に簡単で、従来のユーザビリティテストの実施と似ています。違いは次の点です。1) サンプルサイズ、2) 問題が見つかったらすぐに対処する。下の図は RITE 調査を実施する際に従うワークフローを示しています。
要約すると:
- ステップ 1: 3 人の参加者から開始
- 問題が見つかった場合は対処し、新しい 3 人の参加者でステップ 1 を繰り返します
- 問題が見つからない場合はステップ 2 に進みます
- ステップ 2: さらに 2 人の参加者を追加
- 問題が見つかった場合は対処し、新しい 3 人の参加者でステップ 1 から再開します
- 合計 5 人の参加者をテストした後で問題が見つからない場合、調査は完了です！
RITE の要素
他のユーザビリティテストプロトコルと比較して、RITE は次の要素で構成されています:
- 迅速で反復的（イテレーティブ）: RITE テストは、少人数の参加者で定期的に実行されます。特定されたユーザビリティの問題ごとに、すぐに修正し、新しい参加者セットで再度テストすることを目指します。このプロセスは、新しいユーザビリティの問題が特定されなくなるまで続きます。
- 問題の分類: テストセッションを迅速に進めるために、セッションで特定されたユーザビリティの問題は次のカテゴリに分類されます。
| カテゴリ | 説明 | 対応方法 |
|---|---|---|
| A | テキスト変更、ボタンのリラベリングなど、原因が明らかでソリューションが明らかな、プロトタイプですぐに実装できる問題。 | 解決策をすぐに実装し、これが次のテストセッションのバージョンになります。 |
| B | 原因が明らかでソリューションが明らかだが、迅速に／次のテストセッションまでに実装できない問題。 | これらの問題に対処するソリューションの作業を開始し、今後のセッションでテストします。 |
| C | 原因が明らかでない、またはタスクの指示など他の要因による問題。 | カテゴリ A または B に昇格できるまで、今後のセッションでより多くのデータを収集します。 |
- ドメイン知識と意思決定: 各セッションからの学びに迅速に反応するために、チームの意思決定者がセッションに出席するか、セッションのインサイトに追いつく必要があります。観察された問題が他の人にとっても問題になる可能性が高いかどうかを推定するには、ドメイン知識が不可欠です。
RITE を成功させるための役割と期待
RITE 調査は、デザインプロトタイプを評価・改善するための迅速かつイテレーション的なプロセスを約束します。それは、プロセスへのすべての貢献者が自分の責任を認識し、スケジュールに従う場合にのみ成功します（タイミングとスケジューリングは、RITE 調査の成功に不可欠です）。個々の責任について自分自身で情報を得て、チームと一緒に最適なスケジュールを決定してください。
- Product Designer: デザインプロトタイプを準備し、プロトタイプに基づいて usertesting.com でテストをセットアップし、それを起動する時間を確保します。セッションが利用可能になったらすぐに視聴し、インサイトを分析します。チームの同期で観察を共有し、Product Manager とどのような変更が必要かを決定します。識別されたユーザビリティ問題をすべて 3 つのカテゴリ（A-C）に分類して文書化します。学びに基づいて、将来のイテレーションに取り組む時間が必要です。以下の例のスケジュールでは、週に 2 つのイテレーションをテストすることを目指しており、つまりこの週は、時間の大部分が RITE の実行に費やされることになります。
- Product Managers: オプションですが、調査が開始されたらすぐに各調査セッションを視聴する時間を確保します。チームの同期で観察を共有し、Product Designer と次のイテレーションのためにどのような変更が必要かを決定します。以下の例のスケジュールでは、週に 2 つのイテレーションをテストすることを目指しています。
- エンジニアリング: 素晴らしい製品を作るのはチームの努力であり、実際のユーザーに定期的にさらされることは重要です。オプションですが、いくつかまたはすべてのセッションを視聴し、チームの同期でインサイトを提供する時間を確保することをお勧めします。
サンプルサイズ
RITE 調査のサンプルサイズは独特で、従うことが重要です。かなりシンプルです:
- 各イテレーションで N = 3、プロセスを完了するために N = 5。
イテレーションごとに 3 人の参加者だけが必要なのは、より多くのイテレーションが行われるにつれて N が増加し、追加のユーザビリティ問題を捉える機会が提供されるためです。時間とともに、より多くのユーザーが製品にフィードバックを提供し、進めながら特定した問題を修正していきます。
イテレーションで新しいユーザビリティ問題が特定されない場合、RITE プロセスは完了です。ただし、ユーザビリティ問題の大部分を特定する可能性を高めるために、5 人の参加者というサンプルサイズが推奨されます。したがって、イテレーションで新しいユーザビリティ問題がもたらされない場合は、すべてのユーザビリティ問題が特定されたことを確認するために、さらに 2 人の参加者を追加してください。
メトリクス
RITE 調査はユーザビリティテスト手法であるため、ユーザビリティテストに使用されるのと同じ尺度が RITE テストにも使用されます: 効果、効率、満足度、有用性。使用する詳細な尺度は、ユーザビリティテストハンドブックページにあります。
タスクの数
含めるタスク数に関して、魔法の数字はありません。ガイドラインとして、参加者が疲れたり消耗したりしないように3〜4 個のタスクを用意してください。もう 1 つの考慮事項は、非モデレートテストセッションは最大 15〜20 分、モデレートセッションは最大 60 分であるべきだということです。非モデレートテストには調査が長すぎる可能性がある場合、複数の usertesting.com セッションに分けてタスクを分割する必要があるかもしれません。
タスクを書くときに覚えておくべき重要なことは、現実的なユーザーの目標を反映していることです。タスクを作成する際に JTBD を考慮することで、ユーザーの目標に焦点を保つことができます。
RITE 調査のサンプルアプローチ
RITE 調査は、わずか 1 日で行われることもあれば、必要な限りの長さで行われることもあります。以下の例は 5 日間にわたっており、プロセスを説明するためにのみ使用されます。チームが異なるペースを好む場合は、スケジュールを適宜調整してください。例のスケジュールは、usertesting.com を使用した非モデレートユーザビリティテストに合わせて構築されています。モデレートセッションを実行することを好む場合は、リクルートに追加の時間を確保してください。
1 日目 - 準備
チームを集めて、次のタイムラインに合意します:
- usertesting.com でテストセッションをいつ公開しますか？
- 録画をいつ全員で視聴しますか？
- Dovetail にいつインサイトを入力し、誰が行いますか？
- 次のイテレーションで行う決定や調整をどのように決めますか？例えば、Dovetail で非同期で議論することも、同期ミーティングを使用することもできます。
プロトタイプとテストスクリプト（これは、ベースラインユーザビリティテストで使用したものと同じか類似している必要があります）を準備します。
2 日目 - テストの日
パイロットセッションを実行し、録画を視聴し、必要に応じてテスト計画を調整します。
次に、usertesting.com で 3 人の参加者にテストを起動します。テストの結果が返ってくる速さによりますが、インサイトを分析し、RITE 分類を使用して特定されたユーザビリティ問題を整理します。この Figjam ボードのコピーを自由に使用してください。
3 日目 - チームとの同期
チーム全員が 3 つのセッションを視聴し、特定されたユーザビリティ問題を認識する機会を持つ必要があります。学んだことを共有し、次のセッションのスコープを決定します。それに応じてプロトタイプを調整・準備します。新しいテストラウンドの前にカテゴリ A の問題を修正する必要があることを忘れないでください。
4 日目 - テストの日
2 日目と同じ: usertesting.com で 3 人の参加者にテストを起動します。インサイトを分析し、特定された問題を分類します。
5 日目 - チームとの同期
3 日目と同じ: チーム全員がセッションを視聴し、学んだことに基づいてどう行動するかを決定するために貢献する機会を持つ必要があります。
このプロセスは、カテゴリ B の問題のソリューションを見つけるのにかかる時間や、対処する必要のあるその他のアクティビティに応じて、同じマイルストーンまたは今後のマイルストーンで繰り返すことができます。今後の作業計画のために、カテゴリ B のユーザビリティ問題（明らかなソリューションがあるがすぐには実装できない問題）を GitLab で文書化してください。
5 人の参加者のサンプルでユーザビリティ問題が見つからなくなり、ソリューションがユーザーフレンドリーであることに自信を持てたときに、プロセスは完了したとみなされます。これは 1 つのマイルストーン内に発生しない場合があります。
よくある質問
RITE 調査を 1 日で実施できますか？
はい、確かに可能です。慎重な計画があれば、usertesting.com を使用して、モデレートでも非モデレートでも、1 日で RITE 調査を完了できます。鍵は慎重な計画とスケジューリングです。
RITE テストをデフォルトのユーザビリティテスト手法にすることはできますか？
要件が満たされている限り、もちろんできます！RITE を通じてテストされた体験のユーザビリティパフォーマンスは、従来のユーザビリティ調査を通じてよりも、より自信を持てるでしょう。なぜでしょうか？それは、途中でソリューションをテストし、それらがうまく機能することを知っているからです！
5 人の参加者できれいなテストを実行する時間がありません。どうすればよいですか？
その時点で、テストはもはや RITE 調査ではなく、調査後に対処されたソリューションがテストされないままプッシュアウトされる、従来のユーザビリティ調査の構成になります。
bfd74782)