ナビゲーションのための比較テスト

比較的・定性的なユーザビリティテスト を使うと、デザインプロセスの初期段階 で 2〜3 のデザインに対するフィードバックを得て、異なるデザインの方向性の長所と短所を評価できます。これはベンチマークやデザインの測定に焦点を当てた定量的な比較スタディとは異なります。

デザインプロセスのこの段階での焦点は、異なるデザインで何がうまくいっていて何がうまくいっていないかを特定し、どちらを採用するかについてのインサイトを提供することです。これは被験者内 (within subjects) の手法であり、各参加者がすべてのデザインを見ることになります。複数のデザインを体験することで、参加者は見た異なるデザインを比較対照できるため、有用なフィードバックを提供できるのです。

この手法を使う理由

異なる特徴を持つ 2〜3 のナビゲーションデザインがあり、さらに投資する前に参加者にどのデザインが響くかを確認したい場合に有効です。スタディ内のタスクをテストするために十分なインタラクションだけを備えた低忠実度のプロトタイプを使うことができます。

目標: 複数の初期プロトタイプを比較して、どれがより良いパフォーマンスを示すかを確認します。参加者が関連するタスク/複数のタスクにナビゲートできるか、全体的なユーザビリティを評価し、初期印象や口頭での定性的なフィードバックなどの追加のインサイトを得られるかを確認します。

メリット:

• 参加者は複数のデザインに触れるため、より有益で具体的なフィードバックを提供できます。同じ目標を達成するために複数のデザインを参加者に体験してもらうことで、それらの違いについて考えてもらえます。
• 参加者が考えていることを口にする中で、デザインに関するコメントや意見など定性的なインサイトを得られます。
• タスク達成率と UMUX Lite のスコアという定量的なデータを使ってデザインを比較できますが、サンプルサイズが小さいためデータの解釈には制限があります。これらは方向性を示すものとしてのみ解釈すべきです。

この手法が答えられるリサーチ質問の種類

• どのナビゲーションデザインがより優れたパフォーマンスを示すか? なぜか?
• どのナビゲーションデザインで参加者が最も簡単にタスクを完了/達成できるか?
• 提案されたナビゲーションレイアウトのうち最も納得感があるのはどれか? なぜそう思うか/思わないか?
• 参加者はアプリケーション内で自分がどこにいるか分かっているか? なぜそうか/そうでないか?
• ナビゲーションの UI 要素が参加者に目立って見えるか? なぜそうか/そうでないか?

手法の詳細

ファシリテーションの種類: このタイプのテストは、スタディの具体的な詳細や目標（例: どの程度の定性的なインサイトを得たいか、参加者がプロトタイプを自分で進められるかなど）に応じてモデレートでもアンモデレートでも実施できますが、デザインを比較するための十分な定性的フィードバックを引き出すために、おそらくモデレート形式になるでしょう。

必要な忠実度: 基本的なインタラクションをテストでき、デザイン間の違いを比較できるだけの忠実度を持ったプロトタイプ。たとえば、参加者があるエリアにナビゲートできるかを評価したい場合、参加者がそのタスクを完了でき、できれば「間違った」エリアやパスをいくつかクリックできるようなインタラクティブなプロトタイプが必要です。

推奨サンプルサイズ: 5 名。目標が定性的なインサイトの取得であるためです。5 人目以降に新たな重要なユーザビリティ問題が見つかった場合は、1〜2 名の参加者を追加してください。

デザインの数: 参加者が各デザインを十分にこなせる時間を確保し、参加者の疲労を軽減するために 3 デザインまでに制限 することを推奨します。

何を捉えるか:

• タスク達成率: 各タスクを成功裏に完了した参加者数は?
  • これはデザイン間でどう異なるか?
• UMUX Lite: UMUX Lite のスコアとその評価の理由
  • これはデザイン間でどう異なるか?
