重要な体験の追跡

何

これは、GitLab プロダクト領域における重要な体験を特定し、アナリティクスと可視化を通じてそうした体験を監視・追跡するために必要なプロセスとツールを確立する方法に関する包括的なステップバイステップガイドです。 このガイドは、業界をリードする Google の Critical User Journeys フレームワーク、確立された GitLab UX 品質メトリクスの実践、GitLab 固有の実装要件に基づいて構築されています。

なぜ

重要な体験を通じて実際の UX 品質を追跡することで、GitLab で以下のようにデータドリブンな意思決定が可能になります。

• ビジネスメトリクスとリリース前の UX リサーチ検証の間のギャップを埋める
• 重要なワークフローのユーザー認識と実際のパフォーマンスの両方を測定する
• ビジネス成果にとって最も重要なユーザージャーニーと機能にチームの取り組みを集中させる
• プロダクト改善とリソース配分を導く客観的なデータを提供する

フレームワークの理解: 定義と関係

概念の階層

ユーザー体験（プロダクト体験全体）
└── 重要な体験（成否を分ける瞬間）
    ├── 重要なユーザージャーニー（直線的、順序立てられたワークフロー）
    └── 重要な機能（主要な能力、非線形の探索）

ユーザー体験 vs. 重要な体験

• ユーザー体験は、ユーザーが私たちのプロダクトとやり取りする際に持つ完全な体験を包含します - GitLab との関係全体にわたるあらゆるタッチポイント、インタラクション、結果のすべてです。
• 重要な体験は、ユーザーの成功とビジネスの成果の両方にとって「成否を分ける」ユーザー体験のサブセットです。これらは、成功または失敗がユーザーが目標を達成できるかどうか、そしてビジネス目標が達成されるかどうかに劇的な影響を与える瞬間です。

重要な体験の 2 つのタイプ

重要な体験は、ユーザーが価値をどのように得るかに応じて、根本的に異なる 2 つの方法で測定できます。

• 重要なユーザージャーニー（CUJs）はユーザージャーニーのサブセットです。これらは、ユーザーが特定の目標を達成するために定義されたパスをたどる、明確な開始点と終了点を持つ直線的、順序立てられたワークフローです。通常、3 つのカテゴリに分類されます: 高トラフィック（コアワークフローの最適化）、高ドル（収益フローの改善）、または OEC/総合評価基準（主要な成功メトリクスとの整合）。他のユーザージャーニーと比較して、CUJ は通常以下の特徴のいくつかを示します:
  • 失敗した場合のビジネス影響が大きい
  • 大規模なユーザートラフィックまたは戦略的な重要性
  • 主要なプロダクト価値提案に直接結びついている
  • 横断的な性質（多くの場合、複数のチーム/機能にまたがる）
• 重要な機能は、定められたシーケンスに従うのではなく、非線形のインタラクションパターンを通じてユーザーが価値を得られる主要なプロダクト機能です。検索とフィルタバーのような埋め込まれた UI 要素に結び付けることも、セキュリティ態勢ダッシュボードのように、特定の脆弱性の調査からレポートのエクスポートまで、ユーザーが複数のパスを探索できる複雑なものもあります。

UX 品質メトリクス vs サービスレベルインジケーター vs ビジネス成果

重要な区別: 私たちは UX 品質メトリクスに焦点を当てて重要な体験を追跡しますが、これは GitLab の確立されたユーザー体験 SLI フレームワークやビジネス成果とは異なります。UX 品質メトリクスは、プロダクトが価値を提供しているかどうかのユーザー側のインジケーターであり、一方で SLI は、私たちの技術システムがその提供をサポートできるかどうかを測定します。

ステップバイステップ実装ガイド

これは UX と横断的なチームを巻き込んだ協働的なプロセスです。各ステップで推奨される所有権を以下に概説します。

ステップ 1 - 重要な体験を特定する

オーナー: UX、サポート: プロダクト

潜在的な重要な体験を評価するためにこれら 3 つの次元を使う

提案されるプロセス

可能性のある重要な体験の候補をブレインストーミングし、2 つのカテゴリのいずれかに割り当てます。

