ひとことで言うと#
完成品を作る前に「動く模型」を作り、ユーザーや関係者からフィードバックを得て方向性を確かめる手法。紙のスケッチから高精度のインタラクティブモックまで、目的に応じた精度のプロトタイプを使い分ける。
押さえておきたい用語#
- ローファイ(Lo-Fi)
- 紙やホワイトボードで作る低精度のプロトタイプ。方向性の確認に最適。
- ハイファイ(Hi-Fi)
- 実際のデザインに近い高精度のプロトタイプ。最終承認やマイクロインタラクション検証向け。
- クリッカブルプロトタイプ
- 画面をタップ/クリックすると画面遷移する中精度のモック。Figma等で数時間で作成可能。
- イテレーション(Iteration)
- フィードバックを受けて改善→再テストを繰り返すサイクル。3回が目安。
プロトタイピングの全体像#
こんな悩みに効く#
- 開発に入ってから「思っていたのと違う」と言われる
- 企画書だけでは関係者にアイデアの魅力が伝わらない
- ユーザーテストをしたいが、完成品がまだない
基本の使い方#
何を検証したいかでプロトタイプの精度を選ぶ。
- ペーパープロトタイプ(低精度): 紙とペンで30分。アイデアの方向性やフローの確認に。コストほぼゼロ
- クリッカブルプロトタイプ(中精度): Figma/XDで数時間。画面遷移を確認。ユーザーテストに使える
- ハイファイプロトタイプ(高精度): 実際のデザインに近いインタラクション。ステークホルダーのGO判断やマイクロインタラクションの検証に
原則: 目的を達成できる最も低い精度を選ぶ。精度が高いほど時間がかかり、フィードバックを受け入れにくくなる。
全画面を作る必要はない。検証したいタスクフローだけに集中する。
- ユーザーが最もよく行うタスク(例:商品を検索→詳細を見る→カートに入れる)
- 仮説を持って作る(例:「チャット形式の注文フローは従来型より完了率が高い」)
- エッジケースや例外処理は後回しでOK
5〜10画面あれば、1つのタスクフローは十分検証できる。
プロトタイプは見せるために作るもの。引き出しにしまわない。
- ユーザーに「〇〇してみてください」と操作させて観察する
- 「これをどう思いますか?」ではなく「ここで何ができると思いますか?」と聞く
- フィードバックを受けたら素早く修正し、また見せる
3回のイテレーションを目標にする。1回目は大きな方向修正、2回目は詳細の調整、3回目で確認。
具体例#
目的: 「写真を撮るだけで経費申請が完了する」コンセプトの検証
第1イテレーション(ペーパープロトタイプ、30分):
- 紙に6画面をスケッチ(カメラ起動→レシート撮影→金額確認→カテゴリ選択→送信→完了)
- 同僚5人に見せて操作してもらう
- 結果: 「カテゴリ選択が面倒」「金額が間違ってたら直したい」の声
第2イテレーション(Figmaプロトタイプ、4時間):
- カテゴリをAI自動推定に変更、手動修正も可能に
- 金額の編集機能を追加。8画面のクリッカブルプロトタイプを作成
- 営業部10人にテスト。「これなら電車の中で経費精算できる」と好評
第3イテレーション(4時間で修正):
- 履歴画面を追加。マネージャーの承認フローも追加
- 最終テストで全員が3分以内に申請完了
結果: コードを1行も書かずに、ユーザーの望むアプリの姿が明確になった。 開発着手後の仕様変更はゼロ。
状況: データ可視化ダッシュボードの新機能に5,000万円の開発投資が必要。経営層は企画書だけでは判断できないと回答。
アプローチ: Figmaでハイファイプロトタイプを2日で作成。
- 実際のデータを使った10画面のインタラクティブモック
- ドラッグ&ドロップでグラフをカスタマイズできる操作感を再現
- 競合ツールとの比較デモも用意
経営プレゼン: 経営層が実際に操作。「これなら顧客に見せられる」と即承認。
結果: 企画書だけでは3ヶ月停滞していた承認が、プロトタイプ2日で即決。 開発チームも完成イメージが明確になり、実装速度が向上。
状況: 健康記録アプリの入力UIについてチーム内で意見が分かれた。案A「カレンダー型」vs 案B「タイムライン型」。
アプローチ: 両案のクリッカブルプロトタイプをそれぞれ3時間で作成。ターゲットユーザー10名を5名ずつに分けてユーザビリティテスト。
テスト結果:
| 指標 | 案A(カレンダー型) | 案B(タイムライン型) |
|---|---|---|
| タスク完了率 | 80% | 100% |
| 平均入力時間 | 45秒 | 22秒 |
| 「使い続けたい」回答 | 3/5人 | 5/5人 |
結果: データに基づいて案Bを採用。 チーム内の意見対立が数字で解消され、議論時間ゼロで次のフェーズに進めた。
やりがちな失敗パターン#
- 最初からハイファイで作る — 時間がかかる上に、「せっかく作ったから」とフィードバックを受け入れにくくなる。まずはペーパーかローファイから
- プロトタイプを見せる相手を間違える — ステークホルダーにローファイを見せると「完成度が低い」と思われる。逆にユーザーテストにハイファイを使うと「本物」と思われてしまう。目的に合った精度を選ぶ
- フィードバックを全部取り入れようとする — 矛盾する意見も出る。仮説に基づいて「何を変え、何を変えないか」を判断する
- プロトタイプを作って引き出しにしまう — 見せなければ価値はゼロ。作ったら24時間以内に誰かに見せるルールを設ける
まとめ#
プロトタイピングは 「作る前に試す」 を実践する手法。目的に合った精度で、コアフローに絞って作り、素早くフィードバックを集める。完璧なプロトタイプを1回作るより、粗いプロトタイプを3回改善する方が、はるかに良い結果が得られる。