プロトタイピングを依頼するとき、最初に伝えるべきことは「仕様」ではない──外部パートナーとの初回ブリーフィングを成功させる3つの準備

「画面イメージがあるので、これをプロトタイプにしてほしい」

外部のプロトタイピングパートナーに最初に依頼するとき、こうした伝え方をしてしまうケースが非常に多くあります。ワイヤーフレームがある、スケッチがある、競合サービスのスクリーンショットがある──何らかのビジュアルを手に、「これを作ってください」という依頼から始めてしまうのです。

しかし、この入り口は、プロトタイピングを失敗させる典型的なパターンです。

システム開発やデザイン制作の依頼であれば、仕様や画面イメージを伝えることは正しいアプローチです。作るべきものが決まっていて、それを形にすることが目的だからです。

しかし、プロトタイピングの目的は「決まっているものを作ること」ではなく、「仮説を検証すること」です。

仕様を渡されたパートナーは、その仕様通りに作ることに集中します。その仕様が「正しい問いに答えているか」を考えることは、依頼の範囲に含まれていません。結果として、完成したプロトタイプは「作ったもの」にはなりますが、「検証できるもの」にはなりません。最初のブリーフィングで伝える内容がずれていると、どんなに優秀なパートナーでも、正しい方向には進めないのです。

では、何を伝えるべきでしょうか。外部パートナーとのブリーフィングで最初に共有すべきは、以下の3点です。

① 検証したい仮説（「何を確かめたいのか」）

「このサービスは使ってもらえるか」という問いは、仮説としては漠然としすぎています。プロトタイピングで検証できる仮説は、もっと具体的です。たとえば「仕事の終わりに通知が来たとき、このフローなら3ステップ以内に目的を達成できると感じるか」「価格を見る前に、このサービスに価値を感じてもらえるか」といった、ユーザーの具体的な反応や判断を問う形に絞り込まれているものです。

仮説が絞り込まれていると、パートナーはプロトタイプに含めるべき要素と、省略できる要素を明確に判断できます。検証範囲が広すぎると、作るものが増え、時間もコストもかさみ、それでいて検証の精度は下がります。

② 想定するユーザー（「誰のための体験か」）

「新規事業の担当者」「30代のビジネスパーソン」といった属性情報より、「今どんな課題を抱えていて、どんな行動をしている人か」というコンテキストで伝えることが重要です。

ユーザーの解像度が低いと、プロトタイプのUIや言葉遣い、情報の粒度が「誰向けか」を見失います。逆に、ユーザー像が具体的であるほど、パートナーは「このユーザーなら、このシーンでどう感じるか」を考えながら設計できます。

③ 使われる場面・状況（「どんなコンテキストで使うか」）

プロトタイプは、「机の上で落ち着いて使うもの」と「移動中にスマートフォンで使うもの」では、設計が根本から変わります。使われる場面・デバイス・前後の行動を伝えることで、パートナーはプロトタイプに再現すべき「文脈」を理解できます。

これを伝えずに「スマートフォン対応で」とだけ言うと、デザインは対応していても、実際のユーザー体験とは乖離したプロトタイプが生まれます。

ここまで読んで、「検証したい仮説を言語化することが、そもそも難しい」と感じた方もいるのではないでしょうか。

それは、プロセスとして正常です。新規事業の初期フェーズでは、「何を検証すべきか」自体が不明確なことが多くあります。むしろ、仮説の言語化が難しい段階で外部パートナーに相談することに、大きな価値があります。

優れたプロトタイピングパートナーは、仮説の整理から一緒に入ります。「作る前に考える」フェーズをパートナーと共にやることで、何を作るかの解像度が上がり、プロトタイピング自体の精度も向上します。「仕様が固まってから依頼する」のではなく、「仮説を固めるところから依頼する」というスタンスが、プロトタイピングの本来の使い方です。

プロトタイピングは、最初のブリーフィングの質に大きく左右されます。何を作るかよりも、「何を検証するために、誰のために、どんな場面で使うものを作るのか」が明確であるほど、パートナーは本質的な設計に集中でき、結果として有効な検証につながります。

最初に仕様を渡すのではなく、仮説・ユーザー・コンテキストを伝える習慣を持つことが、外部パートナーとのプロトタイピングを成功させる出発点です。

もし「仮説の整理からサポートしてほしい」「ブリーフィングの段階から一緒に考えてほしい」という方は、Concretoのプロトタイピングパートナーサービスにご相談ください。検証設計から実装まで、プロジェクト全体を伴走します。