GitLab における UX リサーチチームの運営方法

チーム構造

UX リサーチチームは、UX リサーチャー、サービスデザイナー、そしてUX リサーチ オペレーションコーディネーターで構成されています。

• UX リサーチャーは割り当てられたステージグループ内で活動し、UX リサーチを自身で実施したり、チームが行っているリサーチ活動についてコンサルティングを行います。
• サービスデザイナーはステージとグループをまたいで活動し、GitLab 全体のエンドツーエンドユーザージャーニーを改善するためのユーザーリサーチとデザインを実施します。
• UX リサーチ オペレーションコーディネーターは、参加者募集プロセスやリサーチオペレーションに関連するすべてを担当します。

私たちのワーキングモデル

私たちは、ヘッドオブ UX リサーチがそれぞれ複数のプロダクトドメインを統括し、各プロダクトドメイン内のさまざまなステージのリサーチを担当する 5〜7 名の UX リサーチャーとサービスデザイナーをサポートする、ハイブリッドマトリクス構造を採用しています。

ヘッドオブリサーチは、プロダクトドメインのリサーチビジョンと戦略を統括し、クロスファンクショナルな取り組みを調整しながら、チームのためにメンターシップを提供し障害を取り除きます。UX リサーチャーとサービスデザイナーは、自分たちのプロダクト領域内で、戦略的思考と戦術的実行の両方を推進します。

このバランスの取れたアプローチは、深いドメイン専門性と明確な説明責任を両立させ、専門知識を通じたイノベーションと、私たちのつながりのあるプロダクトドメインにわたる協調的なコーディネーションを促進します。

チームメイトペアリング

UX リサーチャーであれサービスデザイナーであれ、チームメンバーはチームメイトペアリングに参加でき、別のチームメイトとペアを組んで互いにフィードバックを提供したり受け取ったりすることができます。これはオプトインの提供であり、チームメンバーは自己組織化できます。

チームメイトペアリングは、リサーチとサービスデザインのアプローチ、課題への対処、テスト計画・レポート・デザインのレビューについてアイデアを共有する一貫したパートナーをチームメンバーに与え、フィードバックを提供する経験を得る機会を提供します。また、チームメンバーに自分の領域以外のプロダクト領域に触れる機会も与えます。

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

UX リサーチャーの働き方

誰と協働するか

私たちはプロダクトデザイナー、プロダクトマネージャー、エンジニアと協働し、どの領域でリサーチを実施するかを共同で決定します。UX リサーチチームは、プロダクトマネジメントおよびプロダクトデザインとパートナーを組みながら、プロダクト開発フロー内で活動します。

UX リサーチャーはプロダクトマネージャーと協働してリサーチスタディの範囲を決定します。可能な限り、UX リサーチャーは指定されたグループのプランニングミーティングに出席するよう努めるべきです。 UX リサーチャーは、リサーチの提供を支援できる方法を積極的に提案するべきです。また、自分自身のリサーチスタディのアイデアをプロダクトマネージャーに提案して議論するべきでもあります。

何に取り組むか

GitLab の他の部門と同様に、私たちはプロダクト開発タイムラインに従い、マイルストーンを使って作業をスケジュールします。マイルストーンは毎月変わります（今後のマイルストーンの日付を確認する）。

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

時間の使い方

UX リサーチャーには時間の使い方について次のガイダンスがあります:

• Solution Validation 10% 未満 - これはリサーチャーの時間の 10% 未満を、プロダクトデザイナーとプロダクトデザインマネージャーの Solution Validation リサーチの支援に割り当てることを意味します。GitLab における Solution Validation リサーチは、プロダクトデザインマネージャーのサポートのもとプロダクトデザイナーが主導します。場合によっては、プロダクトデザインマネージャーが Solution Validation リサーチに関する問い合わせを UX リサーチャーにエスカレートしてアドバイスやフィードバックを得る必要があるかもしれません。

  • キャパシティに余裕があれば、UX リサーチャーは Solution Validation リサーチの実施を手伝うことができます。