• ユーザージャーニー: ユーザーが目標を達成するために比較的予測可能な一連のステップに従う体験であり、いずれかのステップでの失敗が目標達成を妨げる体験
  • 主要なプロダクト機能: 機能採用を通じてユーザーが価値を得る体験であり、成功は機能に効果的にアクセスして活用することです。
  • 各体験を採点する: ビジネス重要度、ユーザー影響、測定可能性で 1-5 点を評価
• 優先度スコアを計算する: 3 つのスコアを掛け合わせる（最大スコア = 125）
• 上位 3-5 個を選択する: 最高スコアの体験から始める（たとえば 60+ をスコアリング）
• ステークホルダーで検証する: プロダクト戦略との整合を確認

プロのヒント: 重要な体験を最大 3-5 個に制限してください。多数の体験に取り組みを薄めるよりも、少数の重要な体験を深く理解する方が良いです。

ステップ 2 - 計装のためのインジケーターを定義する

オーナー: プロダクト、サポート: UX

重要なユーザージャーニーに対して

• 完全なフローをマッピングする: GitLab のユーザージャーニーマッピングベストプラクティスに従って、ユーザーが最初から最後まで実行するすべてのタスクをドキュメント化
• 各ステップの境界を再確認する: 各ステップが CUJ 内の明確なタスクまたはインタラクションを表すことを確認します。タスクまたはインタラクションが失敗すると、CUJ が失敗します。
  • 例の分解: 重要なジャーニー: 「新規ユーザーが最初のマージリクエストを作成する」
  • タスク:
    • リポジトリのセットアップ完了（または既存のリポジトリへのアクセス）
    • フィーチャーブランチの作成と切り替え
    • Web IDE を使ったコード変更
    • 意味のあるメッセージで変更をコミット
    • マージリクエスト作成画面に移動
    • マージリクエストの詳細を入力
    • マージリクエストを正常に送信
• ジャーニーの進捗または機能採用のインジケーターを特定する: 各タスクについて、以下を定義します。
  • 開始イベント: タスクはいつ開始されるか？
  • 成功イベント: タスク完了を示すものは何か？
  • 失敗イベント: 異なる失敗モードは何か？
  • コンテキストデータ: 分析に役立つ追加情報は何か？
• 自己報告データの必要性をチェックする: 自己報告データが必要かどうか議論します。必要な場合、アプリ内で取得する必要があるかを議論します。たとえば、Duo の結果品質を取得するには、アップ/ダウン投票でアプリ内でユーザーのフィードバックを取得する必要があります。

重要な機能に対して

• 測定すべきサブ機能を特定する:
  • 例の分解: 重要な機能: 「セキュリティ態勢ダッシュボード」
  • サブ機能:
    • インタラクティブチャート
    • ネストされた脆弱性リスト
    • レポートのエクスポート
• 成功インジケーターを特定する: 各機能とサブ機能について、以下を定義します。
  • 機能発見インジケーター: ユーザーはこの機能をどのように見つけてアクセスするか？
  • 採用/使用の深さインジケーター: 広範な機能探索を示すアクション。
  • 失敗イベント: 異なる失敗モードは何か？
  • コンテキストデータ: 分析に役立つ追加情報は何か？
• 自己報告データの必要性をチェックする: 自己報告データが必要かどうか議論します。必要な場合、アプリ内で取得する必要があるかどうか議論します。

ステップ 3 - 計装とデータ可視化のセットアップ

オーナー: プロダクト、サポート: UX、エンジニアリング、プロダクトデータインサイト

フェーズ 1 - 既存の追跡の監査

オーナー: プロダクト

• 現在の計装をチェックする:
  • 既存のイベントについて GitLab メトリクス辞書をレビュー
  • 重要なタスクの Snowplow 追跡カバレッジを検証（デモ）
  • データ品質と完全性を評価
  • 現在の追跡のギャップを特定
• 既存のダッシュボードのインベントリ:
  • プロダクト領域の関連メトリクスについて現在の Tableau ダッシュボードをレビュー（Atlan経由）
  • すでに利用可能なものと必要なものをドキュメント化

フェーズ 2 - 欠けている追跡を実装する

オーナー: エンジニアリング

