Experience Research の運用方法

チーム構成

UX リサーチチームは、UX Researchers、Service Designers、UX Research Operations Coordinatorsで構成されています。

• UX Researchers は担当するステージグループ内で働き、そこで自身で UX リサーチを実施し、チームが実施するリサーチ活動に助言します。
• Service Designers はステージとグループを横断して働き、GitLab 全体のエンドツーエンドのユーザージャーニーを改善するために、ユーザーリサーチとデザインを行います。
• UX Research Operations Coordinators は、参加者リクルーティングプロセスと、リサーチオペレーションに関するすべてを担います。

私たちの作業モデル

私たちはハイブリッドマトリックス構造を採用しており、Heads of UX Research はそれぞれ複数のプロダクトドメインを監督し、そのプロダクトドメイン内で各種ステージのリサーチを担う 5-7 人の UX Researchers と Service Designers を支援します。

Heads of Research は、プロダクトドメインのリサーチビジョンと戦略を監督し、チームにメンタリングを提供して障害を取り除きながら、職能横断的な取り組みを調整します。UX Researchers と Service Designers は、各自のプロダクト領域で、戦略的思考と戦術的な実行の両方を主導します。

このバランスの取れたアプローチは、明確な説明責任とともに深いドメイン専門知識を可能にし、つながりのあるプロダクトドメイン全体で、専門知識と協働的な調整を通じたイノベーションを促進します。

チームメイトペアリング

UX Researcher か Service Designer かを問わず、チームメンバーはチームメイトペアリングに参加できます。ここでは別のチームメンバーとペアを組み、互いにフィードバックを提供し、受け取ることができます。これは任意の取り組みであり、チームメンバーは自分たちで調整できます。

チームメイトペアリングでは、リサーチとサービスデザインのアプローチに関するアイデアを共有し、課題に取り組み、テスト計画、レポート、デザインをレビューし、フィードバックの提供経験を得るための、一貫したパートナーがチームメンバーに与えられます。また、自分の担当外のプロダクト領域に触れる機会も得られます。

チームメンバーの割り当て方法

UX Researchers の働き方

協働する相手

私たちは Product Designers、Product Managers、Engineers と協働し、リサーチを実施する領域を共同で決定します。UX リサーチチームは、Product Management と Product Design とパートナーシップを組み、Product Development Flow内で働きます。

UX Researchers は Product Managers と協働し、リサーチスタディの範囲を決定します。可能な限り、UX Researchers は担当グループの計画会議に出席するよう努める必要があります。 UX Researchers は、リサーチの実施を支援できる方法を積極的に提案する必要があります。また、リサーチスタディに関する自身のアイデアを Product Managers に提案し、話し合う必要があります。

取り組む内容

GitLab のほかの部門と同様に、私たちはProduct Development Timelineに従い、マイルストーンを使用して作業のスケジュールを設定します。マイルストーンは毎月変更されます（今後のマイルストーンの日程を確認する）。

私たちは、ステージグループ内で行われるリサーチプロジェクト全体に時間を効果的に配分するのに役立つ優先順位付けプロセスに従います。

時間の使い方

UX Researchers には、時間の使い方について次のガイダンスがあります:

• <10% Solution Validation - これは、リサーチャーの時間の 10% 未満を、Product Designers と Product Design Managers による Solution Validation リサーチの支援に割り当てることを意味します。GitLab では、Solution Validation リサーチは Product Designers が主導し、Product Design Managers が支援します。場合によっては、Product Design Managers が、助言やフィードバックを得るために、Solution Validation リサーチに関する問い合わせを UX Researchers へエスカレーションする必要があるかもしれません。

  • 容量に余裕があれば、UX Researchers は Solution Validation リサーチの実施を支援できます。

Product Managers と Product Designers は、Solution Validation リサーチを計画・実行する際に、Validation phase 5の手順に従います。

• ~60% Problem Validation - リサーチャーは、時間の半分以上を Product Managers とともに Problem Validation リサーチに取り組むことに費やします。長期的な目標は、トレーニングとメンタリングに時間を投資することです。

