authentic-product-representation

本物の製品を忠実に表現する

訪問者の信頼を最も早く失うのは、明らかに演出された製品ビジュアルです。人々は何千ものランディングページを見てきており、作り物のダッシュボード、Lorem Ipsumだらけのスクリーンショット、本物のツールでは決して表示されない内容を出力する「ターミナル」を見抜きます。成果につながるビジュアルとは、実際に動作している製品をそのままスクリーンショットにしたように見えるものです。実際にそうしたものか、見分けがつかないように作られたものです。

原則はシンプルです。**ビジュアルは製品そのものであり、製品のポスターではありません。**そこから外れる近道はすべて、つまり作り物のデータ、装飾的なクローム、存在しない機能の表示は、信頼という口座から少しずつ引き出す行為です。

このスキルが扱うのは、ビジュアルに信頼性があるかどうかです。ページの訴求においてビジュアルが果たすべき役割については、[[layout-paradigms-and-consistency]]の製品ナラティブフレームワークを参照してください。作り物の証拠が何かを証明することはありません。

---

実際のコンテンツでデザインする

理想化されたプレースホルダーコンテンツでは、実際のデザインが直面する問題を隠してしまいます。

• **Lorem Ipsumは使わないでください。**実際のコピー、またはそれに最も近い草稿を使います。実際の言葉には実際の長さがあり、実際の行折り返しがあり、厄介な境界ケースもあります。ラテン語のダミーテキストは、実際のコンテンツにはないほど一様に整っています。
• 実際の名前、実際の数字、実際の長さを使います。「John Smith / $1,234」は架空のデータセットです。現実的な範囲で最も長い名前、アイテム数が0のアカウント、3行に折り返されるタイトルを使います。完璧なデータでしか見栄えがしないなら、デザインはまだ完成していません。
• **空、読み込み中、エラー、オーバーフローの状態もデザインします。**これらも通常の成功パスと同じく製品の一部です。常に完全で完璧な状態しか表示しないスクリーンショットは、実在しない製品を売り込んでいます。

本番データをどうしても使えない場合は、実際のスキーマと実際のレンダラーからモックを生成し、出荷されるものと形状、書式、制約が一致するようにします。

---

実際の出力を再現する

製品が生成するもの（CLIの実行結果、生成ファイル、レポート、チャート、エディターなど）をビジュアルで示す場合は、よりきれいに解釈し直すのではなく、実際の形式を再現します。

• 製品で実際に使われている出力構造を使います。同じラベル、同じ順序、同じツリー／ログ／テーブルの形、同じ省略ルール（「+4 more」）にします。
• 可能であれば、実際の実行結果から値を取得します。ビジュアルでyourdomain.comを処理すると謳うなら、別のサイトの値を付け替えるのではなく、yourdomain.comを処理したときに実際に得られる結果を表示します。
• 実際のレンダリングコンポーネントがあるなら、それを再利用します。製品の変更ですぐに実態とずれてしまう手作りのそっくりな見た目より、忠実な埋め込みのほうが優れています。
• 幅広さは、主張するより見せるほうが説得力があります。ツールがすでに対応している実際のカテゴリ（「ほかにも：ボーダー、シャドウ、モーション、コンポーネント」）を列挙すれば、対応範囲を正直に伝えられます。すでに存在する機能を「近日公開」と予告すれば、逆の印象を与えます。

解釈し直したモックは、保守上の負担であり、信頼性を損なうリスクでもあります。誰かが製品と比較するまでは、製品そっくりに見えるからです。

---

真実を保つ

ビジュアルは主張を伝えます。その一つひとつが事実でなければなりません。