• ギャップを埋める:
  • 欠けているイベントの計装要件を作成
  • GitLab の計装ガイドラインに従う
  • 各重要なタスクのイベント追跡を実装
• プロダクトデータインサイトチームと連携する:
  • 重要なジャーニーフレームワークとタスクの分解を共有
  • イベントと変数のセットアップについて該当領域のプロダクトアナリストと連携
  • 実装タイムラインとテストアプローチを計画
  • レビュープロセスをセットアップ

フェーズ 3 - 必要に応じて自己報告メトリクス収集をセットアップする

オーナー: UX

• プロダクト内フィードバック:
  • プロダクト内フィードバックをいつどのように取得するかを決定。
  • 自己報告データ用の軽量フィードバック UI を設計
  • 該当する場合、ユーザーへの過剰なアンケートを避けるために UX リサーチオペレーションチームと連携。
• スタンドアロンリサーチスタディ:
  • UX リサーチチームと連携してスケジュール済みアンケートを設計
  • リサーチの頻度（月次/四半期）に合意
  • フィードバック収集のターゲットユーザーセグメントを定義
  • 該当する場合、ユーザーへの過剰なアンケートを避けるために UX リサーチオペレーションチームと連携。
  • ユーザー体験のトレンドの縦断的な追跡をセットアップ

フェーズ 4 - UX 品質ダッシュボードを構築する

オーナー: プロダクトデータインサイト

• ダッシュボードの設計、構築、イテレーション:
  • UX 品質メトリクスに合わせたダッシュボードモックアップを設計
  • ダッシュボードでの協働のためにIssue 受付プロセスに従う
  • 必要に応じてより深い分析のためのドリルダウン機能を作成
  • 関連するステークホルダーのアクセス権限を確立
  • 実際のデータでダッシュボードの機能をテスト
• 推奨されるダッシュボード要件:
  • 重要なユーザージャーニーに対して:
    • ジャーニー概要: 各 CUJ の高レベル成功率
    • ステップ分解: ジャーニー内の各重要なステップの詳細メトリクス
    • ファネル分析: ステップ間の離脱ポイントとコンバージョン率
  • 重要な機能に対して:
    • 機能採用: 各機能を積極的に使用している適格ユーザーの割合
    • 機能活用: ユーザーが機能能力をどの程度広範に探索するか
    • エンゲージメントパターン: 使用頻度、セッションの深さ、インタラクションシーケンス
  • すべての重要な体験に対して:
    • トレンド分析: 比較期間との時間経過に伴うパフォーマンス
    • セグメンテーション: ユーザータイプ、経験レベル、機能フラグ等によるパフォーマンス
    • アラート閾値: メトリクスの劣化とエスカレーショントリガーの視覚的インジケーター
    • ドリルダウン機能: 問題が発生したときの根本原因分析のための詳細ビュー
• 推奨されるダッシュボードデザイン原則:
  • 最も重要なメトリクスを目立たせ、見つけやすくする
  • 一貫した色分けと可視化パターンを使用
  • ターゲットベンチマークと許容範囲を含める
  • メトリクスの解釈のためのコンテキストを提供
  • 可能であればレポート用のエクスポート機能を有効化

ステップ 4 - 品質ターゲットと監視頻度を合意する

オーナー: プロダクト、サポート: UX、エンジニアリング、プロダクトデータインサイト

• 現実的なターゲットとエスカレーションプロセスを合意する:
  • 同じ UX 品質メトリクスでも、ターゲットはコンテキストに敏感であることを認識する。
  • UX 品質メトリクスページ（後述）を参照してターゲットを決定
  • 異なる重大度レベルのエスカレーション手順を作成
  • 明確な所有権と対応プロトコルを定義
  • 信頼性を確保するためにアラートシステムをテスト
• 推奨されるレビュープロセス:
  • 週次: トレンドと異常についてダッシュボードをレビュー
  • 月次: ジャーニーパフォーマンスの深掘り分析
  • 四半期: ジャーニーの優先順位付けとターゲットの戦略的レビュー

このガイドへのフィードバック

このガイドは GitLab であなたのチームに役立っていますか？フィードバック Issue にコメントを残してください。ぜひお聞かせください！

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