ユーザビリティテスト

GitLab におけるユーザビリティ

「ユーザビリティ」という用語はさまざまなことを意味します。GitLab では、ユーザーリサーチを実施しプロダクトをデザインするとき、ユーザビリティを次のように定義します。

使用可能であるためには、インタラクティブシステムが有用で、効率的で、効果的で、満足でき、学習しやすいものである必要があります。

• 有用性は、プロダクトによってユーザーが目標を達成できる度合いです。
• 効率性は、一定の時間内にユーザーの目標を正確かつ完全に達成できる速さです。
• 有効性は、インタラクティブシステムがユーザーの期待どおりに動作する度合いと、ユーザーが意図したことを実行するためにシステムを利用しやすい度合いを指します。
• 学習しやすさは有効性の一部であり、事前に定めた一定量・期間のトレーニング（まったくない場合もあります）の後に、ユーザーがインタラクティブシステムを定められた能力レベルまで操作できることに関係します。また、利用頻度の低いユーザーが、使用していない期間の後にシステムを再習得できることを指す場合もあります。
• 満足度は、プロダクトに対するユーザーの知覚、感情、意見を指します。

注: この定義は、Handbook of Usability Testingおよび International Usability and UX Qualification Board curriculumの情報に基づいています。

ユーザビリティテスト

ユーザビリティテストは、代表的なユーザーとともにプロダクト体験を評価するプロセスです。目的は、ユーザーが一連のタスクをどのように完了するかを観察し、遭遇する問題を理解することです。ユーザーはしばしば予想とは異なる方法でタスクを実行するため、この定性的手法は、ユーザーの動機やニーズを理解することを含め、ユーザーがそのようにタスクを実行する理由を明らかにするのに役立ちます。GitLab では、ユーザビリティテストはソリューション検証の一部です。

GitLab では、定期的にユーザビリティベンチマーク調査も実施します。これらもユーザビリティに焦点を当て、GitLab 全体の特定のタスクとワークフローについて、パフォーマンスと UX のベンチマークを設定するために使用します。そのため、通常のユーザビリティテストよりもはるかに厳密で時間がかかります。

さまざまな種類のユーザビリティテスト

一般的に、次のように区別できます。

モデレーターありとモデレーターなしのユーザビリティテスト

モデレーターありのテストには、参加者をタスクに沿って案内するモデレーターがいます。これにより、参加者は自分の体験について会話でき、「なぜ？」という質問への答えを見つけるのに役立ちます。

一方、ユーザーはモデレーターの立ち会いなしに、モデレーターなしのユーザビリティテストを自分で完了します。これは非常に直接的な質問がある場合に役立ちます。

形成的と総括的なユーザビリティテスト

形成的ユーザビリティテストは、ユーザビリティ上の問題を発見するための継続的な評価です。プロダクトの 1 つの特定機能またはその一部に焦点を当てるなど、より範囲が小さい傾向があります。評価にはプロトタイプがよく使用されます。

総括的ユーザビリティテストは、範囲がより大きい傾向があり、実際のプロダクトで実施します。ユーザーが特定の問題を経験する理由の詳細が不足している場合や、まずどれほど使いやすいかを検証したい場合に有用です。

ユーザビリティテストを実施する手順

1. リサーチ質問を設定します。
2. ユーザビリティテストで焦点を当てるタスクを特定します。
   • 含めるタスク数に魔法のような数はありません。参加者が疲弊しないように、3〜4 個のタスクを用意することがガイドラインです。考慮すべきもう 1 つの点は、モデレーターなしのテストセッションは最大 15〜20 分、モデレーターありのセッションは最大 60 分にする必要があることです。
   • タスクを書く際に覚えておくべき重要な点は、現実的なユーザー目標を反映することです。タスクの作成時に JTBD を考慮すると、ユーザー目標に焦点を保つのに役立ちます。例を含む、よいタスクを書くためのヒントを参照してください。
3. 成功がどのような状態かを定義します。
   • ユーザーでテストする前に、目標とする完了率など、成功がどのような状態かについてステークホルダー間で合意します。MeasuringUのこの記事は、ベースラインとして 78% を使用することを提案しています。一方、最低 92% であれば上位四分位の完了率を満たします。ただし、100% を目指すことも不合理ではありません。各調査と各機能に必要な成功基準を決めるのは各チーム次第です。
4. 対象オーディエンスを特定し、採用を開始します。
5. プロトタイプまたはデモ環境を準備します。
   • テストするモードを考慮します。調査間の一貫性を確保しながらテスト効率を維持するため、ユーザビリティテストにはデフォルトでライトモードを使用します。ダークモードでのテストは意図的な方法論上の選択とし、そのモードがリサーチの主な焦点である場合、モードの違いが調査結果に大きな影響を及ぼす可能性がある場合、または特定のユーザーの好みやアクセシビリティ要件に対応する場合にのみ考慮してください。ダークモードのテストを考慮すべき例: モード間での視覚的階層の影響の調査、異なるモードでのタスクパフォーマンスの違いの調査、照明などの環境コンテキストへのモード適応の分析、モード間でのユーザーエンゲージメントパターンの探索、デジタルエコシステム内でのモード互換性と技術統合の検討。