• 各デザインの 重要度付きユーザビリティ問題
  • 参加者がナビゲーションで何かを見つけるのに苦労したか?
  • ナビゲーション項目のラベルが参加者を混乱させたか?
  • ナビゲーション項目が予期せぬ動作をしたか（トップメニューでの検索など）?
• 参加者がタスクを完了するためにどのようにナビゲートしたか
  • 共通のパス（正解・不正解を問わず）
  • そのパスを選んだ理由に関する定性的フィードバック

推奨テストプラットフォーム: アンモデレート向けは UserTesting、モデレート向けは Zoom

比較的ユーザビリティテストの実施方法

• 最大 2〜3 のデザインをテストします。3 つを超えるデザインをテストすると参加者を圧倒する可能性があり、セッション内ですべてをディスカッションを含めてカバーする時間が足りなくなる場合があります。
• 参加者が互いに区別できるように、明らかな違いがあるデザインをテストします。
• すべての参加者がすべてのデザインを見て、各デザインに対して同じタスクを与えられる必要があります。ただし、順序効果（学習行動により後のデザインのタスクが簡単になること）を避けるために、デザインの順序をランダム化してください。
• 最も重要なタスクを選んでテストし、タスクの数を最小限に抑えます。1 セッションで複数のデザインをテストするため、すべてをこなす時間を確保することが必要です。
  • たとえば、5 つのタスクがあり 3 つの異なるデザインがある場合、実際には参加者あたり 15 のタスクになります。
  • まずパイロットセッションを実施して、セッションの長さと参加者の疲労度をテストしてください。
• 各タスク後、各デザイン後、テストセッションの最後に参加者からフィードバックを収集します:
  • タスク後の質問:
    • 今行ったアクティビティについて何かフィードバックはありますか?
    • 特に簡単だった、または難しかったことはありますか（まだ言及していなければ）?
    • 参加者がセッション中に行っていた具体的なことを掘り下げて聞きます（モデレート形式の場合）。
  • 各デザインの最後に: （追加の質問をする前に、まず UMUX Lite アンケートを実施してください）
    • そのデザインにその評価を付けた理由を尋ねます
    • 今見たデザインについて何かフィードバックはありますか?
    • このデザインで気に入った点、気に入らなかった点は何ですか?
    • テスト中に観察したことを掘り下げて聞きます（モデレート形式の場合）。
    • スタディで学びたいことに応じて、より的を絞った質問を追加できます。
  • 各テストセッションの最後に、すべてのデザインを比較して:
    • 参加者が見たすべてのデザインを最初に見返して記憶を新たにできるようにします（アンモデレート形式の場合は、最後にすべてのデザインを確認できるタスクを追加します）。
    • 今日見た異なるデザインを考えて、明日目覚めたときにこれらのデザインのいずれかが GitLab UI に統合されているとしたら、どれを見たいですか? その理由は?
      • 気に入ったのは何ですか? なぜですか?
      • 気に入らなかったのは何ですか? なぜですか?

結果のレポート方法

Slack や Issue に簡単な/初期の所見を報告するには、次の形式を使ってください:

• 各デザインで見つかったユーザビリティ問題の数
  • 例: 「Design A には 5 つのユーザビリティ問題、Design B には 2 つ、Design C には 6 つのユーザビリティ問題がありました。」
• 各デザインで見つかった上位 1〜2 のユーザビリティ問題（重要度が最も高いもの）と各問題の簡単な説明
  • 問題の重要度を判断するために ユーザビリティ重要度分析スプレッドシート（内部リンク） に記入してください
  • 例: 「3 名中 2 名の参加者が、[ボタンまたは要素名] の新しい配置で最近のプロジェクトを見つけるのに苦労した。」
• ユーザビリティ問題につながった行動に関するテーマ
  • 例: 「2 名の参加者が [別の場所] で見つけることを期待した」
• その他の興味深い観察やフィードバックを記載
  • 例: 「3 名の参加者全員が [X] の変更について困惑を表明した。なぜなら…」
• 次の 2 名の参加者を実施する前に対応する予定の問題があれば記載

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