プロトタイピング手法

英語名 Prototyping
読み方 プロトタイピング
難易度
所要時間 数時間〜数日
提唱者 エンジニアリング・デザインの実務
目次

ひとことで言うと
#

完成品を作る前に「動く模型」を作り、ユーザーや関係者からフィードバックを得て方向性を確かめる手法。紙のスケッチから高精度のインタラクティブモックまで、目的に応じた精度のプロトタイプを使い分ける。

押さえておきたい用語
#

押さえておきたい用語
ローファイ(Lo-Fi)
紙やホワイトボードで作る低精度のプロトタイプ。方向性の確認に最適。
ハイファイ(Hi-Fi)
実際のデザインに近い高精度のプロトタイプ。最終承認やマイクロインタラクション検証向け。
クリッカブルプロトタイプ
画面をタップ/クリックすると画面遷移する中精度のモック。Figma等で数時間で作成可能。
イテレーション(Iteration)
フィードバックを受けて改善→再テストを繰り返すサイクル。3回が目安。

プロトタイピングの全体像
#

目的定義→精度選択→コアフロー作成→フィードバック改善の流れ
目的を定義何を検証したいかを明確にする方向性?操作性?ビジネス判断?精度を選択目的を達成できる最低限の精度でペーパー→クリッカブル→ハイファイの順コアフロー作成検証したいタスクの5〜10画面に集中仮説を持って作る全画面は不要FB→改善見せる→修正→再度見せるを3回粗い3回が完璧な1回に勝る粗いプロトタイプを3回改善が完璧な1回に勝る
プロトタイピングの進め方フロー
1
検証目的を定義
何を確かめたいかを明確に
2
精度レベルを選択
最低限の精度で十分
3
コアフローを作成
5〜10画面に集中
4
FB→改善を3回
見せて・直して・また見せる

こんな悩みに効く
#

  • 開発に入ってから「思っていたのと違う」と言われる
  • 企画書だけでは関係者にアイデアの魅力が伝わらない
  • ユーザーテストをしたいが、完成品がまだない

基本の使い方
#

ステップ1: プロトタイプの目的と精度レベルを決める

何を検証したいかでプロトタイプの精度を選ぶ。

  • ペーパープロトタイプ(低精度): 紙とペンで30分。アイデアの方向性やフローの確認に。コストほぼゼロ
  • クリッカブルプロトタイプ(中精度): Figma/XDで数時間。画面遷移を確認。ユーザーテストに使える
  • ハイファイプロトタイプ(高精度): 実際のデザインに近いインタラクション。ステークホルダーのGO判断やマイクロインタラクションの検証に

原則: 目的を達成できる最も低い精度を選ぶ。精度が高いほど時間がかかり、フィードバックを受け入れにくくなる。

ステップ2: コアフローに絞ってプロトタイプを作る

全画面を作る必要はない。検証したいタスクフローだけに集中する。

  • ユーザーが最もよく行うタスク(例:商品を検索→詳細を見る→カートに入れる)
  • 仮説を持って作る(例:「チャット形式の注文フローは従来型より完了率が高い」)
  • エッジケースや例外処理は後回しでOK

5〜10画面あれば、1つのタスクフローは十分検証できる。

ステップ3: フィードバックを集めて改善サイクルを回す

プロトタイプは見せるために作るもの。引き出しにしまわない。

  • ユーザーに「〇〇してみてください」と操作させて観察する
  • 「これをどう思いますか?」ではなく「ここで何ができると思いますか?」と聞く
  • フィードバックを受けたら素早く修正し、また見せる

3回のイテレーションを目標にする。1回目は大きな方向修正、2回目は詳細の調整、3回目で確認。

具体例
#

例1:経費申請アプリをコード0行で仕様確定する

目的: 「写真を撮るだけで経費申請が完了する」コンセプトの検証

第1イテレーション(ペーパープロトタイプ、30分):

  • 紙に6画面をスケッチ(カメラ起動→レシート撮影→金額確認→カテゴリ選択→送信→完了)
  • 同僚5人に見せて操作してもらう
  • 結果: 「カテゴリ選択が面倒」「金額が間違ってたら直したい」の声

第2イテレーション(Figmaプロトタイプ、4時間):

  • カテゴリをAI自動推定に変更、手動修正も可能に
  • 金額の編集機能を追加。8画面のクリッカブルプロトタイプを作成
  • 営業部10人にテスト。「これなら電車の中で経費精算できる」と好評

第3イテレーション(4時間で修正):

  • 履歴画面を追加。マネージャーの承認フローも追加
  • 最終テストで全員が3分以内に申請完了

結果: コードを1行も書かずに、ユーザーの望むアプリの姿が明確になった。 開発着手後の仕様変更はゼロ。

例2:BtoB SaaSの新機能をハイファイプロトタイプで経営承認を得る

状況: データ可視化ダッシュボードの新機能に5,000万円の開発投資が必要。経営層は企画書だけでは判断できないと回答。

アプローチ: Figmaでハイファイプロトタイプを2日で作成。

  • 実際のデータを使った10画面のインタラクティブモック
  • ドラッグ&ドロップでグラフをカスタマイズできる操作感を再現
  • 競合ツールとの比較デモも用意

経営プレゼン: 経営層が実際に操作。「これなら顧客に見せられる」と即承認。

結果: 企画書だけでは3ヶ月停滞していた承認が、プロトタイプ2日で即決。 開発チームも完成イメージが明確になり、実装速度が向上。

例3:ヘルスケアアプリの2案をA/Bプロトタイプで比較検証する

状況: 健康記録アプリの入力UIについてチーム内で意見が分かれた。案A「カレンダー型」vs 案B「タイムライン型」。

アプローチ: 両案のクリッカブルプロトタイプをそれぞれ3時間で作成。ターゲットユーザー10名を5名ずつに分けてユーザビリティテスト。

テスト結果:

指標案A(カレンダー型)案B(タイムライン型)
タスク完了率80%100%
平均入力時間45秒22秒
「使い続けたい」回答3/5人5/5人

結果: データに基づいて案Bを採用。 チーム内の意見対立が数字で解消され、議論時間ゼロで次のフェーズに進めた。

やりがちな失敗パターン
#

  1. 最初からハイファイで作る — 時間がかかる上に、「せっかく作ったから」とフィードバックを受け入れにくくなる。まずはペーパーかローファイから
  2. プロトタイプを見せる相手を間違える — ステークホルダーにローファイを見せると「完成度が低い」と思われる。逆にユーザーテストにハイファイを使うと「本物」と思われてしまう。目的に合った精度を選ぶ
  3. フィードバックを全部取り入れようとする — 矛盾する意見も出る。仮説に基づいて「何を変え、何を変えないか」を判断する
  4. プロトタイプを作って引き出しにしまう — 見せなければ価値はゼロ。作ったら24時間以内に誰かに見せるルールを設ける

まとめ
#

プロトタイピングは 「作る前に試す」 を実践する手法。目的に合った精度で、コアフローに絞って作り、素早くフィードバックを集める。完璧なプロトタイプを1回作るより、粗いプロトタイプを3回改善する方が、はるかに良い結果が得られる