• ~30% 基盤リサーチ - 理想的には、リサーチャー 1 人あたり、四半期ごとに大規模なプロジェクトを 1 件行います。これらは、問題についてほとんど、またはまったく情報が得られていない場合に、混合研究法のリサーチデザインをよく使用して行う、問題検証の一種です。例:

基盤リサーチを実施する 4 つの注目すべき利点:

1. リサーチャーはそのトピックに関する専門知識を得ます
2. リサーチャーは Product に影響を与え、戦略に影響を及ぼす機会を得ます
3. キャリア成長の機会
4. ビジネスは特定の領域についてより多くの知識／データを得て恩恵を受けます

作業の品質を維持する方法

UX Researchers は、Product および／または Design と密接に協働しながら、頻繁に自らリサーチプロジェクトを主導します。 これが起こる場合、UX Researchers は次のリサーチ成果物についてピアレビューのプロセスに参加します:

• 参加者スクリーナー
• テスト計画
  • テスト計画に含まれる資料には、次が含まれる場合があります:
    • スクリプト
    • アンケート
    • カードソートアクティビティ
    • など
• リサーチの最終レポート／アウトプット

ピアレビューのプロセスには多くの利点があります:

• 可視性 - UX Researchers は、直接の担当領域の外部で行われているリサーチについて、より多くの情報を得ます。
• 学習 - UX Researchers は、採用されているアプローチとそのアプローチの背景にある根拠をレビューすることで、互いから学ぶことができます。
• 品質 - リサーチの成果物は、ピアレビューの結果、より標準化され、高品質になります。
• オンボーディング - 新たに採用された UX Researchers は、標準化された例を確認し、再現すべき品質基準を学ぶことで恩恵を受けます。
• 多様性 - 私たちは、コンテンツをどのように解釈するかについての多様な見解と認識を重視します。
• メンタリング - UX Researchers は、それぞれの専門分野で互いにメンタリングする機会をより多く得ます。
• 一貫性 - 特に参加者スクリーナーでは、チーム全体で同じ質問を行う方法について、より標準化されたアプローチが採用されます。

UX Research のピアレビュープロセスは、非同期で、すべての UX Researchers を包摂するよう設計されています。プロセスは次のとおりです:

1. 共有 - UX Researcher は、ピアレビューが必要なテスト計画および／または最終レポートを用意します。共有と編集が可能であることを確認します。
2. 投稿 - #ux_research_team_lounge Slack チャンネル内で、テスト計画または最終レポートへのリンクをレビュー依頼とともに投稿します。フィードバックが必要な日時を記載します。
   • 例: “こんにちは。こちらのテスト計画（リンク）のレビューをお願いできますか？フィードバックは木曜日までに必要です。ありがとうございます！”
   • ベストプラクティス: レビュアーは、レビューのために少なくとも 24 時間を確保するよう努める必要があります。
3. レビュー - レビュアーは、文書、Issue などに直接フィードバックを提供します。
4. 通知 - レビューが完了すると、レビュアーはスレッドに返信し、UX Researcher にメンションします。
   • 例: "@ name - テスト計画をレビューしました。質問があればお知らせください！"
5. 編集 - UX Researcher はフィードバックを確認し、質問をフォローアップして、必要な調整を行います。
6. 完了としてマーク - 完了したら、元の投稿に緑色のチェックマーク絵文字のリアクションを付け、ピアレビューの依頼が完了してクローズされたことを示します。

UX Researchers は、作成した参加者スクリーナー、テスト計画、最終レポートについて、全員がピアレビューに参加する必要があります。また、UX Researchers には、ピアレビューのプロセスを通じて提出されたものをレビューしてピアを支援することが強く推奨されます。

ピアからの提案を非同期でレビューする際は、提案をクローズするときに注記や説明を提供することがベストプラクティスです。これは、提案に関する決定の根拠を説明し、提案を完結させるために行います。

最終的に、どの提案を適用するかは文書のオーナーが決定します。

作業を周知する方法

