コラボレーションモデル
GitLab でのプロダクトデザイン作業は、「ディスカッションのためのデザイン」と「開発のためのデザイン」という 2 つのモードを行き来します。これらのモードは、厳格なプロセスでも、一連のゲートでもありません。トリオ（Product Management、Product Design、Engineering）は、ある時点でその作業が何を目的としているのかを表現し、それに適したツールと忠実度を選ぶために、これらのモードを使用します。トリオの誰もがどちらのモードでも作業を提示できます。誰が作成したかよりも、モードのほうが重要です。
モードを明示することで、何を見ているのかをどのように解釈し、どのような反応をすれば役立つのかが全員に伝わります。対話を始めるためのコンセプトと、構築の準備ができたソリューションには、それぞれ異なる反応が必要です。
トリオの誰もがソリューションを提案できます。重要なのは誰が作成したかではなく、何を目的としているかです。モードを明示することで、何を見ているのかをどのように解釈し、どのような反応をすれば役立つのかが全員に伝わります。対話を始めるためのコンセプトと、構築の準備ができたソリューションには、それぞれ異なる反応が必要です。
2 つのモード
ディスカッションのためのデザイン（発散）
ディスカッションのためのデザインでは、可能性を探り、仮説を検証します。詳細に投資する前に対話を促し、フィードバックを集め、方向性をそろえるためのラフなコンセプトです。ビジョンに関する作業の多くがここに含まれます。
目標は、コンセプトを検証してイテレーションすることです。Customer Zero やデザインパートナーによる検証を通じて、社内の認識をそろえます。これは、幅広く検討してアイデアを生み出し伝える、発散型の思考です。本番コードは収束へと向かわせます。つまり、正しい状態、確立されたパターン、構築可能な詳細を求めます。最初に発散する余地がなければ、チームは最善のアイデアではなく、最初に構築可能なアイデアへ収束してしまう可能性があります。
Figma、FigJam、スタンドアロンのプロトタイプ、開発環境のいずれであっても、最も速く実行できるツールを使用します。成果物は、意思決定ガイド、メンタルモデルのストレステスト、認識をそろえるための図、および／またはプロトタイプになる場合があります。
開発のためのデザイン（収束）
開発のためのデザインは、ソリューションを公開するための作業です。これらは本番環境に対応でき、注釈が付けられ、顧客による検証を経て、実現可能性について Engineering とレビュー済みです。これは収束型の思考です。方向性について認識がそろったため、本番環境に対応できるようにまとめていきます。ここでは、開発環境（GDK／Caproni）でのシームレスな引き継ぎが理想的となり、選ばれたソリューションを洗練して現実のものにします。
モードの選択（およびモード間の移行）
一定規模以上のほとんどのプロジェクト（XL、L、M）は、ディスカッションのためのデザインから始まります。最もよくある質問は、「どの時点でディスカッションのためのものではなくなり、開発のためのものになるのか？」 です。単一のゲートはありませんが、次のテストが役立ちます。
- 方向性が仮説である間は、まだディスカッションの段階です。 問いは 「これは構築すべき正しいものか？」 であり、フィードバックと賛同を引き続き集めています。
- トリオがソリューションについて認識をそろえた時点で、開発へ移行しています。 問いは 「あらゆる状態を含め、構築できるようにするには、どのようにこれを現実のものにするか？」 に変わります。
移行は双方向です。検証セッションが想定外の方向へ進んだ場合でも、制約によって実現可能なことが変わった場合でも、方向性が通用しなくなれば作業はディスカッションへ戻ります。それはプロジェクトの後退ではなく、システムが機能しているということです。
モード別のツール
ツールがモードを決めるのではなく、モードがツールを決めます。
| ディスカッションのためのデザイン（発散） | 開発のためのデザイン（収束） | |
|---|---|---|
| 目標 | 方向性について認識をそろえる。仮説を検証する | 認識をそろえたソリューションを検証し、構築する |
| 思考 | 発散型：幅広く検討し、選択肢を生み出す | 収束型：1 つの方向性を洗練する |
| 忠実度 | アイデアを最も速く伝えられるもの | 本番環境に対応でき、すべての状態が定義された状態へ近づける |
| 一般的なツール | Figma、FigJam、スライド資料、動作するコードプロトタイプ | ドラフト MR、デザイン仕様、注釈 |
| オーナーシップ | Design がトリオとの対話を進行する | Design が体験を、Engineering が本番コードを担当する |
プロトタイピングを行う場所
GDK は、開発のためのデザインに適した環境です。方向性が定まったら、実際のコンポーネントと制約を備えた実際のプロダクト上でデザインすることで、作業を本番環境に対応できるものにします。
ディスカッションの作業には異なる要件があります。それは、考えを変えられるほど速くアイデアを人々に提示することです。実務上の 3 つの違いにより、現時点では軽量なプロトタイプのほうがそこへ至る近道となります。
- 共有とフィードバック。 静的プロトタイプは、誰でも開いてコメントできる URL に公開できます。現在、GDK から派生したプロトタイプは共有やコメントがはるかに難しいため、フィードバックを得るためにかける労力に見合う成果がまだ得られません。組織全体のチームがこのギャップの解消に取り組んでいます。
- セットアップとシードデータ。 デザイナーは多くの場合、達成すべきジョブを対象にデザインします。そのデータ条件をコード上で正確に再現するには、それをプロトタイプとして感覚的に作るよりも、はるかに多くの労力が必要です。
- 発散の速さ。 コンセプト策定では、多くのアイデアをすばやく生み出して破棄します。使い捨てのプロトタイプコードは、人々にインタラクションをすばやく提示し、認識をそろえるための方法です。
a1f3c26a)