調査の優先順位付け
UX Researcher は GitLab でユーザー調査を実施する唯一の存在ではありませんが、私たちはすべての調査が高品質でインパクト主導であることを確保する責任があります。小規模なチームとして、私たちはグローバル優先順位付けフレームワークとプロセスを適用しているため、次のことが可能になります:
- 最重要の調査イニシアチブの組織全体の評価と優先順位付けを保証する
- サイロを壊し、データの三角測量を標準化するプログラムを作成する
- 取り組みの重複（現在および過去の作業）のリスクを減らす
- 研究者間の学習とコラボレーションを促進する
調査プロジェクトの優先順位付けの責任者は誰ですか？
GitLab の UX Researcher は複数のステージグループに従事し、しばしばステージを横断して作業しています。UX Researcher は、自分がサポートするエリアの優先順位付けについての視点を提供します（誰がどのエリアをサポートしているかを参照）。最終的に、Group Product Manager または Director of Product が調査プロジェクトの優先順位付けについての最終的な決定を行います。
UX 調査のグローバル優先順位付けの頻度はどのくらいですか？
UX Research チームは、会社の OKR 計画タイムラインと整合させ、四半期の始まりごとに同期的にプロセスを通過します。これは、ステークホルダーまたは UX Researcher 自身によって、調査リクエストの大部分が提起されるときです。これらのリクエストは、その後議論、評価、優先順位付けされます。
ただし、四半期中にもかなりの数の調査リクエストが提起されます。これは、特に急速に変化するテクノロジー業界では、状況が変わり、優先順位が変動するためです。アドホックな調査リクエストは、四半期の始まりに提起されたものと同じフレームワークを使用して議論、評価、優先順位付けされます。
チームのキャパシティが一杯のとき、新しいプロジェクトを引き受けるには、別の何かを止める必要があります。優先度の高い新しいプロジェクトは、現在の最も低い優先度の作業を押し出します。
四半期ごとのグローバル優先順位付けの仕組み
ステップ 1. インテーク
新しい四半期の始まりに、UX Researcher は Product と Design のステークホルダーと、戦略／KR／ロードマップの変更や進展について確認し、可能な新しい調査プロジェクトや既存のプロジェクトの調整について議論します。これは、テンプレート化された UXR Global Prioritsation Intake Issue で行うことができます。
ステップ 2. 基本の理解
ステークホルダーまたは UX Researcher が提案するすべての調査リクエストは、最初の有機的なセンスチェッキングフェーズを経ます。ここでは、解決すべき問題、調査目標、調査がどの決定にフィードするか、意図するビジネスインパクトタイプなど、基本について話します。
すべてのリクエストには、1 つの主要な意図するインパクトタイプが明確に特定されている必要があります。
| カテゴリ | インパクトタイプ |
|---|---|
| 決定への影響 | 1. 戦略／計画の変更 2. 製品／デザインの変更 |
| 知識への影響 | 1. 知識のギャップを特定／埋める 2. 製品に対するユーザーの認識を捉える 3. 次の大きな機会を特定する |
| UXR の成熟への影響 | 1. UXR プロセス効率の改善 2. UXR の品質と信頼性の改善 |
人々がつながりを作り、既存のインサイト、より効率的な代替案、またはビジネスインパクトの明確なケースがないという合意に達した結果、このフェーズで一部のリクエストはドロップされる可能性があります。
一部のリクエストは、目標、調査質問、スコープが重複しているため、他のリクエストや既存のプロジェクトに統合される場合があります。
ステップ 3. 優先度とサポートレベルの評価
その他のすべてのリクエストは、評価され、P1 から P4 までの優先度レベルが与えられます。これは、UX Researcher が私たちの優先度計算機をガイドとして使用してステークホルダーとの議論をリードすることで行われます（Google Sheets の例 - 内部アクセスのみ）。
詳細はクリックしてご確認ください
優先度計算機は 6 つの質問を尋ね、各質問に 1〜5 のスコアを与えます。平均スコアが優先度レベルにマッピングされます。
| 基準 | 質問 | スコア／重み |
|---|---|---|
| インパクト | この調査を行わない場合のビジネスインパクトは何ですか？ | 1: 重大なインパクト - 主要なリスク 2: 高インパクト - 大きな機会 3: 中程度のインパクト - 有用なインサイト 4: 低インパクト - あればよい 5: 最小のインパクト - 明確なケースなし |
| ユーザー | これは何人のユーザー／顧客に影響しますか？ | 1: すべてのユーザー／重要なセグメント 2: 大規模なユーザーセグメント 3: 中規模のユーザーセグメント 4: 小規模なユーザーセグメント 5: 非常に少数のユーザー |
| 依存関係 | これは即時の決定をブロックしていますか？ | 1: 重要なローンチをブロック 2: 重要な決定をブロック 3: すぐに入力が必要 4: 将来の計画 5: 特定の決定なし |
| タイムライン | タイムラインの柔軟性はどのくらいですか？ | 1: 今四半期 2: 即時（今月） 3: 6 ヶ月以内 4: 9 ヶ月以内 5: タイムラインのプレッシャーなし |
| 代替案 | この情報を得る他の方法はありますか？ | 1: 代替案は存在しない 2: 限られた代替案 3: いくつかの代替案 4: いくつかの良い代替案 5: 多くの代替案 |
| 整合性 | これは私たちの戦略目標とどのように整合していますか？ | 1: 中核的な戦略的優先事項 2: 四半期目標と整合 3: チーム目標をサポート 4: 間接的な整合 5: 明確な整合なし |
| 優先度レベル | 平均スコア | 説明 |
|---|---|---|
| P1 (やる必要がある) | <=1.5 | 重要なビジネスインパクト: 主要な企業メトリクス／OKR とイヤリーに直接影響する; 主要な製品ローンチ／リリースをブロックしている; 主要な製品ローンチ／リリースに関する未知の領域に対処する; 法的／コンプライアンス要件 調査なしの高リスク: 大きな潜在的収益損失; 主要なユーザー体験の劣化; セキュリティ／プライバシーの懸念 |
| P2 (やるべき) | <=2.4 | 戦略的重要性: 四半期目標に整合; 重要な製品決定が保留中; 複数のチーム／製品が影響を受ける。 明確なビジネスインパクト: 収益機会 > $X; 相当数のユーザーベースに影響; 時間に敏感な機会 |
| P3 (やれるとよい) | <=3.5 | 中程度のビジネスインパクト: 単一製品／機能に影響; 中期決定; 影響範囲が限定的 良い機会: 既存の体験を改善; チームの計画をサポート; 知識ベースを構築 |
| P4 (バックログ) | <=4.5 | 低い即時インパクト: 将来の計画; 重要でない改善; あればよいインサイト 遅らせることができる: 即時の決定が保留中ではない; 代替データソースが利用可能; より低い戦略的整合 |
| やらない | >4.5 | 最小限のビジネスインパクト: 明確なビジネスケースなし; 範囲が非常に限定的; 既存の調査の重複 リソース集約的: 高い努力、低いリターン; 大きなリソースを必要とする; 他の手段でよりよく対処できる |
次に、サポートレベル計算機（Google Sheets の例 - 内部アクセスのみ）を使用して、UX Researcher がどのように努力を最善にサポートすべきかを決定します。
詳細はクリックしてご確認ください
計算機は次の領域を考慮に入れます。各基準は以下の表に従ってスコアを受け取り、合計してから合計可能なスコアで割って、適切な UX Research サポートレベルを示すパーセンテージを取得します:
| 基準 | 説明 | スコア／重み |
|---|---|---|
| Issue | 調査 Issue へのリンク | N/A |
| タイプ | プロジェクトが該当する調査のタイプ: 基礎的、問題検証、ソリューション検証。 | 基礎的 = 3 問題検証 = 2 ソリューション検証 = 1 |
| オーナーシップ | この調査は UX Researcher 以外の誰かによってサポートされ得るか？ | はい = 3 ある程度 = 2 いいえ = 1 |
| デザインサポート | このプロジェクトは、Product Design サポートを持つ Product チームによって要求されていますか？ | この調査には該当しない（UX Research によって作成／リード） = 3 要求している Product チームには Product Designer がいる = 2 要求している Product チームには Product Designer がいない = 1 |
| 複雑さ | このプロジェクトには複数の調査または手法が含まれますか？ | はい = 2 いいえ = 1 わからない = 0 |
| スキル開発 | UX Researcher が関与している場合、これはチームのスキル開発をサポートしますか、またはプロセスを改善しますか？ | はい = 3 ある程度 = 2 いいえ = 1 |
| 自信 | 提案されたソリューションまたは焦点領域における自信または知識のレベルはどのくらいですか？ | 高 = 3 中 = 2 低 = 1 |
UXR サポートレベルは、特定の調査プロジェクトに UX Researcher が確約できるサポートのレベルとして定義されます。
| UXR サポートレベル | パーセンテージ |
|---|---|
| エンドツーエンド（旧 Gold）🥇 | 80% を超える |
| タスク固有（旧 Silver）🥈 | 51% から 80% の間 |
| コンサルト／レビュー（旧 Bronze）🥉 | 50% 以下 |
| UXR サポートレベル | 説明 |
|---|---|
| 🥇 エンドツーエンド（旧 Gold） | DRI: UX Researcher これらのプロジェクトはどのようなものか: 調査スペシャリストから利益を得ることができる、大規模で戦略的で厳密なプロジェクト。通常、基礎的な調査、複雑な調査質問、または高優先度の問題検証。 誰が何をするか? UX Researcher はプロジェクト管理、実行の側面、ほとんどのタスクの完了を推進しますが、Product と Design からのサポートがあります。UX Researcher が DRI ですが、チームは調査セッション、分析、結果の議論などへの参加が強く推奨されます。 推定調査数: - 0.5〜2 のアクティブなプロジェクト（UX Researcher のレベルによる） 例: - 複数の調査に影響する調査 - 複数の手法の調査 |
| 🥈 タスク固有（旧 Silver） | DRI: Product/Design これらのプロジェクトはどのようなものか: これらは主に問題検証プロジェクトで構成されます。 誰が何をするか? UX Researcher は調査内の指定されたタスクを引き受け、残りについてアドバイスします。Product と Design がプロジェクト管理、実行の側面、ほとんどのタスクの完了を UX Researcher のサポートのもとで推進します。 推定調査数: - 1〜6 のアクティブなプロジェクト（UX Researcher のレベルによる） 例: - UX Researcher と Product Manager または Product Designer が調査手法でコラボレーション、スクリプトを作成、または分析をレビュー。 - UX Researcher は、実行に数日未満かかる特定のタスクに専用のサポートを提供します。 |
| 🥉 コンサルト／レビュー（旧 Bronze） | DRI: Product/Design これらのプロジェクトはどのようなものか: これらは主にソリューションおよび問題検証プロジェクトで構成されます。 誰が何をするか? UX Researcher は調査の特定の側面についてコンサルされます。Product/Design がプロジェクト管理、実行の側面、ほとんどのタスクの完了を、UX Researcher からのアドバイスのもとで推進します。チームは Issue で UX Researcher にタグを付けて、フィードバックが必要な時期のコンテキストと期日を提供します。 推定調査数: - UX Researcher の時間の 10% 以下が、これらのプロジェクトのサポートに専念されるべきです。 例: - インタビュースクリプトのレビュー - 参加者リクルートメント基準 - 手法の選択 |
両方の計算機は推奨事項を生成するだけであることに注意してください。最終的な優先度レベルとサポートレベルを決定し合意するのは、UX Researcher とステークホルダーの責任です。
ステップ 4. 決定の作成と伝達
優先度レベルとサポートレベルに合意したら、UX Researcher はワークロードサイズを稼働日数で推定し、ステークホルダーと合意して、どのプロジェクトを引き受けるか、どれをドロップするか、または押し出すかを決定できます。
そのために、3 つのチーム容量ルールに従います:
- 予期しない作業（アドホックリクエストなど）、トレーニング、お互いをサポートする（ピアレビューや休暇カバレッジなど）ために 20% の容量を保持します。
- 常に P1 プロジェクトを引き受けます。
- 容量に達しているとき、新しい優先度を引き受けるには別の何かを止める必要があります。新しいより高い優先度のプロジェクトは、現在の最も低い優先度の作業を押し出します。
全員が同じ認識を持ったら、チームは今四半期に引き受けたプロジェクトを関連する Slack チャネルおよび Product と UX ミーティングで伝達します。
注意: 現在の作業は四半期を通じて以下の方法で監視・調整されます:
- 中間チェックイン - グローバル優先順位付けプロセスのミニ版
- 月次バックログトリミング
- 引き受ける必要があるアドホックリクエストを受け取った後の再調整
アドホックリクエストの処理方法
優先順位付けが行われた後、新しい調査プロジェクトをアドホックに特定することは通常のことであり、これらの新しいリクエストを既存の優先順位付けリストに統合することができます。その方法は次のとおりです:
- リクエスター は調査 Issue（テンプレート）を作成し、基本情報を入力します。
- リクエスター が Product または Design のステークホルダーである場合、Issue を自分自身とそのエリアの UX Researcher に割り当てます。リクエスター が UX Researcher である場合、Issue を自分自身と関連エリアの Product および Design のカウンターパートに割り当てます。
- ステークホルダーと UX Researcher は、上記のステップ 2〜4 を経ます。
- プロジェクトを引き受けることを決定し、UX Researcher が容量に達している場合、現在のより低い優先度の作業をドロップするかオフロードし、関連するステークホルダーと伝達する必要があります。
注意: 必要に応じて、UXR リーダーシップを呼び込んで再優先順位付けを支援することができます。
調査優先順位リストの維持
四半期を通じて、UX Researcher はグローバル調査優先順位リストを維持し、プロジェクトのステータスを最新の状態に保ち、変更や調整を四半期 UX Research グローバル優先順位シート（Google Sheets の例 - 内部アクセスのみ）に文書化します。
プロセスに関するフィードバックの募集
オプション: 四半期の終わりに、UX Researcher は、プロセスがチームにとってどうだったかについてフィードバックを得るためにレトロコメントスレッドを開きます。これは、計画プロセスを振り返り、そのサイクルを通じて調査がどうだったかを議論し、次のサイクルで行う改善を特定する機会です。
レトロコメントスレッドで検討するかもしれないいくつかの質問:
- 何がうまくいきましたか？
- 何がうまくいかなかったですか？
- 最も重要な調査プロジェクトが優先順位付けされ実行されたと感じますか？
bfd74782)