プロダクトデザインオペレーション
プロダクトデザインは、GitLab のフルスタックエクスペリエンス組織であるUpstream Studiosの一部です。上流に位置する戦略的パートナーとして、私たちは最初から計画に関与し、これらの運用プラクティスを使用して、プロダクト開発プロセス全体を通じてデザインが統合されることを確保します。
デザインプロセス、コラボレーションプラクティス、技巧ガイダンスについては、プロダクトデザイナーのワークフローを参照してください。
Issue 管理
UX Issue のトリアージ
すべてのプロダクトデザイナーには、~UX、~Deferred UX、~UI polishのラベルが付けられた Issue をトリアージする権限があります。あなたがトリアージを担当していない場合でも、担当の PM と EM からフィードバックを求めるために含まれるべきです。Issue がいつ解決されるべきかを示すためにPriority ラベルを使用し、ユーザーへの影響を示すためにSeverity ラベルを使用してください。割り当てられたラベルについては、常に PM および EM と調整してください。
マイルストーン内の Issue のスケジューリング
戦略的パートナーシップとは、最初から計画に関与することを意味します。UX が必要なDeliverableとラベル付けされたすべての Issue は、キックオフまでにプロダクトデザイナーに割り当てられます。Stretchとラベル付けされた Issue は、キックオフまでに割り当てられる場合とそうでない場合があります。Workflow ラベルの使用方法の詳細については、GitLab Docsを参照してください。
スケジュールされた UX Issue をステージグループに伝える
チームのプランニング Issue にUser Experienceセクションを追加することを検討してください（例 1、例 2）。このセクションには、マイルストーンのアクティブなデザイン項目（リサーチプロジェクト、Deferred UX、UI polish、Pajamas コンポーネントなど）を含めることができます。プロダクトデザイナーのプランニングとキャパシティについて詳しく学んでください。
プランニング Issue にデザインの問題を含めることで、デザインの取り組みが可視化され、workflow::problem validation、workflow::design、workflow::solution validationの段階でクロスファンクショナルなコラボレーションが促進されます。
主な利点:
- 月次プランニングディスカッションの一部にすることで、ステージグループ内で UX を擁護する
- マイルストーンキックオフ時にプロダクトマネージャーとプランニング Issue を使用する
- 現在のデザインとリサーチの取り組みを、お客様やカウンターパートに定期的に伝える
- チームとプロダクトデザイナーのキャパシティを共有する
- デザインフェーズ中のカウンターパートとの早期コラボレーションを促進する
ワークフローラベル
プロダクトデザイナーはワークフローラベルを使用して、Issue が開発ライフサイクルのどこにあるかを追跡します。これらのラベルは、検証、デザイン、実装フェーズに私たちが関与しているタイミングを示すことで、戦略的ポジショニングを維持するのに役立ちます。
プロダクト開発フローのラベル:
Issue は必要に応じてこれらのラベル間を移動します。すべてのラベルがすべての Issue に当てはまるわけではありません:
workflow::validation backlogworkflow::problem validationworkflow::designworkflow::solution validationworkflow::planning breakdownworkflow::schedulingworkflow::ready for development
ワークフローラベルの詳細については、プロダクト開発フローを参照してください。
特定のラベルをいつ適用するか:
workflow::planning breakdown: 実装のためにソリューションをより小さな Issue に分割する必要がある。PM とエンジニアリングに提案されたソリューションを案内することで関与を続けるworkflow::scheduling: PM および/または EM によってソリューションがスケジュールされる必要がある。担当のプロダクトマネージャーをメンションし、割り当てられたエンジニアと連絡を取るworkflow::ready for development: Issue は現在のマイルストーンで実装されることを意図しており、エンジニアがソリューションに納得している
Build フェーズへの早すぎる移動の取り扱い:
デザインの DRI として、私たちは品質のラインを守ります。プロダクトマネージャーが、UX 基準を満たす前に Issue を Build フェーズに移動するよう依頼することがあります。そのような場合、フォローオン Issue を作成し、Deferred UXラベルを適用して、プロダクトが UX 要件を満たしておらず、即座のイテレーションが必要であることを示します。
ソリューションの提供
Issue の説明を更新する
作業が完了し、フィードバックが対応されたら、Issue の説明（SSOT）を「Solution」セクションで更新します。これは、何をどのように行うべきかの参照点となるべきです。
デザインを含める
「Solution」セクションにデザインを追加します。小さなデザインの場合、モックアップで十分かもしれません。より詳細な変更の場合、Figma ファイルへのリンクを含めてください。
デザインハンドオフのチェックリストを使用する
デザインハンドオフのチェックリストに従って、すべてのデザイン仕様が文書化され、エンジニアが成功できる準備が整っていることを確認します。
コラボレーションツールを活用する
Figma のコラボレーションツールを活用して、チームからフィードバックを集め、ディスカッションをナビゲートします。
新しい UX パラダイムを慎重に検討する
新しいパターンやパラダイムを提案する際:
- 新しいパターンが他の領域と一貫性がなくなるかを評価する
- 一貫性を維持するために他の領域を更新する必要があるかを判断する
- 新しいパターンがユーザーエクスペリエンスを大幅に改善するかを評価する
- 変更が必要な場合、コンポーネントライフサイクルのドキュメントに従う
フォロースルー
機能のスコープを縮小する
- レビューがより簡単で効率的になるように、エンジニアに機能を複数のマージリクエストに分割するよう促す
- 部分的な変更をマージすることの UX への影響を考慮する。部分的な変更が UX に悪影響を及ぼす場合、フィーチャーブランチまたはフラグを使用して、フルスコープが一緒に出荷されるようにする
最終的な目標を伝える
ソリューションを小さなパーツに分解する際、開発の取り組みを整合させるために、チーム全体が最終的なデザイン目標を理解していることを確認します。
SSOT を維持する
Issue の説明を最新に保つ:
- Issue の説明（SSOT）を、画像やデザインワークへのリンクを含むすべての合意された要素で更新する
- SSOT を明確に保つために、古いコンテンツを削除またはアーカイブする
- 明白な変更については、判断を使って、合意を待たずにSSOT を直接更新する
継続的に関与する:
- プロダクト領域の Issue を購読し、定期的にレビューする
- プランニングミーティングに積極的に貢献して、適切な優先順位付けを確実にする
- アクティブな Issue に割り当てられ、購読されたままにする
- 関連する MR をフォローし、発生する追加の UX 問題に対処する
デザインが確定した後のフォローアップ
Pajamas に影響する変更について
デザインシステムに影響する変更については:
- 新しい UI コンポーネント: GitLab Design でUX Pattern Issue を作成し、チェックリストに従う
- ドキュメントの更新: Design Systemで Issue および/または MR を作成する
- アプリケーションの更新: アプリケーションの影響を受ける領域を更新するための Issue を作成する
- 変更を周知する:
#upstream-studiosなどの Slack チャンネルを通じて、チームに変更を通知する
変更がライブになった後
フィードバックを集める:
- ソーシャルメディア、Slack、フォーラム、内部/外部ソースからのフィードバックに耳を傾ける
- フィードバックを追跡し対処するための Issue を作成する
これらの運用プラクティスに従うことで、Upstream Studios の戦略的パートナーシップと品質提供へのコミットメントに整合した、効果的なコミュニケーション、コラボレーション、継続的改善を確保します。
マネージャーオペレーション
チームメンバーの更新
プロダクトカテゴリページなどで、チームメンバーがサポートしているプロダクトの領域を更新する必要がある場合、一般的に以下のページとプロジェクトを更新または確認する必要があります。すべての更新について、名前がチームページで使用されている名前と一致していることを確認してください。
セクションレベルの更新:
- www-gitlab-com プロジェクト > Repository > Files に移動する
dataディレクトリを選択する- 下にスクロールして
sections.ymlファイルをクリックする - お好みのエディタータイプを選択する
- 更新する必要がある人を見つけ、変更を加え、コミット/MR を作成し、そこから MR プロセスに従う
グループレベルの更新:
- www-gitlab-com プロジェクト > Repository > Files に移動する
dataディレクトリを選択する- 下にスクロールして
stages.ymlファイルをクリックする - お好みのエディタータイプを選択する
- 更新する必要がある人を見つけ、変更を加え、コミット/MR を作成し、そこから MR プロセスに従う
チームメンバーの更新（UX MR Reviewer Roulette からの削除/追加など）:
- www-gitlab-com プロジェクト > Repository > Files - Documentation に移動する
data/team_members/person/productディレクトリにナビゲートする- チームメンバーのファーストネームの最初のイニシャルに対応するアルファベットの文字フォルダを見つける
- そのチームメンバーの
.ymlファイルをクリックする - お好みのエディタータイプを選択する
- UX MR Reviewer Roulette ボットから削除する場合:
projects:セクションの下にあるgitlab: reviewer UX行を削除する- コミット/MR を作成し、そこから MR プロセスに従う
- UX MR Reviewer Roulette ボットに追加する場合:
- チームメンバーが削除された元の MR を元に戻すか、上記の手順に従って当該の
.ymlファイルを再度見つける projects:セクションの下にgitlab: reviewer UX行を追加する- コミット/MR を作成し、そこから MR プロセスに従う
- チームメンバーが削除された元の MR を元に戻すか、上記の手順に従って当該の
トリアージレポート:
triage-ops プロジェクトで、チームメンバーをトリアージレポートの受信から追加または削除する MR を開きます。編集するファイルはgroup_definition.ymlです。
レトロスペクティブ:
GitLab team retrospective グループで、チームメンバーセクションとグループを見つけ、そこでチームメンバーを追加および削除します。この手順は、機密の Issue がチームメンバーから見られるようにするために必要です。
また、async-retrospectivesのteam.ymlファイルでチームメンバーを追加または削除する MR を開いてください。
成長と開発
成長と開発のリクエストでチームメンバーと作業する際は、Growth and Development Benefit のガイドラインを参照してください。
人材評価
プロダクトデザインとデザインシステムでは、マネージャーと直属の部下の間で人材評価と成長に関する会話を促進するために、パフォーマンスファクターワークシート（🔒 internal only）を活用しています。これらのワークシートは Google Sheets 形式で利用可能で、年中間および年末レビュー用のタブと、年間を通じての成果、強み、機会をリストアップするタブを含んでいます。
各チームメンバーが会計年度の初めに自分自身のワークシートを作成し、年間を通じてツールとして使用することを強く推奨します。
パフォーマンスファクターワークシートを活用することで、Workday 内の 年末の全社人材評価プログラムを効率的に完了できます。
bfd74782)