今後の作業の周知

私たちが主導するリサーチプロジェクトの認知度を高め、透明性を提供するためには、周知に少し追加の努力を払う必要があります。このお知らせはフィードバックを求めるためのものではなく、今後のリサーチをチームメンバーに知らせることが目的であることに注意してください。最も効果的な方法は次のとおりです:

• 実施する内容を説明する簡潔な文を作成します。（例: ‘今後の UX リサーチ - 皆さん、こんにちは！経験豊富な GitLab ユーザーを対象に、Monitor、Infrastructure、Deployments、Packages & Registries の項目に焦点を当てた、新しいナビゲーション関連の意思決定に情報を提供するためのデータ収集を開始しようとしています。’）。手法は記載されていませんが、ここでは意図的です。方法ではなく、達成することに焦点を当ててお知らせを作成してください。
• 調査が回答する主なリサーチ質問を 3-4 個の箇条書きで挙げます。詳細は含めず、非常に短い文だけにしてください。
• 詳細については Issue にリンクします。
• 結果を共有する予定時期についての注記を加えます。大まかな見積もりで構いません。たとえば、’結果は今から 3-4 週間後に共有されます’。
• 任意: この投稿をリサーチセッションの出席者を招待する方法として使用したい場合は、もちろんそうできます。例: ‘ライブでセッションへの参加に興味がある場合は、このスレッドに返信してください。それ以外の場合は、この Dovetail プロジェクトの[リンクを挿入]に録画を投稿します。そこで都合のよい時間に視聴できます。’
• 投稿は、少なくとも次の 3 つのチャンネル（#upstream-studios、#experience_research、#product）に Slack 経由で共有します。該当するステージグループのチャンネルにも投稿を共有することが推奨されます。

リサーチ結果の周知

自分たちでリサーチプロジェクトを主導する場合、これらのインサイトを周知する責任も負います。最も効果的な方法は次のとおりです:

• 実施した内容について簡潔な導入文を作成します。（例: 皆さん、こんにちは！経験豊富な GitLab ユーザーを対象に、Monitor、Infrastructure、Deployments、Packages & Registries の項目に焦点を当てた左側サイドバーのナビゲーションについて、最近ツリーテスト 🌳 を完了しました。主要なインサイトを共有できてうれしいです ⭐ :）
• 主要なインサイトを 3-4 個の箇条書きで挙げます。詳細は含めず、ハイレベルな調査結果についての非常に短い文だけにしてください。
• リサーチレポート、動画による報告、データシート、リサーチ Issue、Dovetail プロジェクトへのリンク
• リサーチの結果として何が行われるかに関する箇条書きを含む「次のステップ」セクション。これらは、実行可能なインサイトである Issue へのリンクにしてください。
• 投稿は、少なくとも次の 4 つのチャンネル（#upstream-studios、#experience_research #experience_research_reports、#product）に Slack 経由で共有します。該当するステージグループのチャンネルにも投稿を共有することが推奨されます。

カバレッジを維持する方法

UX Research チームはステージグループと参加者に非常に密接に関わるため、私たちが PTO 中でもリサーチプロジェクトを進め続けるには、事前に計画を立てることが重要です。このアプローチにより、チームとして互いを支援できます。次の手順は、PTO に関して UX Research チームが従うプロセスを示しています:

1. PTO の日付を Workday と UXR チームの空き状況カレンダー（内部リンク）に入力します。Deel による休暇では、#ux_research_lounge Slack チャンネルまたはマネージャーに自動返信を設定するよう求められます。
2. 他のチームメンバーとの PTO 日程の重複を記録します。ビジネスへの影響がない限り、問題ありません。
3. 時機を逃せないビジネスへの影響を伴う進行中のプロジェクトに対応するため、カバレッジ Issueを作成します。
4. バックアップ担当者が、1) PTO 中でないこと、2) 自身のバックアップ担当者になることに同意していることを確認します。
5. 次回の 1:1 でマネージャーに PTO の日付を伝え、上記の手順が完了していることを示します。

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