プロダクトデザイナーの優先順位とキャパシティ管理
プロダクトデザイナーは Manager of Oneとして働き、トリオの作業、プラットフォームイニシアチブ、より広範な Upstream Studios の責任に対して、自らのキャパシティの配分順序を決めます。このページでは、作業の優先順位付けとキャパシティ計画に関するガイダンスを提供します。
Product Designで働くプロダクトデザイナー向けです。Product Design は Upstream Studiosの一部です。
キャパシティの計画と管理
プロダクトデザイナーは、トリオの対等なメンバーとしてグループに割り当てられます。以下のガイドラインは、制作作業と、このロールの核となる上流段階での判断の両方にキャパシティを確保しながら、作業の順序を決めるために役立ちます。
プロダクトデザイナー
- プラットフォームイニシアチブなどの Upstream Studios の割り当てと、成功するために必要なことをクロスファンクショナルな同僚に知らせてください。
- リクエストによってリサーチ、探索、トリオの戦略作業が圧迫される場合は、キャパシティ上のトレードオフとしてマネージャーに直接提起してください。
- マイルストーン計画中は、休暇(自分と他人の両方)を考慮してください。
- コミットした作業を期限内に完了できないと思った場合は、分かった時点ですぐにマネージャーとトリオへ伝えてください。早めに知らせることで、トレードオフについて話し合う余地を保てます。
- オプションで、UX Issue のウェイトを使用してキャパシティをよりよく理解し、プロダクトマネージャーとの会話を促進してください。
プロダクトデザインマネージャー
- 要求があれば、プロダクトデザイナーが各マイルストーンでグループおよびプラットフォームに割り当てられた作業のベースラインキャパシティを設定できるよう支援してください。
- 制作作業には、明確な完了までの時間(TTC)の期待値と期限を設定してください。戦略作業には、チームの学びに応じたペースで、測定可能な目標とチェックポイントを設定してください。
- チームの質問、懸念、ブロッカーを迅速に解決してください。
- AI がより多くの定型的な制作作業を担うようになったら、空いたキャパシティをディスカバリーと戦略作業に振り向けてください。
- クロスファンクショナルパートナーに、デザイナーのキャパシティには制作作業項目だけでなくディスカバリーと戦略作業も含まれることを理解してもらい、潜在的な依存関係も認識してもらってください。
優先順位
最も大きな効果を生む作業は、コードが 1 行でも書かれる前に行われます。問題を検証し、プロトタイプに飛びつく前にフローから始め、成功基準を早期に設定することです。複数の作業が同じ時間を必要とする場合は、次の順序で優先します。
必須:
- 現在のマイルストーンでコミットしたトリオの作業:
workflow::problem validation、workflow::solution validation、またはworkflow::designラベル付きで割り当てられた Issue、次のマイルストーンの計画、Upstream Forum、Slack、デザインクリティークを通じた進捗共有。これは自分がコミットした作業であり、最優先です。 - 他の人の作業をブロックしているもの: 自動化されたカバレッジがまだない場合の同僚からのフィードバック依頼と、コミュニティコントリビューションを含むマージリクエストレビュー。自分の担当領域で自動化によるカバレッジを進め、これに費やす時間を徐々に減らしてください。
- 具体的なソリューションのスコープを定める前に行う、大規模で全体的なロードマップ施策の探索・ビジョン策定作業。誰も待っていないため、最も削られやすい作業です。だからこそ、キャパシティを確保して守る必要があります。
すべき:
- ユーザーとそのワークフローの理解を改善するタスク(例: UX スコアカード)。
- 現在のリリースマイルストーンで
Stretchとラベル付けされた Issue と、Pajamas デザインシステムへのコントリビューション(pajamas::define、pajamas::design、pajamas::build、pajamas::integrate、および未完了の Pajamas の ToDo ブロック)。さらに広い範囲に手を伸ばす前に、残りのキャパシティをここに充てます。
できれば:
- 将来のリリースまたはバックログのマイルストーンにある Issue、コミュニティラベル付きの取り組みやすい課題、マイルストーンのない人気の Issue、外部での作業共有。上記のどれにも対応する必要がない場合に取り組んでください。
プロダクトマネジメントの支援
トリオの戦略的パートナーとして、プロダクトデザイナーはユーザーのニーズに関するインサイトを提供し、クイックウィンとより大きな戦略的イニシアチブの両方を特定するのに役立ちます。この協調的なアプローチにより、デザインは上流段階から関与し、最初から計画の議論を形作ります。
UX Issue ウェイト
Issue ウェイトはオプションですが、計画に役立ちます。プロダクトデザイナーが自身のキャパシティを理解し、休暇の影響を評価し、プロダクトマネージャーとのトレードオフディスカッションを促進し、より多くの UX サポートが必要なチームを特定するのに役立ちます。
UX Issue ウェイトの使用方法
- 今後の Issue をレビューし、作業を分解する
- 提供されたチャートを使用して Issue ウェイトを割り当てる。必要に応じて明確化のためにプロダクトマネージャーと協力する
- チームの好む方法を使用して Issue ウェイトを記録する
- Google docs に Issue とウェイトをリストする
- UX 作業用のリンクされた Issue を作成し、ウェイトを追加する(完了後にクローズする)。
- design-weight ラベルを使用する
- イテレーションやマイルストーンを計画するときに、キャパシティと総 Issue ウェイトを伝達する
- 将来の計画精度を向上させるため、マイルストーン後にウェイトをレビューする
追加メモ:
- ほとんどの UX Issue(リサーチや Pajamas 関連の Issue を含む)は、希望すればウェイトを付けられます
- キャパシティを決定するときは、視覚的レビュー、ミーティング、その他のウェイトのない責任を考慮してください
- 非常に小さい Issue(1 未満)にはウェイトを付けないでください
- ウェイト 8 または 13 は、Issue が大きすぎる可能性があることを示します
- マイルストーン中の計画外の作業にウェイトを追加し、プロダクトマネージャーとトレードオフを議論してください
マイルストーンキャパシティテンプレート:
- 前回のマイルストーンで完了した総ウェイト: 10
- 平均キャパシティ(過去 3 か月で完了したウェイトの平均): 10
- 現在のマイルストーンの推定キャパシティ: 7(平均キャパシティを使用し、計画された休暇を差し引く)
- 現在の総ウェイト: 10
UX ウェイトの定義
| ウェイト | デザインタスク | ユーザーリサーチタスク |
|---|---|---|
| 1 | 主に小さなインクリメンタルな UX 改善につながる小さな UI 変更。これらの変更にはユーザーのワークフローは関与しません。要件は明確で、未解決の質問はありません。例: コピーの実験やボタンのスタイル変更。 | 以前のリサーチ結果を統合し、それらに基づいて推奨事項を生成する。 |
| 2 | すべての要件を理解しているが、既知の質問/問題に対する解決策を見つける必要があるかもしれない単純な UI または UX の変更。これらの変更は実際のユーザーワークフローに溶け込む必要があります。例: トライアルフローでサインイン/登録プロセスを簡素化する。 | ファーストクリックテストやその他のタイプのモデレートされていないリサーチ調査を実施する |
| 3 | よく理解されている変更だが、作業範囲がより大きい。複数のページが関与し、かつ/または小さなフローのデザイン/再デザイン、または既存のフローを互いに接続することを始めている。デザイナーは広範な背景調査(以前の Issue、サポートチケット、過去のユーザーリサーチのレビュー、分析のレビューなど)を実施することがあります。作業中にいくつかの未知の質問が生じる可能性があります。例: CustomersDot のチェックアウトページを更新してサブスクリプションと請求情報の入力を可能にする、アプリ内でセールスへの問い合わせオプションを追加する実験。 | 単一ページのユーザビリティレビューなど、答えるべき特定の質問を持つモデレートされた範囲の狭いリサーチ調査 |
| 5 | 可能な限り早い段階でグループメンバーからのインプットが必要な複雑な変更。複数のページにまたがり、製品の別のエリアと潜在的に接続する中規模のフローに取り組んでいます。回答が必要な重要な未解決の質問があります。プロダクトデザイナーは独自に、またはリサーチャーと協力して何らかのリサーチを行う必要があるかもしれませんが、必ずしもそうとは限りません。考えられるリサーチ活動には、Job To Be Done の発見と/または検証、ユーザーテストやカードソート、調査の実施などが含まれます。例: UX スコアカード、アップグレード時の dismiss アクションを改善する方法。 | エンドツーエンドのフローや複数の関連機能のユーザビリティを評価するリサーチ調査、または小さな探索的要素を含むユーザビリティ調査 |
| 8 | 他の大きなフローと接続する新しいユーザーフローを導入する複雑な変更で、同じステージグループまたは別のステージグループの他のデザイナー、プロダクトマネージャー、またはエンジニアからのインプットが必要な場合があります。これは単一のマイルストーンで取り組む最大のフローデザイン/再デザインです。これにはリサーチが必要で、デザイナーがリサーチャーと協力して探索的インタビューやユーザーテストセッションを計画して実施する場合とそうでない場合があります。例: オンボーディング Issue ボードを通じて新規サインアップをオンボードする。 | 1 つ以上の異なるユーザーグループを含む、単一のステージに関連する広範な行動を調査する探索的調査 |
| 13 | 複数のユーザーフロー、大規模な新機能、かつ/または完全な再デザインに影響する非常に重要な変更。この Issue は製品戦略に大きな影響を与え、他の人(より広い GitLab コミュニティ、e-group、顧客)からの重要なインプットが必要で、未知数が多くあります。これにはリサーチが必要で、デザイナーはリサーチャーや他のデザイナーとチームを組んでインプットデータを収集し、探索的インタビューを計画して実施し、ユーザーテストセッションをリードすることができます…マイルストーンでこの Issue を完了することにコミットすることはまずなく、要件をさらに明確化するか、複数のマイルストーンで計画されたより小さな Issue に分割することが望ましいです。例: GitLab.com SaaS ユーザー向けの改善された無料トライアルサインアップエクスペリエンス。 | 複数のステージと複数のタイプのユーザーにわたる広範な行動を調査する探索的調査で、異なるステージのチームメンバーが関与する可能性があります。 |
c955a93f)