Rapid Iterative Testing and Evaluation（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 | 明白な原因がない問題、またはタスク指示などの他の要因による問題。 | Category A または B に移せるまで、今後のセッションでさらにデータを収集します。 |
- ドメイン知識と意思決定: チームの意思決定者は、各セッションで得た学びに迅速に対応するため、セッションに参加するか、セッションのインサイトを確認する必要があります。観察された問題が他の人にも問題になりそうかを見積もるには、ドメイン知識が不可欠です。
RITE を成功させるためのロールと期待事項
RITE 調査は、デザインプロトタイプを評価・改善する迅速で反復的なプロセスを約束します。これは、プロセスに関わる全員が自分の責任を認識し、スケジュールに従う場合にのみ成功します（タイミングとスケジュール設定は、RITE 調査の成功に不可欠です）。自分の責任を必ず確認し、どのスケジュールが最も適しているかをチームで決めてください。
- Product Designer: デザインプロトタイプを準備し、そのプロトタイプに基づいて usertesting.com でテストを設定して開始する時間を確保します。セッションが利用可能になったらすぐに視聴して、インサイトを分析します。チーム同期で観察結果を共有し、Product Manager とどの変更が必要かを決定します。特定したすべてのユーザビリティ問題を 3 つのカテゴリ（A ～ C）に分類して記録します。得られた学びに基づき、今後のイテレーションに取り組む時間が必要です。以下のスケジュール例では、週に 2 回のイテレーションをテストすることを目指しています。つまり、その週の時間の大半は RITE の実行に費やすことになります。
- Product Manager: 任意ですが、調査が開始されたらすぐに各リサーチセッションを視聴する時間を確保します。チーム同期で観察結果を共有し、次のイテレーションに向けて Product Designer とどの変更が必要かを決定します。以下のスケジュール例では、週に 2 回のイテレーションをテストすることを目指しています。
- Engineering: 優れたプロダクトを構築することはチームの取り組みであり、実際のユーザーに定期的に触れることは重要です。任意ですが、一部またはすべてのセッションを視聴し、チーム同期でインサイトを共有する時間を確保することを推奨します。
サンプルサイズ
RITE 調査のサンプルサイズは、独自のものであり、従うことが重要です。とても単純です:
- 各イテレーションは N = 3、プロセスの完了は N = 5。
イテレーションを重ねるにつれて N が増え、追加のユーザビリティ問題を捉える機会が得られるため、各イテレーションに必要な参加者は 3 人だけです。時間とともに、より多くのユーザーがプロダクトについてフィードバックを提供し、特定した問題をその都度修正します。
イテレーションで新しいユーザビリティ問題を特定しなければ、RITE プロセスは完了です。ただし、ユーザビリティ問題の大半を特定できる可能性を高めるため、参加者 5 人のサンプルサイズを推奨します。そのため、イテレーションで新しいユーザビリティ問題が出なかった場合は、すべてのユーザビリティ問題を特定したことを確認するために、さらに 2 人の参加者を追加してください。
指標
RITE 調査はユーザビリティテストの方法であるため、ユーザビリティテストに使用するのと同じ測定値を RITE テストにも使用します: 有効性、効率性、満足度、有用性。使用する詳細な測定値は、ユーザビリティテストのハンドブックページで確認できます。
タスク数
含めるタスク数に魔法の数字はありません。参加者が疲弊しないよう、3 ～ 4 個のタスクを用意することがガイドラインです。考慮すべきもう一つの点は、モデレートなしのテストセッションは最大 15 ～ 20 分、モデレートありのセッションは最大 60 分にすることです。モデレートなしのテストには調査が長すぎる可能性がある場合、複数の usertesting.com セッションにタスクを分割する必要があるかもしれません。
タスクを作成する際に覚えておくべき重要なことは、現実的なユーザー目標を反映することです。タスクを作成する際に JTBD を考慮すると、ユーザー目標に焦点を保つのに役立ちます。
RITE 調査アプローチの例
RITE 調査は、最短で 1 日、または必要なだけ長く実施できます。以下の例は 5 日間にわたり、プロセスを説明するためだけに使用します。チームが別のペースを望む場合は、タイムラインを適宜調整してください。スケジュール例は、usertesting.com を使用するモデレートなしのユーザビリティテストに合わせて作られています。モデレートありのセッションを実施する場合は、リクルーティングに追加の時間を確保してください。
Day 1 - 準備
チームを集め、次についてタイムラインに合意します:
- テストセッションはいつ usertesting.com で公開されますか?
- 全員がいつ録画を視聴しますか?
- いつ Dovetail にインサイトを入力しますか? また誰が入力しますか?
- 次のイテレーションで行う意思決定と調整をどのように決めますか? 例えば、Dovetail で非同期に話し合うか、同期ミーティングを使用できます。
プロトタイプとテストスクリプトを準備します（これは、ベースラインのユーザビリティテストで使用したものと同じか類似している必要があります）。
Day 2 - テスト日
パイロットセッションを実施して録画を視聴し、必要に応じてテスト計画を調整します。
次に、usertesting.com で 3 人の参加者にテストを開始します。テスト結果がどれほど早く戻るかに応じて、インサイトを分析し、特定したユーザビリティ問題を RITE 分類を使って整理します。この Figjam ボードのコピーを自由に使ってください。
Day 3 - チームとの同期
チームの全員に 3 つのセッションを視聴し、特定したユーザビリティ問題を把握する機会が必要です。学びを共有し、次のセッションのスコープを決定します。それに合わせてプロトタイプを調整し、準備します。新しいテストラウンドの前に Category A の問題を修正する必要があることを覚えておいてください。
Day 4 - テスト日
Day 2 と同じです: usertesting.com で 3 人の参加者にテストを開始します。インサイトを分析し、特定した問題を分類します。
Day 5 - チームとの同期
Day 3 と同じです: チームの全員にセッションを視聴し、学びにどう対応するかの決定に貢献する機会が必要です。
Category B の問題に対するソリューションを見つけるのにかかる時間や、対応すべき他の活動に応じて、同じマイルストーンまたは今後のマイルストーンでこのプロセスを繰り返せます。Category B（明白なソリューションがあるがすぐに実装できない問題）のユーザビリティ問題を、今後の作業計画のために GitLab に記録します。
参加者 5 人のサンプルでユーザビリティ問題が見つからなくなり、ソリューションがユーザーフレンドリーであると確信できたときに、プロセスは完了したと見なされます。これは 1 つのマイルストーン内では起こらない場合があります。
よくある質問
RITE 調査を 1 日で実施できますか?
はい、十分に可能です。慎重に計画すれば、モデレートありでもモデレートなしでも、usertesting.com を使って RITE 調査を 1 日で完了できます。重要なのは、慎重な計画とスケジュール設定です。
RITE テストをデフォルトのユーザビリティテスト方法にできますか?
要件を満たしている限り、もちろんできます! RITE を通じてテストした体験については、従来のユーザビリティ調査よりもユーザビリティのパフォーマンスに確信を持てます。なぜでしょうか? 途中でソリューションをテストしており、それらがうまく機能することを知っているからです!
5 人の参加者でクリーンなテストを実行する時間がありません。どうすればよいですか?
その時点で、テストはもはや RITE 調査ではなくなり、調査後に対処するソリューションを未テストのまま後送りする従来のユーザビリティ調査の構成になります。
c955a93f)