6. 収集するタスクと指標を含むテストスクリプトを作成します。
   • テストを設定して、これらのユーザビリティ要因を測定します。これにより、時間の経過とともに一貫して改善を測定し、システムユーザビリティへの影響を評価できます。エラー率やユーザーが助けを必要とした回数など、ユーザビリティ上の問題を理解するために測定できる他の多くの指標があります。リサーチトピックに役立つ場合は、自由に使用してください。
   • 特にモデレーターなしのテストでは、タスクを進めながら思考を発話するよう参加者に伝えます。
   • 優れたユーザビリティテストスクリプトの書き方について、より詳細なヒントとコツを確認してください。
   • UserTesting でモデレーターなしのユーザビリティテストを実施する場合は、「Account templates」セクションにあるユーザビリティ指標テンプレートからテストを作成します。UserTesting には私たちのものに似た指標を取得するための task success と difficulty のネイティブオプションがありますが、これらは調査に必要な同じユーザビリティ指標ではありません。代わりにこのテンプレートに記載されたオプションを使用してください。
   • 5 分未満で実行するモデレーターなしのユーザビリティテストを実施する場合は、テスト計画の作成時に Short test オプションをオンにします。
7. ユーザビリティテストをテストするためのパイロットセッションを実施します。
8. リサーチデータを分析します
   • 各タスクについて、成功または失敗したユーザー数と、失敗した理由を統合します。
   • 各タスクについて、効率性に関する質問の平均スコアを計算します。スコアを付けた理由のパターンを探します。
   • 満足度と有用性に関する質問の平均スコアを計算します。スコアを付けた理由のパターンを探します。
   • その他に得た興味深い観察を記録します。
9. 洞察を Dovetail に記録します。実行可能な洞察がある場合は、GitLab UX Research プロジェクトにも記録されていることを確認してください。
10. 次のステップを決定します。
    • 実行可能な洞察にはフォローアップが必要です。特定されたユーザビリティ上の問題の優先順位を決めるために、対応するメンバーと協力してください。提案したソリューションを検証するために、別のユーザビリティ調査を実施することを忘れないでください。

測定するユーザビリティ要因

これらの要因についてさらに学ぶには、私たちのユーザビリティの定義を参照してください。

有効性

• 何を測定しますか？
  • 有効性は、合格率を計算することで判定できます。これは各タスクの成功率または完了率を示します。
• どのように測定しますか？
  • 合格率は、タスクを完了できた参加者数を参加者総数で割ることで判定できます。
  • 参加者が失敗する理由も観察して記録してください。
• なぜ測定しますか？
  • 私たちはユーザーが目標を達成できることを望んでいます。ユーザーが失敗する理由と場所を理解すると、体験の改善に役立ちます。

効率性

• 何を測定しますか？
  • 効率性は、タスクの容易さについての参加者の認識を理解することで測定できます。
• どのように測定しますか？
  • 各タスクの後で Single Ease Question を尋ねます。
    • 「全体として、このタスクは…」
      - 非常に難しかった
      - 難しかった
      - 簡単でも難しくもなかった
      - 簡単だった
      - 非常に簡単だった
      「なぜですか？」
  • 参加者が回答した直後に、そのように評価した理由を尋ねるようにしてください。
• なぜ測定しますか？
  • 特に評価が低い場合は、参加者が評価を付けた理由を理解することが重要です。参加者数も少ないユーザビリティテストでは、これは特に重要です。

満足度

• 何を測定しますか？
  • 満足度は、体験についての参加者の認識を理解することで判定できます。
• どのように測定しますか？
  • すべてのタスクを完了した後、満足度評価の質問をします。
    • 「この体験の品質をどのように評価しますか？」
      - 非常に良い
      - 良い
      - 良くも悪くもない
      - 悪い
      - 非常に悪い
  • 参加者が回答した直後に、そのように評価した理由を尋ねるようにしてください。
• なぜ測定しますか？
  • 参加者が評価を付けた理由を理解することが重要です。参加者数も少ないユーザビリティテストでは、これは特に重要です。

有用性

• 何を測定しますか？
  • 有用性は、テストした機能によって参加者が目標をどの程度達成できるようになるかについての認識を理解することで判定できます。
• どのように測定しますか？
  • すべてのタスクを完了した後、調整済みの UMUX Lite 質問をします。
    • 「あなたは今、<Feature/Scenario> の私たちの実装を体験しました。次の記述にどの程度同意または反対しますか: <Feature/Scenario> には、私自身の仕事で行う必要があることに必要な能力があります。」
      - 強く同意する
      - 同意する
      - 同意も反対もしない
      - 反対する
      - 強く反対する
  • 参加者が回答した直後に、そのように評価した理由を尋ねるようにしてください。
• なぜ測定しますか？
  • このスコアは、通常のパフォーマンス指標の 1 つである System Usability Scale (SUS) スコアと高く相関します。
  • 特に評価が低い場合は、参加者が評価を付けた理由を理解することが重要です。参加者数も少ないユーザビリティテストでは、これは特に重要です。

よくある質問

ユーザーテストで、参加者がタスクを正常に完了したかを尋ねるべきではないのはなぜですか？

これは自己申告の測定であり、正しい場合も正しくない場合もあります。参加者がタスクを正常に完了したと示した場合も、定義した成功に基づいて実際に完了したかを確認する必要があります。ユーザーから必要なデータだけを取得することが重要であり、実際の行動と照合して回答を二重確認する必要があることを考慮すると、最初から質問を省くことを提案します。

効率性を評価するために UserTesting.com のネイティブタスク指標 difficulty を使用すべきではないのはなぜですか？同じではありませんか？

UserTesting.com のタスク指標 difficulty は似ていますが、Single Ease Question とは異なる評価尺度を使用します。現時点で、UserTesting.com には尺度ラベルを私たちのものに合わせて変更する選択肢がありません。

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