プロダクトマネージャーとプロダクトデザイナーは、Solution Validation リサーチを計画・実行する際にValidation phase 5のステップに従います。

• Problem Validation 約 60% - リサーチャーは時間の半分以上をプロダクトマネージャーとともに Problem Validation リサーチに費やし、長期的には時間をトレーニングとメンタリングに投資することを目標としています。

• 基礎リサーチ 約 30% - 理想的には、四半期ごとにリサーチャー 1 人につき 1 つの大きなプロジェクトです。これらは、問題について情報がほとんどまたはまったく知られていない、混合手法のリサーチデザインを使用することの多い、Problem Validation の一種です。例:

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

1. リサーチャーがそのトピックの主題知識を得る
2. リサーチャーがプロダクトに影響を与え戦略に影響を与える機会を持つ
3. キャリア成長の機会
4. ビジネスが特定の領域でより多くの知識／データを得られることで利益を得る

仕事の品質をどう維持するか

UX リサーチャーは、プロダクトおよび／またはデザインと密接に協力して、リサーチプロジェクトを自身で推進することが頻繁にあります。これが発生する場合、UX リサーチャーは次のリサーチアーティファクトについてピアレビュープロセスに参加します:

• 参加者スクリーナー
• テスト計画
  • テスト計画に含まれる素材は次のようなものを含む可能性があります:
    • スクリプト
    • サーベイ
    • カードソートアクティビティ
    • など
• リサーチの最終レポート／成果物

ピアレビュープロセスには多くのメリットがあります:

• 可視性 - UX リサーチャーは自分の直接の担当領域以外で実施されているリサーチについてより情報を得ることができます。
• 学び - UX リサーチャーは取られているアプローチとその背後にある正当化をレビューすることで互いから学ぶことができます。
• 品質 - ピアレビューの結果、リサーチの成果物がより標準化され、より高品質になります。
• オンボーディング - 新しい UX リサーチの採用者は、標準化された例を見て、再現すべき品質基準について学ぶことで利益を得ます。
• 多様性 - 私たちは、コンテンツの解釈について多様な見方や認識を重視します。
• メンタリング - UX リサーチャーは自分の技能において互いをメンタリングする機会をより多く持ちます。
• 一貫性 - 特に参加者スクリーナーは、私たちがチーム全体で同じ質問を尋ねる方法について、より標準化されたアプローチを持ちます。

UX リサーチのピアレビュープロセスは、非同期かつすべての UX リサーチャーを包含するように設計されています。プロセスは次のとおりです:

1. 共有 - UX リサーチャーがピアレビューが必要なテスト計画および／または最終レポートを持っています。共有可能で編集可能であることを確認します。
2. 投稿 - #ux_research_team_lounge Slack チャンネル内で、テスト計画または最終レポートへのリンクとレビューの依頼を投稿します。フィードバックが必要な日時を含めます。
   • 例: “Hi - can I please request a review of this test plan (link)? Feedback is needed by Thursday. Thank you!”
   • ベストプラクティス: レビュアーは少なくとも 24 時間以上のレビュー時間を提供することを目指すべきです。
3. レビュー - レビュアーがドキュメント、Issue などに直接フィードバックを提供します。
4. 通知 - レビューが完了したら、レビュアーがスレッドに返信し、UX リサーチャーにメンションします。
   • 例: "@ name - your testplan has been reviewed. Let me know if you have any questions!"
5. 編集 - UX リサーチャーがフィードバックを見て、質問にフォローアップし、必要な調整を行います。
6. 完了とする - 完了したら、元の投稿に緑色のチェックマークの絵文字リアクションを付け、ピアレビューリクエストが完了し終了したことを示します。

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

非同期でピアからの提案をレビューする際、提案を閉じる際にメモや説明を提供することがベストプラクティスです。これは、提案に関して下された決定の背後にある根拠を説明し、提案にクロージャーを追加するために行われます。

