Navigation のテスト: 初期段階の Solution Validation
Navigation のための初期段階 Solution Validation リサーチプロセス
このプロセスは、Navigation に焦点を当てた初期段階のソリューション検証リサーチプロジェクトで迅速なイテレーションを可能にすることを目的としています。目的は、初期段階のSolution Validationリサーチのニーズの大半に対応するプロセスを提供し、Product Designer 向けに従いやすいガイダンスを提供し、初期段階のソリューション検証リサーチを迅速に計画できるようにすることです。ダブルダイヤモンドフレームワークでは、これはデザインライフサイクルの開発／テストフェーズにあります。目的は、初期段階の Navigation デザインとコンセプトを評価して、十分に投資する前にそれらのアイデアへの確信を築くことです。このガイドは、後段のソリューション検証におけるユーザビリティ調査またはベンチマーク調査は対象にしません。
以下の表では、初期段階のソリューション検証リサーチで使用できる 3 つの方法を説明します。目的は、ベンチマークやデザインの測定に焦点を当てるのではなく、「なぜ」を理解するための定性的インサイトを収集して、Navigation デザインの方向性を提供することです。
| 目標 | 方法 | 回答できる質問の種類 | 必要なプロトタイプの忠実度 | サンプルサイズ |
|---|---|---|---|---|
| ユーザーがタスクを完了するために最初にどこをクリックするか、およびその理由を学ぶ。 | ファーストクリックテスト | ユーザーは Navigation 要素に到達するため最初にどこをクリックすべきかわかりますか？ 提案されたレイアウトは理にかなっていますか？その理由は何ですか？ 情報アーキテクチャの階層は理にかなっていますか？その理由は何ですか？ ユーザーはアプリケーション内の自分の位置を把握していますか？その理由は何ですか？ UI 要素はユーザーの目に留まっていますか？ | 十分な詳細があれば、スケッチであっても静的画像。 | 30* 詳細はファーストクリックテストのページを参照してください。 |
| ユーザーが 1 〜 2 回のクリックを超えて関連するタスクに移動できるか、基本的なユーザビリティを評価し、デザインがどのように受け止められるかとその理由を学ぶ。（単一デザイン） | RITE（定性的ユーザビリティテスト） | ユーザーはタスクを完了するためにどこへ行くべきかわかりますか？その理由は何ですか？ ユーザーは Navigation デザインでタスクを完了できますか？その理由は何ですか？ 提案された Navigation デザインのレイアウトは理にかなっていますか？その理由は何ですか？ ユーザーはアプリケーション内の自分の位置を把握していますか？その理由は何ですか？ UI 要素はユーザーの目に留まっていますか？その理由は何ですか？ | 基本的な操作をテストするのに十分な忠実度を持つプロトタイプ。たとえば、ユーザーがある領域に移動できるかを評価したい場合は、そのタスクを完了でき、理想的にはいくつかの「誤った」領域をクリックできるインタラクティブなプロトタイプが必要です。 | 5 人から開始（テストラウンドごと）。 |
| 複数の初期プロトタイプを比較し、基本的なユーザビリティとその理由において一方が他方より優れているかを学び、ユーザーが各デザインをどのように受け止めるかを学ぶ。 | 比較定性的ユーザビリティテスト | どの Navigation デザインがより優れた成果を上げますか？その理由は何ですか（例: タスク完了）？ どのデザインがユーザーにとってタスク達成を最も容易にしますか？ ユーザーはどのデザインを好みますか？その理由は何ですか？ | 単一デザインでの RITE テストと同じです。デザイン間の違いを比較できるだけのインタラクションと詳細を、プロトタイプに持たせる必要があります。 | 5 人から開始。 |
Navigation はすべてのユーザーに影響するため、誰をテストすべきですか？
Navigation 調査では、時間の経過に伴って調査を比較できるよう、リクルートを標準化する必要があります。一般的なユーザーベースを代表する幅広いユーザーをリクルートすることを目指します。
- 技術系と非技術系のユーザーを混在させる
- さまざまな企業規模を混在させる
- 少なくとも 3 か月 GitLab を使用している経験豊富なユーザー
ユーザーの一部に関連する特定の領域に、より狭く焦点を当てる必要がある調査もあります。その場合は、その特定のペルソナをリクルートします。
- チームでまだ十分に理解できていないペルソナの場合は、その特定のペルソナに関連するタスクを決定し、職務上の責任やそのペルソナに関連する可能性があるその他の属性（企業規模、GitLab の使用頻度、GitLab の経験（新規ユーザーか経験豊富なユーザーか、経験豊富なユーザーの場合は GitLab の使用期間など））に基づいて適切にリクルートできるよう、特定のペルソナに詳しいステークホルダーと協力することを推奨します。
Navigation をテストするにはどのタスクを使用すべきですか？
Navigation 調査では、時間の経過に伴って調査を比較できるよう、タスクを標準化する必要があります。これは、ほとんどの GitLab ユーザーに幅広く適用できる Navigation タスクの中核グループ（作成中）を開発することで実現できます。この中核タスクリストに含めるタスクに関する考慮事項には、次が含まれます。
- より幅広いユーザーに当てはまる、以前のリサーチで特定された上位タスク
- より幅広いユーザーに当てはまる、以前の Navigation リサーチで使用されたタスク
- 現在の Navigation 体験でよくクリックされる領域
- 既知の問題／ペインポイントに関連し、より幅広いユーザーに当てはまる一般的なタスク
特定のペルソナを対象とする調査では、関連するタスクを特定するため、そのペルソナに詳しいステークホルダーと協力することを推奨します。
- 1 つの提案として、ペルソナごとの識別タスク（内部リンク）を検討できます。ただし、これらはスクリーナーで使用できるように書かれており、テスト用には書かれていません。テストのために、GitLab で実行できることとして構成し、記述する必要があります。
- たとえば、Sasha のタスクは「プロダクトデザインをコードに変換する」です。
- これは、「参加しているすべてのプロジェクトで、レビューを担当として割り当てられたすべてのコード変更の一覧をどこで見つけますか？」のように言い換えられます。
c955a93f)