Product Designer のワークフロー

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

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

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

Product Designer は、早期の協働、ユーザー中心の思考、継続的な検証を重視する、戦略的かつ反復的なプロセスに従います。戦略的パートナーとして、私たちは最初から関わり、すでに行われた意思決定を単に実行するのではなく、方向性を形作ります。

機会を定義する

まず、PM と協働して、誰が、何を、なぜ、を検証します:

• 誰のためにデザインするのか、何をデザインするのか、なぜデザインするのかを検証する
• ユーザーが達成しようとするジョブとその周辺のコンテキストを理解する ジョブ理論（JTBD）として、PM がこれを明確に表現できるよう支援する
• エビデンスに基づかない「どのように」を実装するよう求められた場合は、PM が誰が、何を、なぜ、に焦点を戻し、最善の方法を協働して決定するよう促す
• 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 に記録し、元の Issue にリンクする
• 確信度が高く、リスクが低い変更: 検証が完了する前に開発者が開始する必要がある場合は、確信度が高く、リスクが低い変更に焦点を当てる
• 先を計画する: PM と Product Designer は協働して、1 〜 2 ヶ月先を行くようにし、Build トラックに常に十分に検証された機会が準備されているようにする
• 大規模な機能を管理する: 機能は 1 〜 2 マイルストーン内で構築可能にする必要がある。大きすぎる場合は、PM および Engineering チームと協働し、より小さく管理可能なセグメントに分割する

インスピレーションを得るには、Product Designer が GitLab におけるイテレーションについて話す様子を視聴してください。

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

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

デザインの判断に関する権限を持つデザイン DRI として、私たちは複数の選択肢ではなく、検証済みの 1 つのソリューションを提案します。代替案を提案すると、委員会方式のデザインにつながり、戦略的パートナーとして私たちがもたらす強い視点を損なう可能性があります。複数のソリューションを提案しなければならない場合は、その理由を明確に説明してください。

コンテキストと目標を非同期で共有する:

• 提案の内容をオーディエンスが理解し、どのように支援できるかを把握できるよう、必要なすべてのコンテキストを Issue に記載する
• ソリューションの対象者、その人が何をできるようになるか、フィードバック、支援、承認のいずれが必要かを明確にし、必要とする人に ping する
• 理解を促すため、前回のレビュー以降の変更を強調する
• 主なポイントから注意をそらさずに補足情報を含めるため、折りたたみコンテンツセクションを使用する

Product Design Manager にフィードバックを依頼する:

フィードバックを得るために、Product Design Manager を @mention します。マネージャーは戦略的整合性を提供し、品質を確保し、プロダクト全体で機能の一貫性を維持できます。

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

デザインの議論は、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 チャンネルにアップロードする。機密でない限り公開設定を「Public」にし、「UX」プレイリストに追加する
6. 参照情報を含むコメントをする: 機能の Issue に動画と、Issue、エピック、Figma ファイルなどの関連する参照情報（例）へのリンクを付けてコメントする。これらのリンクを動画の説明にも追加する
7. Issue にフィードバックを記録する: レビューに必要なすべての参照情報と情報を添付し、フィードバックを記録する専用の Issue（例）を作成する

例:

• 新しいリストのイテレーションを追加する - フィードバック依頼
• スイムレーンボードの読み込み状態 - Skeleton loaders のフィードバック依頼
• 右側の 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 パラダイムと整合させる
• ユーザー中心の思考を最優先に保つ

私たちは、善意あるラディカル・キャンダーを実践し、個人を大切にしながらも直接的に挑戦する、バランスの取れたデザインクリティークを優先します。効果的なクリティークの実施方法は次のとおりです:

1. 作業を準備する: 初期コンセプトでも洗練された作業でも、厳密なフィードバックから恩恵を受けるデザインを選ぶ
2. クリティークセッションを構成する:
   • 十分なコンテキストを提供する: 顧客の問題、制約、行ったデザインの意思決定、特にクリティークを必要とする領域を共有する。どの側面に挑戦してほしいかを明確にする（5 分）
   • 過度な説明をせず、作業を提示することから始める（10 分）
   • 参加者が明確化のための質問をし、クリティークを提供できるようにする（セッションの大部分）
   • 主な学びと次のステップを要約する（5 〜 10 分）
3. 効果的に参加する:
   • デザインの意思決定を理解するために、「〜したことがありますか」、「これはどのように」、「これはなぜ」といった質問をして好奇心を示す
   • 発表者を励まし、挑戦させ、行き詰まりを解消する、具体的で詳細なコメントを提供する
   • 個人的な好みではなく、ユーザーのニーズとビジネス目標にフィードバックを結び付ける
4. クリティークを建設的に受け取る:
   • 応答する前に、開かれた姿勢で聞く
   • 詳細なメモを取り、必要に応じて明確化のための質問をする
   • 具体的かつ挑戦的なフィードバックに対して参加者へ感謝する
5. 記録し、フォローアップする:
   • 関連する Issue またはエピックに、クリティークの主なポイントを記録する
   • 次のイテレーションで、クリティークがデザインの意思決定にどう影響したかを共有する
   • 意味のある改善につながるクリティークをしたチームメンバーを称える

適切なマインドセットを整える

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

行動規範

クリティークセッションでは、私たちは次のことを約束します:

