ユーザビリティテスト

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

「ユーザビリティ」という言葉はさまざまな意味を持ち得ます。GitLab では、ユーザーリサーチを実施し製品を設計する際に、ユーザビリティを次のように定義しています。

ユーザブル（利用可能）であるためには、インタラクティブなシステムは、有用（useful）、効率的（efficient）、効果的（effective）、満足できる（satisfying）、習得可能（learnable）である必要があります。

• 有用性（Usefulness） は、製品がユーザーの目標達成をどの程度可能にしているかの度合いです。
• 効率性（Efficiency） は、ユーザーの目標が一定時間内にどれだけ素早く、正確かつ完全に達成できるかを表します。
• 効果性（Effectiveness） は、インタラクティブなシステムがユーザーの期待通りに動作する度合い、およびユーザーが意図することを行うためにシステムをどれだけ簡単に利用できるかを指します。
• 習得可能性（Learnability） は効果性の一部であり、ユーザーが事前に定められたトレーニング量・期間（まったくない場合もあり得ます）の後、インタラクティブなシステムを一定の習熟度で操作できる能力に関わります。これは、活動していない期間の後に低頻度のユーザーがシステムを再学習する能力も指します。
• 満足度（Satisfaction） は、ユーザーの製品に対する認識、感情、意見を指します。

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

ユーザビリティテスト

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

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

ユーザビリティテストの異なるタイプ

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

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

モデレートありテストでは、モデレーターが立ち会い、参加者をタスクへ導きます。これにより、ユーザーのエクスペリエンスについて会話でき、「なぜ？」という質問への答えを見つけるのに役立ちます。

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

形成的（formative）対総括的（summative）のユーザビリティテスト

形成的ユーザビリティテストは、ユーザビリティ問題を発見するための継続的な評価です。スコープが小さい傾向があり、製品の特定機能や一部のみに焦点を当てます。多くの場合、評価にはプロトタイプが使われます。

総括的ユーザビリティテストは、スコープが大きく、ライブの製品で実施される傾向があります。なぜユーザーが特定の問題を経験しているかの詳細が不足している場合や、そもそも使いやすさを最初に検証したい場合に役立ちます。

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

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

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

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

効果性

• 何を測定するか？
  • 効果性は合格率を計算することで判断できます。これは各タスクの成功率（完了率）を示します。
• どのように測定するか？
  • 合格率は、タスクを完了できた参加者数を全参加者数で割ることで判断できます。
  • 参加者が なぜ 失敗したかを観察・文書化することも忘れないでください。
• なぜ測定するのか？
  • 私たちはユーザーが目標達成に成功することを望みます。どこでどう失敗するかを理解することは、エクスペリエンスの改善に役立ちます。

効率性

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

満足度

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

有用性

• 何を測定するか？
  • 有用性は、テストされた機能が目標達成にどれだけ役立つかについての参加者の認識を理解することで判断できます。
• どのように測定するか？
  • すべてのタスクが完了したら、調整版の UMUX Lite の質問を尋ねます。
    • 「あなたは私たちの <Feature/Scenario> の実装を体験しました。次の記述にどの程度同意または不同意しますか: <Feature/Scenario> は自分の仕事で必要なことに対して必要な機能を備えている。」
      - 強く同意する
      - 同意する
      - どちらでもない
      - 同意しない
      - 強く同意しない
  • 返答の直後に、参加者がそのように評価した 理由 を必ず尋ねてください。
• なぜ測定するのか？
  • このスコアは システムユーザビリティスケール（SUS）スコア、つまり 定期的なパフォーマンス指標 の 1 つと高い相関があります。
  • 評価の理由、特に評価が低い場合の理由を理解することが重要です。これはユーザビリティテストで参加者数も少ない場合に特に重要です。

よくある質問

ユーザーテストで、参加者がタスクを成功裏に完了したかを尋ねるべきでない理由は？

自己報告型の指標であり、真実かどうか分かりません。参加者がタスクを成功裏に完了したと示しても、定義した成功基準に照らして本当に完了したかをチェックする必要があります。ユーザーからは必要なデータだけを取得することが重要で、実際の行動と照合する必要があるなら、最初から尋ねないことをお勧めします。

UserTesting.com のネイティブなタスク指標 difficulty を効率性の評価に使うべきでない理由は？同じではないのですか？

UserTesting.com のタスク指標 difficulty は似ていますが、Single Ease Question とは異なる評価スケールを使っています。現時点で UserTesting.com のスケールラベルを私たちのものに合わせて変更するオプションはありません。

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