ビルドプロンプトに実際に必要なものは何か？
4つあります。これは、200件近いプロンプトが完成したサイトへと変わっていくのを見た上での結論です――それが何か、誰のためか、必須要件、そして任意で雰囲気です。それ以外はすべて、どうせビルダーがデフォルトで埋めてしまうノイズです。本当のコツは多く書くことではなく、この4つのうち自分が実際に意見を持っているものだけを見極めて、それだけを言うことです。
まず「それが何か」から始め、仕様ではなくカテゴリに留めましょう。「ヨガスタジオの予約サイト」の方が、「人々が時間を見てボタンをクリックして予約枠を確保し、確認を受け取るサイト」よりも良い結果になります。後者の方が情報量は多いのに、です。カテゴリはビルダーが既に持っているデフォルトを起動します――スケジュールはスケジュールらしく、予約フローは予約フローらしく見えます。一方、説明文はビルダーにカテゴリをゼロから再構築させてしまいます。
対象ユーザーを書く必要はありますか？
必須ではありませんが、多くの人が省いてしまいがちな、省くべきではない一文です。「スタジオの既存の生徒向け」と「初めてスタジオを知る人向け」では、重要な点でほぼ必ず違うサイトができあがります――コピーのトーン、大きなマーケティングヒーローがあるか、それともスケジュールへ直行するレイアウトか、料金を前面に出すか（新規訪問者には必要）、それとも奥にしまうか（常連客はすでに知っている）。この一節が、機能要望の1ページ分よりも、多くの小さな曖昧さを解消してくれます。対象ユーザーが本当に一般的なら、無理に設定せず省いてください。
必須要件はいくつ挙げるべきですか？
2つか3つです。私が使っているテストは、「これが欠けていたら最初のビルドを却下するか？」というものです。「クラススケジュール、オンライン決済、講師プロフィール」はヨガスタジオならこのテストに合格します――スケジュールがなければ、それは縮小版のサイトではなく別のサイトです。「フッターのニュースレター登録」はほとんど合格しません。それはあった方が良い程度のもので、プランを見た後のフォローアップの会話に入れるべきで、重要な項目と競合する最初のプロンプトに詰め込むべきではありません。
正直、これが両方向で最も失敗しやすい要素です。必須要件がゼロだとビルダーは推測し、時には外します。必須要件が8個あると、ビルダーはその8つすべてを同等に重要なものとして扱ってしまい、返ってくるものは機能一覧がウェブサイトの衣装をまとったようなものになります――階層もなく、余白もありません。もしどれか一つの要素だけ省くなと言わなければならないなら、これです。「これを自分らしくする2つのこと」という一節だけでも、ほとんどの場合1往復分の手間を省けます。それは、カテゴリだけからではビルダーが推測しようのない唯一の情報だからです。
雰囲気は指定すべきですか？
指定がある場合だけで構いません。優れたプロンプトの多くはこれを完全に省略していますし、それで問題ありません。デザインディレクターは、あなたが方向性を指定してもしなくても、何らかのアートディレクションにコミットします。二言のムード(「温かみのある手描き風」「無機質でスピーディ」「90年代のアーケードっぽい」)は、そのコミットの方向を、カテゴリのデフォルトに任せる代わりに、あなたが指し示す先に向けさせるだけのものです。強いこだわりがあるなら――クリーム色の背景に温かみのあるセリフ体を使いたい、角丸は絶対に嫌だ、といったこと――その一文に費やす価値があります。ちなみに「クリーンでモダン」はカウントしません。それはムードではなく、ムードの不在であり、スロットを消費するだけで何の方向性も示しません。
考えていることを全部書いてはダメなの?
ビルダーはあなたの指示に従うからです。これが実際の失敗パターンであり、多くの人が予想しないものです――情報が多すぎるとビルダーが混乱するのではなく、あなたが書くすべての文が指示として読まれるのです。もう一度見返せば喜んで削るような、まだ固まっていない考えも含めて。「テスティモニアルのセクション、あってもいいかも、まだ分からないけど」と書いた人が、プレースホルダーの引用文を3つ含んだテスティモニアルセクションを返された場面を私は見てきました。「あってもいいかも、まだ分からない」は人間の読み手にとってはためらいですが、あなたの言葉をそのまま受け取るシステムにとっては機能要求だからです。
情報不足のコストが高いのであれば、これは問題にならないでしょう。人間の開発チーム相手なら実際にそうで、曖昧さのせいで間違ったものが作られたと気づくまでに2週間かかることもあります。しかしここでは違います。ビルダーは構築の前に計画を立てるので――何かがコードにコミットされる前に、具体的な提案を確認できます――情報不足のコストはチャットでの5分の修正で済みます。一方、情報を盛り込みすぎると、あなたがまだ何を残すべきか一番分かっていない段階で、あなたの一番弱い断片的なアイデアをすべて先出ししてしまうことになります。10語の本物の要件は、200語の思いつきの羅列に勝ります。それは情報が抽象的に悪いからではなく、このインターフェースでは特に、余分な一語一語がコミットメントになってしまうからです。
もう一つ、静かなコストがあります。優先順位が失われることです。12個の機能を同じ重みで並べれば、ビルダーはあなたが実際にどの3つを重視しているかの手がかりを得られません。結果として、12個すべてに同じ視覚的重みを与える(ごちゃごちゃになる)か、優先順位を推測する(時には間違い、そして今度はあなたの好みではなく推測をデバッグする羽目になる)かのどちらかになります。3つの必須事項をはっきり述べれば、その優先順位は守られます。段落の中に12個並べれば、それは消えてしまいます。
実際に良いプロンプトとはどんなものか?
| プロンプト | なぜうまくいくのか |
|---|---|
| 「クライマー向けのトレーニングログ――セッション記録、グレード、進捗グラフ。」 | 「何を作るか」に3つの必須事項を加えて、要件全体で10語。対象ユーザーの説明はありません。「クライマーが自分のトレーニングを記録する」というのはカテゴリから自明だからです。ここでは効果のない一要素を正しく省略しています。 |
| 「都市型農業についてのポッドキャストのランディングページ。温かみがあり編集記事風で、エピソード一覧と購読フォームがある。」 | 「何を作るか」、「私のポッドキャスト」から自明な対象ユーザー、ムード、2つの機能。どのプレーヤーでエピソードを埋め込むか、1ページに何件表示するかは書かれていません。それらは最初のプロンプトで決めることではなく、2巡目の質問です。 |
| 「2人プレイのエアホッケーゲーム、本物の物理演算、キーボード1台。」 | ゲームはこのパターンが分かりやすい例です――ジャンルに加えて、実際のプレイ感を決定づけるたった一つの制約。「本物の物理演算」と「キーボード1台」は機能というより、頭の中にあるゲームと同じ感触になるかどうかを決める2つの決定です。テーブルの色、パックの軌跡エフェクト、スコアUIなどはビルダーが提案し、あなたが反応する部分です。 |
この3つに共通するのは、簡潔さそのものが目的なのではなく、すべての単語が役割を果たしていることです。ポッドキャストのプロンプトから「温かみがあり編集記事風」を削れば、ありきたりなポッドキャストページになります。「都市型農業」を削れば、ムードの言葉が向かう先を失います。それがプロンプトの出来を測る本当のテストです――単語数ではありません。無駄なく簡潔だが必須事項をこっそり落としている15語のプロンプトより、すべての節が意味を持つ40語のプロンプトを私は選びます。
すでにブランドカラーや実際の写真がある場合は?
それを添付してください。説明するのではなく。実際のブランドガイドがずっとデスクトップのPDFにあったのに、16進コードに近い言葉でブランドパレットを丁寧に説明する段落を書いている人を私は見てきました――「深い森の緑、少しくすんだ感じの」というように。説明された色はビルダーが再構築しなければならない推測ですが、添付された色はただ正確です。実物のメニュー、実際の写真、ブランド資産――ナレッジと参照機能がそれらを直接ビルドに反映させます。事実の説明よりも、事実そのものの方が常に勝ります。
