プロダクトデザイナーのワークフロー

Product Designer は、Product Design 内で働きます。Product Design は Upstream Studios の一部です。私たちは戦略的パートナーとして上流に位置し、プロダクト開発プロセス全体を通じて Product Management と Engineering とのトリオで協力します。

Issue のトリアージ、ラベル付け、スケジューリングなど運用の詳細については、Product Design Operations を参照してください。

プロダクトデザインプロセス

Product Designer は、早期のコラボレーション、ユーザー中心の思考、継続的な検証を重視する、戦略的でイテレーティブなプロセスに従います。戦略的パートナーとして、私たちは最初から関与しており、既になされた決定を実行するだけでなく、方向性を形作ります。

機会を定義する

PM と協力して、who/what/why の検証から始めます。

• 誰 のためにデザインしているのか、何 をデザインしているのか、なぜ デザインしているのかを検証します
• PM がこれを job to be done (JTBD) として表現するのを手伝います。ユーザーが達成しようとしていることと、その周囲のコンテキストを理解することです
• エビデンスに基づかない「どのように」の実装を求められた場合、PM に who/what/why に焦点を戻し、最適な方法を協力して決定するよう促します
• PM が MVC の成功基準を定義するのを支援し、MVC の「必須」と非 MVC の「すべき」「可能」を優先順位付けします

これらの基準は、イテレーティブなデザインプロセスと顧客フィードバックからの新しい洞察に基づき変わる可能性があることに注意してください。

デザイン前に

アイデアを生む

戦略的パートナーは、リクエストにただ応えるだけではなく、積極的に探求し、実験し、考えを前進させます。Upstream Studios は好奇心を保ち、前提を疑うことを大切にしています。これは、解く価値のある問題を積極的に探すことを意味します。

Product Designer として、チーム内のアイデア生成をリードし促進してください。既知の UX 問題に対処し、PM とプロダクトロードマップに取り組むことは重要ですが、まだ発見されていない、探求する価値のある問題もあることを忘れないでください。

創造性を刺激するアクティビティとリソース:

• ワークショップを開催: 同期（例: ThinkBig!）または非同期のワークショップを開催してアイデアをブレインストーミングします
• カウンターパートと関わる: 新鮮な視点を得るため Sales、Customer Success、または Marketing のカウンターパートに連絡します
• 問題検証リサーチを実施: PM や UX Researcher と協力して、問題検証リサーチ のラウンドを優先します
• 顧客コールに参加: PM との顧客コールに参加し、ユーザーが自身の課題やワークフローをどのように説明するかを直接聞きます
• 未知のペインポイントを発見:
  • Dovetail を使ってデータを分析し、リサーチリポジトリにアクセス
  • Gong を使って、セールスコールの録音から洞察を検索
  • Zendesk を探って既存の問題を特定
  • コミュニティフォーラム をレビュー

スペースを理解する

