この記事の要点（UIXHERO視点） UIXHEROでは、ワイヤーフレームを「構造の設計図」、プロトタイプを「動きの検証モデル」と定義し区別する。 ワイヤーフレームは「何を配置するか」を決め、プロトタイプは「どう動くか」を検証する。
導入：「とりあえずプロトタイプ作って」の危険性
「ワイヤーフレームはいいから、早くプロトタイプ見せて」 「動くものがないと判断できない」
こんな要望を受けたことはないでしょうか。一見もっともに聞こえますが、これは 設計プロセスの順序を無視した危険な要求 です。
ワイヤーフレームなしでプロトタイプを作ると：
- 構造の議論と見た目の議論が混ざる
- 手戻りが大きくなる
- 本質的な問題が後から発覚する
ワイヤーフレームは「骨格」、プロトタイプは「動き」。順序を間違えると、骨格がないまま肉付けすることになる。
ワイヤーフレームとプロトタイプの違い（定義）
ワイヤーフレームは「静的な設計図」であり、プロトタイプは「動的な検証モデル」である。
| 項目 | ワイヤーフレーム | プロトタイプ |
|---|---|---|
| 定義 | 画面の構造・レイアウトを示す設計図 | 実際の操作感を再現した検証用モデル |
| 忠実度 | 低〜中（Lo-Fi） | 中〜高（Hi-Fi） |
| 動き | なし（静的） | あり（インタラクティブ） |
| 目的 | 構造・情報配置の合意 | 操作性・フローの検証 |
| ツール例 | 紙、Figma、Sketch | Figma、ProtoPie、Framer |
語源と背景
ワイヤーフレーム は、建築やプロダクトデザインの「骨組み図」から派生した概念です。Web/アプリデザインでは、視覚的な装飾を省き、構造と情報配置のみを示す図として使われます。
プロトタイプ は、工業デザインの「試作品」から派生しました。デジタルプロダクトでは、実際に操作できるインタラクティブなモックアップを指し、ユーザビリティテストや関係者との合意形成に使われます。
研究からの引用 : 「プロトタイプの目的は、アイデアを検証することであり、完璧なものを作ることではない。失敗を早く、安く経験するためのツールである。」（IDEO）
なぜ重要なのか
1. 議論のフォーカスが異なる
| フェーズ | ワイヤーフレームで議論すべきこと | プロトタイプで議論すべきこと |
|---|---|---|
| 早期 | 「この情報はここに必要か？」 | — |
| 中期 | 「このレイアウトで優先順位は伝わるか？」 | 「この操作は直感的か？」 |
| 後期 | — | 「このアニメーションは適切か？」 |
ワイヤーフレームなしでプロトタイプを見せると、「構造の問題」と「見た目の問題」が混ざり、議論が発散します。
2. 手戻りコストが異なる
| 変更内容 | ワイヤーフレームで変更 | プロトタイプで変更 |
|---|---|---|
| 情報構造の変更 | 数分 | 数時間〜数日 |
| レイアウト変更 | 数分 | 数時間 |
| インタラクション変更 | — | 数分〜数時間 |
構造の問題はワイヤーフレーム段階で潰すべきです。
具体例・ケース比較
ケース1：ECサイトの商品詳細ページ
| 観点 | ワイヤーフレーム | プロトタイプ |
|---|---|---|
| 確認すること | 商品画像、価格、説明、CTAの配置 | カートに入れる操作、画像の拡大、タブ切り替え |
| 成果物 | グレーボックスのレイアウト図 | クリック可能なモックアップ |
| 発見例 | 「レビューがファーストビューに入らない」 | 「カート追加後のフィードバックがわかりにくい」 |
| 修正コスト | 低（配置を変えるだけ） | 中（インタラクションの再設計） |
ケース2：オンボーディングフロー
| 観点 | ワイヤーフレーム | プロトタイプ |
|---|---|---|
| 確認すること | ステップ数、各画面の情報量 | ステップ間の遷移、スキップの動作 |
| 成果物 | 各ステップの画面構成図 | 実際に操作できるフロー |
| 発見例 | 「入力項目が多すぎる」 | 「進捗バーの動きがわかりにくい」 |
| 修正コスト | 低（項目を減らすだけ） | 中（アニメーションの調整） |
ケース3：ダッシュボード
| 観点 | ワイヤーフレーム | プロトタイプ |
|---|---|---|
| 確認すること | ウィジェットの種類と配置、情報の優先順位 | フィルターの操作、ドリルダウン、リアルタイム更新 |
| 成果物 | ウィジェット配置のレイアウト図 | データを切り替えられるモックアップ |
| 発見例 | 「KPIが多すぎて優先順位がわからない」 | 「フィルターの反映が遅いと感じる」 |
| 修正コスト | 低（優先順位を整理） | 高（インタラクション設計の見直し） |
実務でなぜ区別すべきか
UIXHEROがこの2つを厳密に区別する理由は3つあります。
1. ステークホルダーの期待値を管理できる
| 成果物 | 期待されるフィードバック |
|---|---|
| ワイヤーフレーム | 「この情報は必要か」「優先順位は正しいか」 |
| プロトタイプ | 「操作感はどうか」「わかりやすいか」 |
「ワイヤーフレームです」と明示すれば、色やフォントへのフィードバックを避けられます。
2. デザイナーの作業効率が上がる
正しい順序：
- ワイヤーフレーム : 構造を固める（低コスト）
- ビジュアルデザイン : 見た目を作り込む
- プロトタイプ : 動きを検証する
この順序を守れば、構造変更によるデザインのやり直しを防げます。
3. テストの目的が明確になる
| テスト対象 | 適切なテスト素材 |
|---|---|
| 情報構造の妥当性 | ワイヤーフレーム（ペーパープロトタイプ） |
| 操作性・使いやすさ | プロトタイプ |
| 最終的な体験 | Hi-Fiプロトタイプ or 実装 |
忠実度のスペクトラム
ワイヤーフレームとプロトタイプは二項対立ではなく、 忠実度のスペクトラム 上にあります。
| 忠実度 | 名称 | 特徴 | 用途 |
|---|---|---|---|
| 最低 | スケッチ | 手書き、数分で作成 | アイデア出し、初期検討 |
| 低 | Lo-Fiワイヤーフレーム | グレーボックス、テキストのみ | 構造の合意 |
| 中 | Mid-Fiワイヤーフレーム | 実際のテキスト、アイコン | 詳細な情報設計 |
| 中高 | Lo-Fiプロトタイプ | クリック可能、遷移あり | フローの検証 |
| 高 | Hi-Fiプロトタイプ | 実際のデザイン、アニメーション | ユーザビリティテスト |
フェーズに応じて適切な忠実度を選ぶことが重要です。
📌 忠実度と役割の関係 : 「ワイヤーフレーム＝構造」「プロトタイプ＝動き」という役割の違いは明確ですが、制作物の忠実度は連続的です。Lo-Fiプロトタイプもあれば、Mid-Fiワイヤーフレームもあります。大事なのは「今何を検証したいか」を明確にし、それに合った忠実度を選ぶことです。
よくある質問 (FAQ)
Q1. ワイヤーフレームを飛ばしてプロトタイプから始めていいですか？
小規模な改善や、構造が明確な場合はOK です。
ただし、以下のケースではワイヤーフレームを先に作るべきです：
- 新規プロダクト
- 大規模なリニューアル
- 情報構造が複雑
- ステークホルダーが多い
Q2. Figmaでワイヤーフレームもプロトタイプもやっていますが、問題ありますか？
問題ありません 。ツールは同じでも、成果物の目的を区別することが重要です。
- ワイヤーフレームとして使う : 色を使わない、プレースホルダー画像、インタラクションなし
- プロトタイプとして使う : インタラクションを追加、画面遷移を設定
Q3. クライアントがプロトタイプしか見たがらない場合は？
ワイヤーフレームの価値を説明 しましょう：
- 「この段階で構造を固めると、後の手戻りが減ります」
- 「見た目ではなく、情報の優先順位についてフィードバックをください」
- 「プロトタイプは次のフェーズでお見せします」
それでも難しい場合は、Lo-Fiプロトタイプ（グレーボックスだが動く）で対応する方法もあります。
関連リンク
UIXHEROの関連記事
- ワイヤーフレームの書き方 — 実践ガイド
- プロトタイピングツール比較 — Figma、ProtoPie、Framer
- ユーザビリティテストの進め方 — プロトタイプを使ったテスト
- ユーザーフローとジャーニーマップの違い — 設計ドキュメントの使い分け
用語集
ワイヤーフレームは「骨格」——何を配置するかを決める。 プロトタイプは「動き」——どう動くかを検証する。
まとめ
- ワイヤーフレーム : 画面の構造・レイアウトを示す静的な設計図
- プロトタイプ : 実際の操作感を再現した動的な検証モデル
- 使い分け : ワイヤーフレームで構造を固め、プロトタイプで動きを検証する。この順序を守ることで、手戻りを最小化できる。
「とりあえず動くもの」を求める前に、「何を配置するか」を決める。骨格が曖昧なまま肉付けすると、後で大きな手戻りにつながりやすい。