• **数字は現実を反映させます。**統計、件数、指標は実際の値か、明確に例示とわかる値にします。事実であるかのように見せる、誇張された作り話は使いません。
• **ラベルと内容を一致させます。**あるものを別のものに見せかけてはいけません（システムAのスクリーンショットにシステムBのキャプションを付ける、コマンド内のドメインと表示結果が一致しない、など）。
• **実際に備わっている機能だけを見せます。**製品にない機能を実行するデモは、初めて使われたときに破ることになる約束です。
• **「近日」は本当に近日である場合に限り、その表示が適切なことはほとんどありません。**すでに提供中のものに「保留中／近日公開」のバッジを付けるのは嘘です。実際のロードマップ項目に付ける保留中のバッジも、製品画像ではたいてい余計なノイズになります。動作するものを見せることを優先してください。

捏造したマーケティング風の装飾を避ける

ひと目で「実際の製品をスクリーンショットしたもの」ではなく、「印象的に見えるよう生成されたもの」とわかる視覚表現があります。それは AI 生成の粗悪なコンテンツのように見え、築こうとしている信頼性を損ないます。

避けるもの：

• 架空のダッシュボード、偽のグラフ、マーケティング文句を表示する装飾的な「ターミナル」
• 内容の代わりに使われる、グラデーション文字、きらめきや星のアクセント、オーロラのような発光、グラスモーフィズム
• 実際の機能がないタイプライター風・ローテーション式の見出しや、見せかけの AI 風装飾（スキャンライン、「思考中」を示すきらめきなど）
• 空間を埋めるだけのピル型バッジや装飾。特に、媒体にそぐわない場所で使うもの（例：等幅フォントの出力に置かれたラベルチップ）

節度を見極める基準：実際の製品に存在しない要素は、実際の製品を表すビジュアルに含めるべきではありません。情報を伝えない装飾は、まず削る対象です。

---

演出が必要な場合

文字どおりのスクリーンショットを用意できないこともあります（リリース前、機密データ、複数画面の合成など）。その場合は、誠実に演出してください。

• 実際のスキーマ、実際のコンポーネント、現実的な値を基に作成します。
• 目立たない状態も含め、製品の実際の状態と書式に合わせます。
• 主張は控えめにします。ビジュアルでは期待を控えめに示し、製品でそれを上回るようにします。
• 説明用の数値は、測定値であるかのように見せず、説明用であることを明記します。

---

色付きの背景に写真を配置する場合

色付きのタイルに製品写真を載せる場合は、背景を透過した切り抜き画像が必要です。背景が白く塗りつぶされた写真を色付きの背景に載せると、白い四角形が見えてしまいます。切り抜き画像がない場合は、写真をタイルに乗算合成して白い部分を消します。

デザインの書き出し画像と、そのデザイン自体のスクリーンショットが一致しない場合は、スクリーンショットを優先します。書き出し画像はファイルに対するツールの見解です。実際の表示が、リリースされたものです。

---

レビューチェックリスト

• lorem ipsum や、明らかに理想化されたプレースホルダーの内容が残っていませんか？（残っていてはいけません。）
• 長い名前、空のリスト、3 行のタイトルなど、現実的な長さの内容を使っていますか？
• 空、読み込み中、エラー、オーバーフローの各状態も表現されていますか？ 完璧な状態だけになっていませんか？
• ビジュアルが製品の出力を代わりに示す場合、実際の形式、並び順、省略方法と一致していますか？
• 値は表示されている入力に対応していますか（正しい分野、正しい情報源）？ 別のケースのラベルだけを差し替えたものではありませんか？
• 実際の表示コンポーネントがある場合、手作りの模倣ではなく、それを再利用していますか？
• 色付きの背景に置く製品写真には、背景を透過した切り抜き画像、または乗算合成を使っていますか？
• 数値、ラベル、機能に関する説明はすべて正確ですか？ 誇張、誤表示、未実装のものはありませんか？
• すでに提供されているものに「近日公開」といった表現を使っていませんか？
• 削除すべき、捏造したマーケティング風の装飾（偽のダッシュボード、グラデーション文字、きらめき、装飾的なターミナル）はありませんか？
• 訪問者が実際の製品のスクリーンショットを撮ったとき、このビジュアルと同じ印象を受けるでしょうか？ そうでない場合、なぜでしょうか？