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