1. デザイナーではなく、デザイン作業に焦点を当てる
2. 敬意をもってコミュニケーションし、攻撃的な言葉や行動を避ける
3. 個人を大切にしながら、直接的に挑戦する
4. 曖昧なコメントではなく、具体的で実行可能なフィードバックと理由を提供する
5. クリティークする前にデザインの意思決定を理解するため、本物の好奇心を実践する
6. 異なる視点とアプローチに開かれた姿勢を保つ
7. クリティークを開かれた姿勢で受け取り、うまくいかなかった要素を手放す意思を持つ
8. 私たちのクラフトへの情熱をもって、率直な会話と活発な議論に参加する

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

洗練されたシンプルさ

私たちは、最適なユーザー体験を作るために 3 つの原則のバランスを取る、洗練されたシンプルさを目指します:

1. 構造 - コンテンツとコンセプトを、意味のあるグループとパターンに整理・配置する
2. 発見 - 間違いを最小限に抑えながら、学びと習熟を促す方法でユーザーが対話し、探索できるようにする
3. 能力 - ユーザーがタスクを完了し、プロセスを自動化できる機能と働きを提供する

これらの原則のバランスを取ることが重要です:

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

洗練されたシンプルさを実現すると、基本機能へのアクセスにおける摩擦を減らし、強力な機能へ迅速にアクセスできるようにし、ユーザーがタスクの完了に習熟する助けになります。

デザイン時には次の質問を検討する:

• コンテンツの階層と流れは明確か
• 類似する項目はグループ化され、そのグループは明確に定義されているか
• このコンテンツまたは機能は、常に、かつすべての人に見えている必要があるか
• このコンテンツまたは機能は、このコンテキストで必要か。役立つだけでなく、不可欠でもあるか
• 発見はユーザーが間違いを避け、または容易に回復するのに役立つか
• 構造は、発見と高度な能力の使用を支えているか
• この機能または能力は必要か、使われているか、あるいは取り除いた場合に何が起こるか
• すべてが「手の届く範囲」にあるか、それともユーザーはさまよわされているか

モードを考慮したデザイン

デザインは、現在ライトモードとダークモードを含む、一般提供されているすべてのモードで機能しなければなりません。デザインする際は、次の点を念頭に置いてください:

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

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

ダークモードのデザインは、次の原則に沿う必要があります:

• 前面の要素は明るく、後退する要素は暗くする: これは自然光の振る舞いを模倣しています。ダークモードでは、明るい要素が奥行きを作り、境界線や影に大きく頼らずに重要なコンテンツを際立たせます
• 彩度を下げる: ダーク UI では、色が自然により目立ちます。背景を色で満たすのではなく、必要な場所に注意を引くために色を選択的に使用します
• 反転ではなく、調光する: ダークモードは、インターフェースを完全に反転するのではなく、照明を落とすように感じられるべきです。コンテンツの明瞭さを保つため、どの要素を暗くし、どの要素を明るくするかを慎重に決定します

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

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

• AI デザイン: AI 搭載機能をデザインする場合は、AI デザインガイドに従う
• デザインモード: ライトモードとダークモード向けのデザインに関するガイダンスは、Figma とデザインツールを参照する
• デザイン原則: Pajamas の完全なデザイン原則をレビューする

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

Technical Writing は、Product Design と並ぶ Upstream Studios のコアディシプリンです。私たちの言葉はプロダクト体験を形作り、デザイナーとライターの協働は、私たちが提供する完全なスタックを強化します。

UI テキストを追加または変更するときは、所属グループの Technical Writer と協働することが不可欠です。この協働は、プロダクトのデザインフェーズ中に開始する必要があります。

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

円滑なプロセスを確保するには:

• Issue と MR にラベルを付ける: UI text と documentation のラベルを適用する
• レビューを依頼する: デザイン Issue で、グループ担当の Technical Writerにメッセージを送り、レビューを依頼する。レビューするファイルまたは行と、プレビューまたはコンテキストを理解する方法を指定する
• テキストの最終化で協働する: UI テキストが使いやすく正確になるよう、Technical Writer と密に協働して最終化する
• 他部門からのフィードバックを取り入れる: 他部門が UI コピーについて意見を提供する場合は、大幅な修正と委員会方式のデザインを避けるため、具体的なテキストではなく目標を尋ねる

プロダクト内の参照情報で協働する

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

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

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

UX Research は、Product Design と並ぶ Upstream Studios のコアディシプリンです。リサーチはデザインに情報を与え、私たちが何を構築するかを方向付け、すべての体験がユーザー理解に根ざすようにします。

UX Researcher は、リサーチプロジェクトの対象が適切で、価値あるインサイトを提供できるように、Product Manager および Product Designer と協働します。

• UX Researcher に連絡する: リサーチを実施または案内してもらうため、UX Researcherに連絡する
• 調査結果を記録する: 確立されたプロセスに従って、リサーチの調査結果が記録されるようにする

作業を周知する

デザイン作業を共有すると、Product Designer は GitLab の内外で同僚をメンターし、関わり、刺激を与えられます。視野が広がり、デザインの意思決定がプロダクトに及ぼすより広い影響を理解するのに役立ちます。

社内での周知:

• Slack: インサイトと更新を共有する
• Unfiltered YouTube: 更新を提供し、フィードバックを収集する
• Upstream Forum: 類似の目標と JTBD に取り組むチームとの協働への道筋を開く

社外での周知:

• ブログ投稿: デザインの意思決定とプロセスについて書く
• イベント/カンファレンスでの講演: 作業とインサイトを共有する

これらの活動は、他のデザイナーを刺激するだけでなく、Upstream Studios の認知度を高め、透明性を向上させ、応募候補者を引き付けます。

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