モデレーターなしユーザビリティテスト
GitLab におけるモデレーターなしユーザビリティテストの活用。
GitLab では、Solution Validation における一部のモデレーターなしテストに UserTesting.com を使っています。モデレーターなしユーザビリティテストは、ユーザーから評価フィードバックを非常に素早く得ることを可能にし、より独立した方法で(より少ないリソースで)素早くイテレーションを回せるようにしてくれます。
モデレーターなしユーザビリティテストとは何ですか?
モデレーターなしユーザビリティテストとは、モデレーターが立ち会わずにユーザビリティテストを行う方法と定義されます。つまり、参加者はすべてのタスク/指示/質問を 1 人で進めることになります。一般的には、参加者パネルも提供しているサービスを利用して実施されます。モデレーターなしユーザビリティ調査のアウトプットは動画であり、リサーチを立ち上げた本人が視聴して分析する必要があります。
GitLab と UserTesting.com
参考までに、UserTesting.com で実施できる調査の本数は無制限ではないため、UserTesting.com で調査を開始する際はその点を考慮してください。
長所と短所
モデレーターなしテストの利用には長所と短所があることに留意し、モデレーターなしとモデレートありのどちらを選ぶか判断する前に、それらを検討することが重要です。具体的には次のとおりです。
モデレーターなし
- 長所:
- 非常に短時間で結果が得られる(数時間)
- スケジュール調整や謝礼の調整が不要
- 多様な参加者パネルが大規模に利用可能
- 短所:
- 参加者と会話して軌道修正したり、タスクを理解しているか確認することができない
- タスク/指示/質問が明確に作成されている必要がある
モデレートあり
- 長所:
- 参加者と議論をしながら、観察された行動を深掘りできる
- 必要に応じて軌道修正ができる
- 短所:
- 時間がかかる(数週間)
- スケジュール調整と謝礼の調整が必要
調査のベストプラクティス
- まずは 1〜2 名の参加者で調査を開始してください。 これがパイロットとなり、その結果を使って参加者がタスクと質問を理解しているかを判断します。最悪なのは、いきなり 5〜8 名の参加者全員で調査を実施してから、彼らが意図とは異なる方法でタスクや質問を解釈していたと気づくことです。
- 評価質問をする場合は「なぜそう評価したのですか?」と尋ねてください。 私たちは定性データを扱っているため、評価の背後にある なぜ を理解したいのです。
- 慎重かつ賢明にスクリーニングしてください。 モデレーターなしテスターは調査ごとに報酬を得るため、参加する調査が多いほど多く支払われます。その結果、調査に参加するためにスクリーナーで嘘をついた参加者に当たることがあります。その可能性を減らすために、効果的なスクリーナーの書き方 のハンドブックページが用意されています。
- 調査は長すぎないようにします。 目安として、テストは 15〜20 分の範囲に収まるようにしてください。これはプレビューモードや 1〜2 名の小規模なサンプルでテストを通してみることで測れます。より短いテストの場合は short test 形式の利用を検討してください。
プロトタイプのベストプラクティス
プロトタイプに Figma を使う場合、テストにリンクを添付する前に押さえておきたいヒントがいくつかあります。
- プロトタイプを
Fit to screenに設定して、参加者の画面いっぱいに表示されるようにします。 Show hotspot hints on clickのチェックを外します。参加者はこれを探す傾向があり、テスト結果にバイアスがかかる可能性があります。- ホットスポットヒントを無効にしても、Figma ではクリック可能領域にカーソルを合わせるとカーソルが変化します。メインのクリック対象が明らかになりすぎないよう、プロトタイプ内に追加のクリック可能なモック要素を用意することを検討してください。
Show Figma UIのチェックを外します。これにより参加者は余計な情報を見ずにプロトタイプだけに集中できます。- 共有設定が
allow the participant to view the prototype, and only the prototypeになっていることを確認してください。 - 参加者はタブでプロトタイプの名前を確認できるため、ここに事前情報になるような内容を含めないようにします。
よくある質問
- 自分の調査がモデレーターなしテストに適しているかどうかをどう判断すればよいですか? 詳細を説明する必要がなく、参加者が脱線するリスクが低い調査であれば、おそらくモデレーターなしテストに向いています。モデレーターなしテストに適しているかどうか疑問があれば、UX リサーチャーに相談してください。
- 問題検証に関する質問をしたい場合はどうしますか? UserTesting.com は最適な選択肢ではありません。代わりに、リクルーティングプロセス を通じて別の方法で参加者を見つけてください。
- 1 つの調査につき参加者は何名依頼すべきですか? モデレーターなしは評価調査に利用するため、サンプルサイズは 1 調査あたり 5〜8 名にしてください。
- 既存の GitLab ユーザーでカスタムパネルを作成できますか? カスタムパネルを作ることは可能ですが、UserTesting パネルを利用し、保存済みのスクリーナー質問を使って特定の役割の GitLab ユーザーを絞り込むことを推奨します。
- 特定の条件でスクリーニングできますか? もちろん、好きな条件でできます。スクリーナーの条件が厳しいほど、目的の参加者を見つける可能性は下がります。UserTesting.com にはすでに GitLab のスクリーニング質問がいくつか保存されているので、それらを活用できます。UserTesting.com の「Saved Screener Questions」から見つけられます。
- デモグラフィックフィルターのチェックボックスはどう機能しますか? デモグラフィックフィルターは次のように動作します。フィルターを何も選択しない場合、参加者プールには UserTesting.com パネルの誰もが含まれます。フィルターを選択し始めると、参加者プールは指定したフィルターに特化していき、結果として候補者プールは小さくなります。フィルターを何も選択しないことで誰かを除外することにはならず、むしろこの方法でより多くの参加者を対象にできます。デモグラフィックフィルターはできるだけ一般的に保ち、スクリーナー質問で具体的なタイプの参加者を絞り込むことを推奨します。
- GitLab の要件を満たすために必須のスクリーニング質問はありますか? はい。少なくとも「Individual contributor license agreement」の質問は必ず尋ねる必要があり、場合によっては「IP Assignment」の質問も尋ねます。これらはいずれも UserTesting.com 内の「Saved Screener Question」として保存されており、スクリーニング条件に追加できます。
- あまり良くない参加者に当たってしまいました(スクリーニング基準を満たしていない、あまり発言してくれない、指示に従わない等)。どうすればよいですか? UserTesting.com では参加者を 5 段階で評価できます。1 星評価を付けると、UserTesting.com のサポートから連絡が来て、代替の参加者を希望するか尋ねられます。代替を依頼することもできますし、代わりにクレジット返還を依頼することもできます。
- UserTesting.com の利用回数を気にする必要はありますか? 年内に利用できる「ユニット」数には上限があることを認識しておいてください。無制限ではありません。とはいえ、必要なだけ UserTesting.com を活用することを推奨しています。
- アカウントの取得方法は? Okta 経由でアクセスできる Lumos からリクエストしてください。UserTesting.com の席は現時点ではプロダクトデザイナーと UX リサーチャーのみに割り当てられています。これらの職種がソリューション検証テストに密接に関わっているためです。
- リクルーティングや謝礼はどう扱われますか? UserTesting.com パネルを通じてリクルーティングする場合、謝礼は自動的に処理されます。心配する必要はありません。
- UserTesting.com 調査のアウトプットは何ですか? 動画クリップと、アンケート質問をした場合はデータのサマリーです。動画クリップは Dovetail で使用するためにダウンロードできます。
- UserTesting.com パネルで必要なタイプの参加者が見つかりません。どうすればよいですか? @asmolinski2 に連絡してください。ただしその場合は、UX リサーチャーが謝礼を処理する必要があります。
- 「short test」とは何ですか?UserTesting で調査を作成する際にこのオプションが見えます。 「short test」は UserTesting の機能で、3〜5 問の短い調査を実施できます。回答が必要な軽量なリサーチ課題に最適です。例えば、参加者がスクリーンショットやワークフロー内のどこをクリックするかを知りたいファーストクリック調査などです。調査の長さは 5 分を超えないようにしてください。short test を利用するメリットは、標準的な UserTesting 調査の半分のクレジットで済むことです。
- 質問がたくさんあります!誰に連絡すればよいですか? まずは UserTesting.com のトレーニング資料(UserTesting ログインが必要)を確認してください。それで解決しない場合は、Slack チャンネル #ux_research_usertesting で質問してください。
- UserTesting.com の「Enable Participant View」を有効にすべきですか? この設定を有効にすると、参加者が調査に取り組む際の表情を捉え、彼らがどう感じているかについてのインサイトを多く得られます。ただし、必須ではありません。カメラで取得したいデータが「行動への自信」のような場合は、複数選択(単一選択)の質問や、口頭で自信を尋ねる質問を追加することを検討してください。
- クイックスタートで使えるテンプレートはありますか? はい、アカウントテンプレート を確認して、そこから 1 つ選んでください。
- 調査で質問順のバイアスをどう除去すればよいですか? プロトタイプ A 対 プロトタイプ B を評価する場合、balanced comparison を使って参加者が見るバリエーションの順序を入れ替え、結果に対する順序バイアスのリスクを軽減できます。
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (
bfd74782)