Content last updated 2026-07-16

Navigation を評価する

Navigation の変更を提案する際は、高い確信を持って進めることが重要です。定義済みの一連の方法を使用して、既存の体験と比較しながら変更の成果を評価します。

Navigation の変更を評価する

Navigation は、他のすべての体験を支える構造です。ユーザーは、プロダクトで最も重要なタスクをどこで、どのように行うかを知るために Navigation に頼っています。Navigation に何らかの変更を提案する場合は、高い確信を持って進めることが重要です。

チームがデザインプロセスのどの段階にいるかに応じて、異なる方法とメトリクスを適用する必要があります。ダブルダイヤモンドフレームワークには、物事を正しくデザインすることに焦点を当てた、開発/テストと提供/観察という 2 つの異なるフェーズがあります。このページでは、両方のフェーズで Navigation を評価するとき、および変更が実装された後に経時的に評価するときに使用するメトリクスの概要を示します。

ダブルダイヤモンドのプロセスモデル

開発/テスト

このフェーズでは、幅広い Navigation ソリューションを検討し、ユーザーからのフィードバックを収集して、さらにイテレーションするソリューションを絞り込みます。これを初期段階のソリューション検証または初期コンセプトテストとも呼びます。このフェーズでは、次のような質問に答える必要がある場合があります。

  • ユーザーは Navigation 要素に到達するため最初にどこをクリックすべきかわかりますか?
  • 提案されたレイアウトまたは情報アーキテクチャは理にかなっていますか?
  • どの UI 要素がユーザーの目に留まっていますか?
  • どのデザインがユーザーにとってタスクの達成をより容易にしますか?
  • ユーザーはどのデザインを好みますか?

これらの質問に対応する適切な方法の詳細は、こちらをお読みください

提供/観察

前のフェーズで新しい Navigation ソリューションを特定したら、提案した改善が既存の体験と比べてどうか、また経時的にどのような成果を上げるかを理解することが重要です。次のような質問に答える必要がある場合があります。

  • 新しい Navigation は既存の Navigation と比較してどうですか?
  • 異なるユーザーグループ間に違いはありますか(例: 新規ユーザーと成熟した GitLab ユーザー、異なるペルソナ)?
  • Navigation を長期間使用することは、ユーザーの認識にどのような影響を与えますか?
  • Navigation に対するユーザーの認識と感情は、時間の経過とともにどのように変化しますか?

Navigation に対するユーザーの認識と感情を経時的に監視するために実施する四半期ごとの Navigation アンケートなど、これらの質問に対応する方法を詳述したハンドブックページを追加中です。

Navigation の変更を評価するためのアプローチ

異なるステージグループが Navigation 体験への変更を提案する場合があり、これらの提案が Navigation 全体のユーザビリティに与える影響を理解することが重要です。

一貫した方法で改善を測定するには、どのステージグループでも利用できる中核メトリクスのセットが必要です。以下のメトリクスは、標準的なユーザビリティメトリクスとデザイン固有のメトリクスで構成されています。デザインメトリクスは、SUS のフィードバックから生じ、チームの作業を導くテーマを反映しています。

標準的なユーザビリティメトリクス

  • 有効性(= タスクの成功)
  • 使いやすさ(= 主観的に認識されるタスクの難易度)
  • 効率性(= 主観的に認識される労力)

デザインメトリクス

  • 発見可能性(= 新しい機能を発見すること)
  • シンプルさ(= 圧倒される感覚を最小限に抑えること)
  • 位置把握(= 自分がどこにいるかを知ること)
  • 見つけやすさ(= 中断した場所から再開することを含め、注意が必要なものを見つけること)

中核メトリクスのセットは、調査で選択した方法を考慮して適切な場合に、あらゆる Navigation リサーチ調査における最小メトリクスセットとして含めることを意図しています。たとえば、アンケートでは有効性のメトリクスを含める必要はありません。さらに、調査の目的にとって意味がある場合は、追加のメトリクスを加えることが推奨されます(例: ファーストクリックテストの確信度メトリクスを追加する、またはNavigation Northstar Beta Testingで行ったようにユーザーがプロジェクトへ移動する能力に関するメトリクスを追加する)。チームは、複数のメトリクスを使用して成功を三角測量することに抵抗を感じるべきではありません。

どのメトリクスも提案したソリューションの改善を示さない場合は、収集したデータを使用して、メトリクスによって裏付けられるが左右されない、全体的かつ主観的な決定を行うことをチームに勧めます。

メトリクス定義測定方法
有効性タスクが与えられたときにユーザーが項目を見つける能力の二値測定です。各タスクの成功率または完了率を示します。タスクを完了できた参加者数を参加者の総数で割ることで、通過率を決定できます。
使いやすさユーザーが主観的に認識するタスクの難易度「GitLab Navigation の使いやすさ、または使いにくさはどの程度ですか?」- 非常に難しい - やや難しい - 簡単でも難しくもない - やや簡単 - 非常に簡単
効率性ユーザーが何かを達成するために主観的に認識する労力「日常業務のタスクを完了する際、GitLab Navigation はどの程度効率的、または非効率的ですか?」- 非常に効率的 - 効率的 - 中立 - 非効率的 - 非常に非効率的
発見可能性GitLab Navigation を通じてユーザーが新しい GitLab 機能を発見する能力「Navigation を通じて、自分にとって新しい機能を見つけることはどの程度簡単、または難しいですか? - 非常に難しい - やや難しい - 簡単でも難しくもない - やや簡単 - 非常に簡単
シンプルさユーザーが認識する圧倒される感覚「GitLab Navigation をどのように表現しますか?」- とてもシンプル - シンプル - 中立 - 圧倒される - 非常に圧倒される
位置把握GitLab 内で自分がどこにいるかを知るユーザーの能力「GitLab 内を移動するとき、自分がどこにいるかを知ることはどの程度簡単、または難しいですか?」- 非常に難しい - やや難しい - 簡単でも難しくもない - やや簡単 - 非常に簡単
見つけやすさ中断した場所から再開することを含め、注意が必要なものを見つけるユーザーの能力。「注意が必要なものを見つけることはどの程度簡単、または難しいですか?」- 非常に難しい - やや難しい - 簡単でも難しくもない - やや簡単 - 非常に簡単