プロトタイプは、プレゼンテーションには出せないものをもたらします。それは「結果」です。ユーザーが選択肢を選び、次の画面に進んで、その結果が自分の想定通りだったかどうかを確かめる。プロトタイプテストは、チームが製品を作り切ってしまう前に、そうしたやり取りを通じてデザインを検証するための手法です。

プロトタイプは紙のスケッチでも、画面同士をリンクさせたモックでも、実際に動くコードでもかまいません。大切なのは、リサーチで確かめたい操作を参加者が実際に試せるかどうかです。デモしかできない美しい画面は議論のきっかけにはなっても、ユーザーが自力でサービスを使いこなせるかどうかまでは教えてくれません。

プロトタイプで何を明らかにしたいか、から始める

たとえば、架空のシェアサイクルサービスで「利用終了（返却）」の流れをリニューアルするとしましょう。検証したい論点は、どこに駐輪できるかかもしれないし、施錠が正しく完了したとわかるか、あるいは追加料金の理由に納得できるかかもしれません。問いによって、リアリティを持たせるべき部分は変わってきます。

ルールの理解度を確かめるだけなら、地図と実践的な駐輪案内があれば十分かもしれません。施錠できたと認識できるかをテストするには、適切なフィードバックと一連の操作の流れが必要です。追加料金への納得感を調べるなら、納得のいく金額と説明が求められます。テストに直結しないアカウント設定などをすべて作り込んでも、手間が増えるだけで検証の質は上がりません。

これこそが、プロトタイプの忠実度（フィデリティ）が果たす実践的な役割です。最終的なプロダクトと同じ挙動やテキストが必要な部分はどこかを見極めること。忠実度は、解消したい不確実性に応じて決めるべきであり、「すべてのプロジェクトがワイヤーフレームから作り込まれた画面へと同じ順序を踏むべき」といった固定概念に縛られる必要はありません。

自然な試行ができる自由度を持たせる

プロトタイプでユーザーが辿るルートは、往々にしてデザイナーがクリック可能にしたルートそのものになりがちです。他の選択肢がすべて無効だと、参加者は画面上の情報ではなく、クリックできる場所を探して進むようになってしまいます。これでは、不完全なデザインであっても使いやすいかのように見えてしまいます。

タスクの周辺にありそうな選択肢も用意し、成功を認識できる状態や、ミスからリカバリーできる状態も含めておきましょう。Nielsen Norman Groupによるプロトタイプの網羅性と深度の解説では、システムをどの程度まで再現するかがテストにとってなぜ重要なのかが説明されています。チームとして意識すべきなのは、想定通りのルートだけでなく、参加者が自然に試しそうなルートまで目を向けることです。

意思決定に影響を与える部分には、リアルなコンテンツを使いましょう。ダミーのアカウント残高、当たり障りのないエラーメッセージ、空の検索結果などは、参加者の行動を変えてしまうことがあります。テスト用データは、共有しても安全で、かつ実際の体験として信憑性があり、参加者に不要な個人情報を出させないものを用意します。

参加者に自然体でデザインに触れてもらう

参加者には、画面の操作方法を細かく説明するのではなく、目的だけを伝えたタスクシナリオを提示します。プロトタイプとして動かない部分など、現実的な制約は事前に伝えておくべきですが、リサーチで検証しようとしている知識を先に教えてしまうようなチュートリアルは避けましょう。

モデレーター付きのテストなら、リサーチャーが「その機能はまだ実装されていない」と補足しつつ、参加者が何を期待していたかを記録できます。セルフ型のテストなら、そうした問題を報告できる明確な仕組みが必要です。いずれにしても、プロトタイプ自体の限界と、デザイン案そのものの問題点は切り分けて捉えましょう。どちらも重要ですが、打つべき対策は異なります。

チームがFigmaを使っているなら、Ballparkのプロトタイプテスト機能を使ってデザインをそのままテストに組み込めます。参加者を募集する前に、まったく同じ環境でリハーサルを行ってください。デザイナーのブラウザでは問題なく動いていても、別の環境では権限が不足していたり、表示サイズが崩れたりすることがあります。

得られた学びを次のバージョンに反映する

シェアサイクルの例でいえば、参加者が正しく駐輪できたとしても、利用が終了したかどうかに不安を感じている場合があります。この不安を解消するには、完了メッセージを見直すのが有効かもしれません。一般的なオンボーディングツアーを追加しても、安心感が必要なその瞬間には届かない可能性があります。

起きた事実、改善案の背景にある解釈、そして次のテストで何を確かめるべきかを記録しておきましょう。セッションの合間にプロトタイプを改修する場合はバージョンを明確に分けて管理し、得られたインサイトが「実際にユーザーが見たデザイン」と正しく紐づくようにします。

プロトタイプテストが成功すれば、デザインに関する不確実性を減らすことができます。ただし、技術的な信頼性や市場の需要を証明したり、最終的な実装のアクセシビリティを保証したりできるわけではありません。そうした問いについては、実際のインタラクションを組み込んだテストを含め、プロダクトの開発が進む中で別途検証していく必要があります。