プロトタイピング完全ガイド：アイデアを素早く形にする実践手法

2026年10月8日にGOV.UKのMaking prototypesとmoderated usability testing、Adobe XD FAQ、Figma prototyping guideを再確認した。紙・クリック・必要範囲のコードを問いに合わせ、本番へ転用する条件を分け、対象と課題を決めて答えを教えず観察と介助を区別する。Figmaのフローは開始点と接続を持つが、実画面クリック、契約別権限、認証、本番の安全を確認したことにはならず、旧10倍・30%・25%の効果数値は採用しない。

プロトタイプは、まだ分からないことを確かめるための試作品です。完成品のように見せることより、どの判断に使うかを決める方が先です。紙、クリックできる画面、必要範囲のコードには、それぞれ確かめやすいことと残ることがあります。

30秒で要点

• 確かめる問いに合わせて、必要な精度と操作だけを作ります。
• 答えを教えない課題で、操作と介助、迷った理由を記録します。
• 小さな観察を市場の成果に読み替えず、本番の安全性や性能は別に確認します。

どの疑問に答えるかを先に決める

「使いやすいか」だけでは、何を作り何を観察するか決まりません。「注文確定前に送料を確認できるか」「管理者と一般利用者の操作範囲を理解できるか」など、具体的な場面へ分けます。

表が収まらない場合は、横にスクロールできます

中・高忠実度といった呼び方に唯一の境界はありません。見た目を整えるほど常に良いわけでもなく、未確定の内容を完成したものと誤認させる場合があります。確かめる問いと、まだ作っていない部分を共有してください。

GDSのプロトタイプの資料は、紙からコードまで、必要に合う形を選ぶことを説明しています。現実的な操作を確かめたい場合はコードが役立ちますが、そのコードをそのまま本番へ転用できるという意味ではありません。

ECの注文確認を試す仮想例

ECサイトなら、架空の商品、送料、支払条件を用意し、「必要な費用を確認し、注文を確定する直前まで進んでください」といった課題を作れます。実際の支払や個人情報の入力をさせる必要はありません。

観察するのは、必要な費用を見つけたか、最終操作の意味を理解したか、どこで介助が必要だったかです。「この送料欄を確認してください」のように答えを教えると、見つけられるかの確認にはなりません。操作を止めた場合も、試作品の未実装が原因か、説明が原因かを分けます。

ここで得た結果から実店舗や公開サイトの売上が30%増えるとは言えません。次にどの説明や操作を直し、何を再観察するかの判断材料にします。

紙三画面から観察と改訂までを一巡する

同じECの問いを、担当者がその場で試せる手順へ落とします。扱う商品と値段はすべて架空とし、カード番号や住所など実際の情報を集めません。目的は注文を発生させることではなく、「確定前に費用と内容を把握できるか」を確かめることです。

1. 三枚に、必要な情報と状態を書く

表が収まらない場合は、横にスクロールできます

紙の裏には画面ID、版、観察したい問いを記します。Bへ戻った場合は同じ仮の選択が残る、Aへ戻って数量を変えた場合は後続の合計も作り直す、という状態の約束も担当者間で決めます。今回は数量1だけを対象にするなら、その制限を先に共有し、未実装の挙動を利用者の失敗と数えません。

2. 開始点、遷移、戻りを通してみる

進行役とは別の担当者が、指示された操作に合わせて紙を差し替えます。A→B→CだけでなくC→B、B→Aも試し、費用の内訳が途中で消えないか、戻る操作で何が変わるかを確認します。これは試行の準備点検で、参加者の評価結果には含めません。

クリックできる版へ移す場合も、この画面IDと遷移の表を設計書として使います。開始点をAに定め、前進と戻りを接続し、未実装の確定操作には説明を残します。Figmaなどの現UIのボタン位置や契約ごとの共有権限は、この手順だけで確認済みとはしません。利用時に公式資料と実際の権限で確かめます。

3. 共有する範囲と課題をそろえる

試作品には「注文・支払は発生しない確認用」と表示し、共有相手、版、対象端末、未実装の機能を伝えます。参加者には「この商品を一冊買うつもりで、必要な費用を確認し、注文を確定する直前まで進んでください」と伝えます。「Cに合計がある」とは教えません。