• 既存のリサーチをレビュー: UXR Library を調査します。関連するリサーチが存在しない場合、Slack (#experience_research) で Experience Research チームに連絡します。
• 競合分析を実施: 競合他社を分析し、用語、機能、UX 慣習を理解します。戦略的な理由がない限り、業界標準に準拠します
• ユーザーフローとジャーニーマップを作成: フローやジャーニーマップを作成し、ワークフローの包括的な理解を確保します

考えられる依存関係を調査

私たちの中核的な戦略アプローチの 1 つであるプラットフォーム思考とは、自身の作業がプロダクト体験全体にどのように影響するかを、担当領域だけでなく評価することを意味します。デザイナー同士の強い結びつきが、この戦略的視点を可能にします。

• 同僚と協力: 他の Product Designer に積極的に連絡を取り、背景情報を集め、自身の作業が他のプロダクト領域とどう相互作用するかを理解します
• DRI を特定し関与させる: そのプロダクト領域の Directly Responsible Individual (DRI) を特定し、最初から関与させます。不明な場合は、Product Categories ページ を参照してください
• プロダクトキックオフをレビュー: Product Kickoff Review を確認し、他のステージで何が計画されているかを把握します

アイデアを出してイテレートする

優れたデザインはビジョンから始まります。作業をイテレーションに分解する前に、目指す先の明確なイメージ、すべての決定を導く北極星を確立します。ビジョンがなければ、イテレーションは意図的な変革的成果に向けた進歩ではなく、局所最大値へのあてどない洗練となります。

魅力的なビジョンが確立されると、イテレーションが配信戦略となります。ビジョンを最小単位の変化に分解し、ユーザーをその将来の状態に意味ある形で近づけます。各リリースは、前提を検証し、学習を生成し、ソリューションとビジョン自体の双方の洗練に役立てるべきです。

ビジョンを構築・伝達する:

• 北極星を定義: PM やエンジニアリングパートナーと協力して、最終状態の体験を表現します。ユーザーにとっての成功とはどのようなものか？ どの問題が完全に消えるのか？
• 戦略的アーティファクトを使用: ジャーニーマップ、ストーリーボード、デザインビジョンは、トリオを揃え、ステークホルダーに方向性を伝えるのに役立ちます。ソリューションのスコープが大きい場合は、忠実度を低く保ちます
• ビジョンを生きたものとして扱う: デザインビジョンは恒久的ではなく、出荷と学習を通じて進化します。各イテレーションが次のバージョンの北極星に役立ちます

イテレーションで配信する:

• 低忠実度から始め、確信に応じて忠実度を上げる: アイデアを伝える最もシンプルなアーティファクトから始めます。ソリューションが固まり実装が近づくにつれて忠実度を上げます
• PM と早期にパートナーシップ: Interlock 計画から問題定義と成功基準を一緒に形作ります。戦略的パートナーは最初から関与し、決定がなされた後に呼ばれるのではありません
• エンジニアリングと協力: 技術的な実現性とデザイン視点のため、エンジニアを早期に巻き込みます。最高のソリューションは、多様な視点が互いに挑戦することから生まれます
• デザインクリティークを使用: 他の Product Designer とのクリティークに参加し、客観的なフィードバックと新鮮なアプローチを得ます
• Technical Writer とパートナー: UI テキストの大幅な変更については、グループの Technical Writer と協力します
• Product Design Manager を巻き込む: 重要な UX 変更については、より広いコンテキストと戦略的な調整のため、PDM を含めます
• データでデザインし、経験で判断: UX リサーチ を通じて、高リスクの方向性をユーザーで検証します。低リスクの作業については、リリース後にフィードバックを集めます。経験に基づく直感は判断材料となりますが、それは例外であり、ルールではありません
• デザインおよび UI 変更チェックリスト を使用: 出荷前に可読性、外観、機能性を確保します

分解について:

「物事を分解することは、デザイナーとしての私に心理的安全を与えます。」 - GitLab Product Designer

MVC を洗練する

集中力を維持し、スコープクリープを避けるために:

• 必須を優先: PM や開発者と協力して、「必須」と先送りできる要素を特定します。非 MVC のコンセプトは新しい Issue に文書化し、元と紐付けます
• 高確信・低リスクの変更: 検証が完了する前に開発者が開始する必要がある場合、高確信・低リスクの変更に焦点を当てます
• 先回りして計画: PM と Product Designer は協力して 1〜2 か月先行する ようにし、十分に検証された機会が Build トラックに常に用意されるようにします
• 大きな機能を管理: 機能は 1〜2 マイルストーン以内で構築可能であるべきです。大きすぎる場合は、PM や Engineering チームと協力して、より小さく管理しやすいセグメントに分割します

インスピレーションには、Product Designer が GitLab でのイテレーション について語る動画をご覧ください。

MVC ソリューションを提示する

1 つのソリューションを提案する:

デザイン判断権限を持つデザイン DRI として、複数のオプションではなく、検証された 1 つのソリューションを提案します。代替案を提案すると、デザイン・バイ・コミッティーにつながり、戦略的パートナーとしての強い視点を損ねる可能性があります。複数のソリューションを提案する必要がある場合は、理由を明確に説明してください。

コンテキストとゴールを非同期に共有:

• 提案を理解し、どう支援できるかを聴衆が把握できるよう、Issue にすべての必要なコンテキストを提供します
• ソリューションが誰のためか、何ができるようになるか、フィードバック・支援・承認が必要かを明確にし、それらを求める相手に @メンションします
• 前回のレビューからの変更点を強調し、理解を容易にします
• 折りたたみコンテンツセクション を使用して、メインの要点から逸らさずに補足情報を含めます

Product Design Manager からフィードバックを依頼:

Product Design Manager に @mention してフィードバックを求めます。Product Design Manager は戦略的な調整を提供し、品質を確保し、プロダクト全体で機能の一貫性を維持できます。

顧客と問題に焦点を当てる:

UI や機能ではなく、顧客と解決している問題を中心にデザインの議論を組み立てます。現状から始め、それがユーザーニーズをどう満たせていないかを説明し、提案するソリューションをユーザー視点から提示します。

質問を予期し対応:

• 起こり得る質問を予期し、提案コメントで対応します
• 理由を説明してフィードバックループや不要な議論を減らします
• 質問として組み立てた見出し で提案を構造化し、明確さと焦点を提供します

デザインファイルガイドラインに従う:

SSOT を最新に保つ:

合意されたすべての要素（画像やデザイン作業へのリンクを含む）で Single Source of Truth が更新されていることを確認します。

デザインレビュー

Upstream Studios は、戦略的パートナーがまず強い内部の結びつきを持ち、次に強い外部のパートナーシップを持つことを重視します。デザインレビューは、戦略的思考とプラットフォーム全体のコラボレーションを可能にする、デザイナー同士の関係を構築します。

作業の共有とフィードバック収集は、デザインプロセスのどの段階でも可能であり、多くの場合 Issue でのモックや開かれた議論を通じて行われます。デザインレビューは、Product Designer が特定のフィードバックを与えたり受けたりする専用のセッションです。

デザインレビューの利点:

• 他のメンバーが何に取り組んでいるかを発見する
• 重複する作業を特定する
• グループでのコラボレーションの機会を表面化する
• 作業を共有する習慣を促進する
• 戦略的思考を可能にするデザイナー同士の関係を構築する

私たちは、より広い参加を可能にするため 非同期 なデザインレビューを優先します。非同期レビューの実施方法は以下のとおりです。

1. キーとなる Issue を特定: 多くの未解決の質問がある Issue や、自分が最も取り組みたい Issue を選びます
2. 最適なフォーマットを選択: Issue、テキスト概要、スクリーンショット、Figma ファイル、または短いビデオウォークスルーを使って作業を共有します
3. コンテキストを提供: 顧客の問題、制約、具体的なフィードバックニーズを共有します。どのようなフィードバックが欲しいか、どこに提供するかを明確に述べます
4. フィードバックのために投稿: 作業を #ux-coworking Slack チャネルや関連グループチャネルで共有し、アイテムとフィードバック先のリンクを提供します
5. 動画を録画: 動画を録画する場合は Zoom を使い、GitLab Unfiltered YouTube チャネルにアップロードします。機密でない限り公開設定にし、「UX」プレイリストに追加します
6. 参照付きコメント: 機能 Issue に動画と関連参照（例、Issue、エピック、Figma ファイルなど）へのリンクを添えてコメントします。動画の説明にもこれらのリンクを追加します
7. Issue でフィードバックをキャプチャ: フィードバック収集専用の Issue (例) を開き、レビューに必要なすべての参照と情報を添付します

例:

• 新しいリストのイテレーションを追加 - フィードバックのリクエスト
• スイムレーンボードの読み込み状態 - スケルトンローダーのフィードバックリクエスト
• 右側の Issue 対応サイドバーパターンのフィードバックリクエスト
• Geo: メンテナンスモードのデザイン

デザインレビューに含める人

デザインレビューに誰を含めるかを判断するのは難しい場合があります。ガイドラインを以下に示します。

• ステージグループ: Product Manager、Engineering Manager、Frontend Engineer、Product Design Manager は、常にレビューとフィードバック提供の機会を持つべきです。継続的なコラボレーションのため、これらの担当者を Issue に含めます
• デザイナー: デザインプロセスのどの段階でも、Section 内の同僚デザイナーを巻き込みます
• クロスステージのカウンターパート: 作業が他のステージに影響する場合、それらのカウンターパートを含めます
• 広範な影響: ナビゲーション、グローバルヘッダー／フッター、Pajamas パターンへの変更については、#ux_coworking Slack チャネルで UX Department のレビューを依頼するか、GitLab で @gitlab-com/gitlab-ux/designers にメンションします
• 他部門: 作業が他部門（例: Customer Success、Sales、Marketing）に関係する場合、特にブランドガイドラインから逸脱するときは、フィードバック提供を依頼します

誰を含めるかわからない場合は、Product Design Manager に相談してください。

デザインクリティーク

Upstream Studios はクラフトの底上げと、コラボレーションをデフォルトとすることを重視します。デザインクリティークは、作業をより強くする生産的な対立の場を作ることで、両方の原則を体現します。

デザインクリティークは、Product Designer が厳密で建設的なフィードバックを交換し、作業の質を高める専用セッションです。前提に挑戦し、標準的なデザインレビューを超えて、デザイン決定の根底にある根拠を吟味します。

利点:

• 具体的で実行可能なフィードバックを通じて、デザインを卓越性へ押し上げ、顧客にとっての全体的な品質と価値を高める
• 建設的な挑戦が評価され、期待される文化を構築する
• より深い議論を通じて、プロフェッショナルの成長とデザインクラフトを加速する
• デザインプロセスの早期で問題や不整合に対処する
• デザインシステム、他のプロダクト領域、UX パラダイムとの調整
• ユーザー中心の思考が前面に保たれるようにする

私たちは慈悲深く radical candor を実践し、個人として気にかけながら直接的に挑戦するという、バランスの取れたデザインクリティークアプローチを優先します。効果的なクリティークの実施方法を以下に示します。

1. 作業の準備: 初期コンセプトでも洗練された作業でも、厳密なフィードバックから恩恵を受けるデザインを選択します
2. クリティークセッションを構造化:
   • 徹底したコンテキストを提供: 顧客の問題、制約、なされたデザイン決定、特にクリティークが欲しい領域を共有します。挑戦してほしい側面を明確にします (5 分)
   • 過度な説明なしに作業を提示することから始めます (10 分)
   • 参加者が明確化のための質問をしたり、クリティークを提供したりするのを許可します (セッションの大部分)
   • 重要なポイントと次のステップをまとめます (5〜10 分)
3. 効果的に参加:
   • 「〜したことがある？」「これはどうやって…?」「なぜこれは…?」のような質問をして好奇心を持ち、デザイン決定を理解します
   • 提案者を励まし、挑戦し、ブロックを解くような具体的で詳細なコメントを提供します
   • フィードバックを個人的な好みではなく、ユーザーニーズとビジネスゴールに結びつけます
4. クリティークを生産的に受け取る:
   • 応答する前にオープンに聞きます
   • 詳細なメモを取り、必要に応じて明確化のための質問をします
   • 具体的で挑戦的なフィードバックに対し、参加者に感謝します
5. 文書化とフォローアップ:
   • 重要なクリティークポイントを関連 Issue やエピックでキャプチャします
   • 後続のイテレーションで、クリティークがデザイン決定にどう影響したかを共有します
   • 意味のある改善につながったクリティークを行ったチームメンバーを認めます

正しいマインドセットを設定する

クリティークセッションが心理的安全と誠実なフィードバックの両方を維持できるよう、ファシリテーターは開始前に行動規範を参照し、マントラを声に出して述べることを強く推奨します。

行動規範

クリティークセッション中、私たちは以下を約束します。

1. デザイナーではなくデザイン作業に焦点を当てる
2. 敬意を持ってコミュニケーションし、不快な言動を避ける
3. 個人として気にかけていることを示しながら、直接的に挑戦する
4. 曖昧なコメントではなく、具体的で実行可能なフィードバックと理由を提供する
5. クリティークを行う前に、デザイン決定を理解する純粋な好奇心を持つ
6. さまざまな視点とアプローチにオープンであり続ける
7. クリティークをオープンに受け取り、うまくいかない要素を手放す意思を持つ
8. クラフトへの情熱を持って率直な会話と活発な議論に参加する

デザイン原則とアプローチ

Sophisticated simplicity（洗練されたシンプルさ）

私たちは、最適なユーザー体験を生み出すために 3 つの原則のバランスを取る sophisticated simplicity（洗練されたシンプルさ） を目指します。

1. 構造 (Structure) - コンテンツとコンセプトを意味のあるグループとパターンに整理・配置する
2. 発見 (Discovery) - 学習と熟達を促進しつつミスを最小化する方法で、ユーザーが対話・探求できるようにする
3. 能力 (Capability) - ユーザーがタスクを完了し、プロセスを自動化できる機能を提供する

これらの原則のバランスは重要です。

• 構造 + 発見、能力なし: 静的コンテンツに適したシンプルな体験だが、機能的豊かさに欠ける
• 発見 + 能力、構造なし: 堅牢で興味深い体験だが、導く構造がないため習得が困難
• 構造 + 能力、発見なし: 洗練された複雑さ - 機能は豊富だが、ユーザーは学習と理解に苦労する

sophisticated simplicity を達成することで、基本機能へのアクセス摩擦が減り、強力な機能への素早いアクセスを提供し、ユーザーがタスク完了に習熟するのを助けます。

デザイン時に検討すべき質問:

• コンテンツの階層とフローは明確か？
• 類似アイテムがグループ化され、グループが明確に定義されているか？
• このコンテンツや機能は、常時、すべての人に表示する必要があるか？
• このコンテキストにおいてこのコンテンツや機能は必要か？ 役立つ かつ 不可欠か？
• 発見は、ユーザーがミスを避けたり、容易に回復したりするのに役立つか？
• 構造は発見と高度な機能の使用をサポートするか？
• この機能や能力は必要・使用されているか？ 削除されたら何が起こるか？
• すべてが「手の届く範囲」にあるか、それともユーザーは迷子になっているか？

モードでのデザイン

デザインは、現在ライトモードとダークモードを含む一般提供されているすべてのモードで機能する必要があります。デザイン時には以下の考慮事項を念頭に置いてください。

• ライトモードはプロダクトで最もよく使われるモード設定で、Pajamas UI Kit デザインアセットのデフォルトであり、ユーザビリティテスト のデフォルトです
• デザインシステム は、サポート対象モードで機能するデザイントークンとコンポーネントを提供します
• モードが顧客の成果における主要要因の場合は、特に注意を払います
• 分析データを使用して、どのモードを主要なデザイン焦点とすべきかを判断します

ダークモードのデザイン原則:

ダークモードデザインは、以下の原則に沿っている必要があります。

• 前面の要素は明るく、後退する要素は暗く: これは自然光の挙動を模倣します。ダークモードでは、明るい要素が深みを生み、重要なコンテンツが境界線や影に大きく依存することなく目立つようにします
• 彩度を下げる: 暗い UI では色は自然に目立ちます。背景に色を溢れさせるのではなく、必要な箇所に注意を引くため色を選択的に使用します
• 反転ではなく、薄暗く: ダークモードは、インターフェイスを完全に反転させるのではなく、明かりを薄暗くする感覚であるべきです。コンテンツの明瞭さを維持するため、どの要素を暗くし、どれを明るくするかを慎重に決定します

デザイントークンとモード固有のコンポーネントについては、Pajamas デザインシステム を参照してください。

追加のデザインガイダンス

• AI デザイン: AI を活用した機能のデザインには AI デザインガイド に従ってください
• デザインモード: ライトモードとダークモードのデザインガイダンスについては Figma とデザインツール を参照してください
• デザイン原則: Pajamas のデザイン原則 全体をレビューしてください

Technical Writer とのパートナーシップ

Technical Writing は、Upstream Studios 内で Product Design と並ぶ中核的な職能です。私たちの言葉はプロダクト体験を形作り、デザイナーとライター間のコラボレーションが、提供する完全なスタックを強化します。

UI テキストを追加または変更する際は、グループの Technical Writer との協力が不可欠です。このコラボレーションは、プロダクト デザインフェーズ 中に始めるべきです。

UI テキストには、ボタンやメニューのラベル、エラーメッセージ、ログファイル、ユーザー支援のマイクロコピー、通知メール、その他 UI に表示されるあらゆるテキストが含まれます。UI テキストの変更は、ドキュメントの手順に大きな影響を与える可能性があります。

スムーズなプロセスを確保するために:

• Issue と MR にラベル付け: UI text と documentation ラベルを適用します
• レビューを依頼: デザイン Issue で グループの Technical Writer にメッセージを送り、レビューを依頼します。レビューするファイルや行、コンテキストをプレビューまたは理解する方法を指定します
• テキストの最終決定で協力: Technical Writer と密に連携し、UI テキストが使いやすく正確であることを確認しながら最終決定します
• 他部門のフィードバックを取り入れる: 他部門が UI コピーに意見を提供する場合、広範な修正やデザイン・バイ・コミッティーを避けるため、具体的なテキストではなくゴールを尋ねます

プロダクト内参照情報での協力

デザイナー、PM、Technical Writer が、追加の プロダクト内参照情報 を ドロワーコンポーネント で表示することに合意することがあります。参照情報は、機能の既存ドキュメントと整合させる必要があります。

1. コピーの下書き: デザイナーはドロワーのコンテンツを下書きし、ユーザーゴールに必要な情報を特定します。この下書きは可能な限り最終版に近いものにすべきです
2. 下書きステータスをマーク: ドロワーコンテンツが最終ではないことを示すため、「ドキュメント待ち」「下書き」「プレースホルダー」のようなテキストウォーターマーク、または Figma ファイルのピンを使用します
3. デザインから開発のプロセスに従う:
   • 開発者は機能コード MR の一部としてドロワーとドキュメントを作成します
   • Technical Writer がドキュメントとドロワーコンテンツをレビューします
   • ドキュメントが公開されると、ドロワーにコンテンツが入力されます

UX Researcher とのパートナーシップ

UX Research は、Upstream Studios 内で Product Design と並ぶ中核的な職能です。リサーチはデザインに情報を提供し、私たちが何を作るかを駆動し、すべての体験がユーザー理解に基づくことを確保します。

UX Researcher は、Product Manager や Product Designer と協力し、リサーチプロジェクトが対象を絞り価値ある洞察を提供することを確保します。

• UX Researcher に連絡: リサーチを実施または導くために UX Researcher に連絡します
• 発見事項を文書化: 確立されたプロセスに従ってリサーチの発見事項を文書化することを確保します

作業を共有する

デザイン作業を共有することは、Product Designer が GitLab 内外の同僚にメンタリングし、関与し、インスピレーションを与えることを可能にします。視点が広がり、デザイン決定がプロダクトに与える広範な影響を理解する助けとなります。

社内での共有:

• Slack: 洞察と更新を共有
• Unfiltered YouTube: 更新の提供とフィードバックの収集
• Upstream Forum: 同じ目的や JTBD に取り組むチームとのコラボレーション経路を開く

社外での共有:

• ブログ投稿: デザイン決定とプロセスについて執筆
• イベント／カンファレンスでの登壇: 作業と洞察を共有

これらの活動は、他のデザイナーにインスピレーションを与えるだけでなく、Upstream Studios の可視性を高め、透明性を向上させ、潜在的な応募者を引き付けます。

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