最終的に、どの提案を適用するかを決めるのはドキュメントのオーナーです。

仕事のソーシャライズの仕方

今後の仕事のソーシャライズ

私たちが推進するリサーチプロジェクトについて認識を高め、透明性を提供するために、情報を発信するために追加の労力を投じる必要があります。このアナウンスはフィードバックを求めるものではないことに注意してください。その目的は、今後のリサーチについてチームメンバーに知らせることです。最も効果的な方法は次のとおりです:

• 何が行われるかを説明する簡潔なステートメントを作成します。（例: ‘Upcoming UX Research - Hi team! I’m about to start collecting data to inform some new navigation-related decisions focused in the Monitor, Infrastructure, Deployments, and Packages & Registries items with experienced GitLab users.’）メソッドはここでは言及されていないことに注意してください。これは意図的です。何が行われるかではなく、何が達成されるかにアナウンスを集中させます。
• スタディが答える主要なリサーチ質問について 3〜4 個の箇条書きをリストします。これらは詳細を含まず、非常に短い文にすべきです。
• 追加詳細のために Issue にリンクします。
• 結果を共有する予定のタイムラインに関するメモ。大まかな見積もりは受け入れられます。たとえば、’Results will be shared in 3-4 weeks from now’。
• オプション: この投稿をリサーチセッションへの参加者を招待する方法として使いたい場合は、確かにそうできます。その方法の例: ‘If you are interested in attending sessions live, please reply to this thread. Otherwise, I’ll post recordings to this Dovetail project [insert link], where you can watch on your own time.’
• 投稿は Slack で 少なくとも 次の 3 つのチャンネル: #ux、#ux_research、#product に共有されます。関連するステージグループチャンネルでも共有することを推奨します。

リサーチ結果のソーシャライズ

自分でリサーチプロジェクトを推進する場合、それらのインサイトをソーシャライズする責任もあります。最も効果的な方法は次のとおりです:

• 何が行われたかについての簡潔なイントロを作成します。（例: Hi team! I recently finished a tree test 🌳 on the left sidebar navigation focused in the Monitor, Infrastructure, Deployments, and Packages & Registries items with experienced GitLab users. I’m excited to share the key insights ⭐ :）
• 主要なインサイトを 3〜4 個の箇条書きにリストします。これらは詳細を含まず、ハイレベルな発見の非常に短い文にすべきです。
• リンク先: リサーチレポート、ビデオ読み上げ、データシート、リサーチ Issue、Dovetail プロジェクト
• ‘Next steps’ セクション。これにはリサーチの結果として何が起こるかについての箇条書きを含めます。アクション可能なインサイトとなる Issue へのリンクであるべきです。
• 投稿は Slack で 少なくとも 次の 4 つのチャンネル: #ux、#ux_research、#ux_research_reports、#product に共有されます。関連するステージグループチャンネルでも共有することを推奨します。

カバレッジの維持方法

UX リサーチチームはステージグループや参加者と非常に密接に連携しているので、PTO のときも、自分が休んでいる間でもリサーチプロジェクトを進めるための計画を持っていることが重要です。そのようなアプローチにより、チームとして互いをサポートできます。次の手順は、UX リサーチチームが PTO に関して従うプロセスを概説しています:

1. Workday とUXR チームの可用性カレンダー（内部リンク）の両方に PTO 日を入力します。Time off by Deel は、#ux_research_lounge Slack チャンネルまたはマネージャーへの自動返信を割り当てるよう求めます。
2. 他のチームメンバーとの PTO 日の重複に注意します。これは問題ありません - ビジネスへの影響がない限り。
3. タイムリーなビジネス影響のある進行中のプロジェクトに対処するためのカバレッジ Issue を作成します。
4. バックアップが: 1) PTO 中でないこと、2) あなたのバックアップになることに同意していること、を確認します。
5. 次の 1:1 でマネージャーに PTO 日を伝え、上記の手順が完了していることを示します。

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