紙とクリック版で入力できる範囲が違えば、同じ条件の試験だったと扱わないでください。録画や発言記録を取る場合も、その用途と扱いを説明してから始めます。実際の購入意欲や支払能力を評価する課題ではありません。

4. 発言と操作、介助を分けて記録する

表が収まらない場合は、横にスクロールできます

「送料を嫌がった」「購入率が低い」といった心理や市場成果は、このメモだけでは分かりません。必要なら操作後に理由を開かれた質問で聞き、本人の説明と担当者の推測を分けます。

5. 改訂点を絞り、次の観察へ渡す

この架空例では、まずAの価格付近に「送料は次画面で確認」と明示する案を試します。版をv1からv2に変え、変更理由、変えた箇所、次の課題を記録します。Cの戻り先も同時に変えたなら、その事実を残し、変化を一箇所の効果に帰属させません。

同じ参加者が二回目には場所を覚えている可能性もあります。初見の分かりやすさを確かめるなら、別の対象者を含めるか、再参加という条件を明記します。改訂後も費用の内訳と戻る操作を観察し、理解できたこと、まだ不明なこと、本番で別に検証することを引継ぎ票へ残して一巡です。

SaaSの権限操作を試す仮想例

SaaSでは、管理者と一般利用者で見える画面や許される操作を分けた試作品が役立つ場合があります。たとえば架空のメンバー招待と、権限変更の確認画面を対象にします。

参加者が操作できたとしても、本番のアクセス制御が実装された証拠にはなりません。画面の説明と、サーバー側の権限判定は別です。削除や権限拡大など影響の大きい操作は、試作品の見え方の確認後も本番条件で検証します。

道具は操作、共有、引継ぎの条件で選ぶ

表が収まらない場合は、横にスクロールできます

Figmaの公式ガイドは、フレームをつなぐフローや開始点、操作、共有を説明しています。旅程全体だけでなく、一部分の流れを試すこともできます。実際に使う権限や契約、対象端末での条件は利用時に確認してください。 Adobe XDの公式FAQでは保守モードが案内され、新機能開発と既存利用者への不具合・安全面の対応を区別しています。サポート終了と同じ意味にはしません。製品名を固定のおすすめ順位にせず、今回の問いに必要な機能と提供条件を確認します。

命名や共有では、対象の場面、版、確認したい問い、まだ動かない部分を明示します。画面名だけでは、どの仮説を検証したか分からなくなります。試作品が実サービスだと誤認されないよう、アクセス範囲と説明を用意してください。

誘導しない課題と観察記録を作る

実際の、または想定される利用者が行う場面を設定します。使い方を説明してから試すのか、初見で確かめるのかも区別します。参加者に不必要な個人情報を求めず、観察や記録の扱いを事前に説明します。

GDSの進行役付きユーザビリティテストの資料では、調べる問いや対象者を決め、信じられる状況の課題を用意することを扱っています。操作の答えを含めず、必要な時は開かれた質問で事情を聞きます。

表が収まらない場合は、横にスクロールできます

五回の観察と市場の率を区別する

架空の5セッションで、自力完了3、介助あり1、未完了1だったとします。3＋1＋1＝5です。自力完了3÷5＝60%は、この条件で行った5回の観察の記述です。市場全体のCVR、成功率、改善の因果効果とはしません。

人数だけで十分性を決めず、対象者の違い、課題、残った問題の影響を確認します。重要な利用者や補助技術、端末条件を確認していなければ、その限界を残します。解決案を試しても、別の問題が増えていないか再観察が必要です。

本番へ進む前の別の確認

試作品で理解できたことと、本番で安全に動くことは別です。認証、権限、個人情報、性能、アクセシビリティ、障害時の対応を本番の条件で確認します。GDSの資料も、試作用コードを無条件で本番へコピーしないよう注意しています。

次の判断は、作り込む、別案を試す、課題や対象を見直す、実装へ進む、のいずれもあり得ます。観察された問題と採用した理由を残し、Web制作の進め方、設計全体の整理、アクセシビリティへつなげてください。