prototype

ユーザーは、実際のコードを書く前に反応を確かめるための、使い捨てのプロトタイプを求めています。テキストだけでは決められない見た目、使い心地、フローに関する疑問を解消するものです。

1. 作り始める前に、デザインシステムに基づいてプロトタイプを作成します。モデルのデフォルト設定をそのまま使ってはいけません。汎用的な見た目になるためです。プロジェクトにDESIGN.mdや既存のデザイントークンがあれば、それを使います。ない場合は、まずユーザーに用意してもらいます。DESIGN.md、参考にするサイト、またはfontpairs.coなどの情報源から選んだフォントの組み合わせを指定してもらいます。タイポグラフィ、色、間隔が実際の情報源に基づくまでは、作業を始めないでください。
2. 情報源が既存のDESIGN.mdではなく、参考サイトやフォントの組み合わせである場合は、作り始める前に、決まったトークン（タイポグラフィ、色、間隔）をプロジェクトのDESIGN.mdに書き込みます。プロトタイプの作成後に残すものは、このファイルだけです。implementとrubricはこれを読み込みます。
3. トークンだけでは、見た目の大半は決まりません。look.mdに従い、生成 UI にありがちなデフォルトの傾向と、それに代わる表現を確認してください。
4. リポジトリの外に、自己完結型のHTMLファイルを1つ作成します。ファイルのパスをユーザーに伝え、ブラウザーで開けるようにしてください。
5. ユーザーが反応した時点で止めます。

ルール：

• プロトタイプは見た目だけにします。画面はダミーデータで作成します。バックエンドには接続せず、状態も保持せず、ブランチも作成せず、本番コードにも触れないでください。
• 書く量を減らします。ラベルは短くし、デザイン上必要のない補助テキストや説明は入れません。生成 UI は説明が多くなりがちです。説明しすぎるプロトタイプは、すでに間違っています。
• 方向性が決まっていない場合は、明確に異なるレイアウトをいくつかファイルに用意し、反応を確かめます。洗練された案を1つだけ見せてはいけません。
• 既存のものをコピーします。合わせる対象となる実際のコンポーネントやページのマークアップとトークンを使います。説明するだけではいけません。
• プロトタイプは使い捨てです。方向性を決めるためのものです。ユーザーが選んだら破棄し、その決定を実際の作業に反映します。