プロトタイプ

概要とマーケティングにおける役割

デザインや機能の「試作品」。ワイヤーフレーム(WF / ワイヤーフレーム)（骨組み）よりは具体的で、本番のコード実装よりは簡略化された、検証用モデルのこと。

実際の Web サイトのようにクリックやタップで画面遷移ができる「動くデザインカンプ」のような状態が代表的で、現在は「Figma」や「ProtoPie」等のツールで作成するのが主流。システム開発（コーディング実装）に本格着手する前に、ユーザーテストや社内デモを行うことを目的とする。

現場の核心：手戻りコストの回避

大切なのは、プロトタイプで判断するのは完成度ではなく「方向性が合っているか（体験として正解か）」だという点。

動線・体験・印象を仮の状態で触ってもらい、本実装前に方向性のフィードバックを得る。ここで細部の修正にこだわらず、大枠のズレを無くすのが肝。コーディング（プログラミング）まで進んでから「やっぱりこの機能いらない」「ページ構成を変えたい」という方向性のずれが見つかると、莫大な手戻りコストとスケジュールの遅延が発生する。

実務におけるテスト運用と共有

プロトタイプの「忠実度」は、フェーズに合わせて【Low-Fi（低忠実度：白黒で構造だけを見る）】と【Hi-Fi（高忠実度：色やアニメーションまで精巧に作る）】を使い分ける。

• ユーザーテスト：ペルソナに近い人に実際に操作してもらい（モデレートテスト）、「どこで迷うか」「どこが期待外れか」の生々しい行動を観察する。
• 社内デモ：経営層・現場・関係者に触らせて反応を集める。
• 他部署との要件すり合わせ：SEO・広告・アクセス解析などの各担当者へ「動く画面」を共有し、どのボタンに計測タグを仕込むかなど、改修の前提を具体的にすり合わせる。

やってはいけない「現場の落とし穴」と防衛策

• 細部へのダメ出し（期待値調整の失敗）：社内デモで、経営層が「ほぼ完成形」と勘違いし、「このダミーテキストの日本語がおかしい」「色が薄い」と細部に意見が集中してしまう。（※対策：見せる直前に「本日は動線の確認です。色やテキストは後で変えるので無視してください」と必ず強くアナウンスし、フィルターをかける）。
• 操作時の混乱：デモ用に作っていない「動かないボタン」を経営層が連打して、「バグだ！壊れてるぞ！」と混乱・不信感を招く。
• ペルソナのズレ：ユーザーテストの参加者が実際のペルソナ（ターゲット顧客）と全く違う属性で、検証結果が明後日の方向に偏る。
• 手段の目的化：プロトタイプの作り込み（完璧なアニメーションなど）に時間をかけすぎてしまい、肝心の実装着手（開発）が遅れる。