シンプルなグレースケールのワイヤーフレームであっても、極めてリアルな意思決定を検証できる一方で、美しく作り込まれたプロトタイプがほとんど役に立たないこともあります。ユーザーが必要とする実際の価格や制約条件、選択肢が含まれていれば、ダミーテキストで埋め尽くされた見栄えの良い画面よりも優れたテストができるかもしれません。プロトタイプの忠実度（フィディリティ）とは、完成形となるプロダクトをどれだけ精緻に再現できているかを表すものであり、その類似性にはいくつかの側面があります。

ビジュアルの見た目はそのひとつに過ぎません。コンテンツやインタラクション、そしてプロダクトのどの範囲をカバーしているかも重要です。具体的にどの要素の精度が高いのかを明確にせず、単に「ハイフィディリティ（高忠実度）」と呼んでしまうと、チームは何を検証できるのかを正確に把握できなくなります。

見た目の完成度にとらわれない

ビジュアルの忠実度とは、レイアウト、タイポグラフィ、配色など、見た目に関する要素を指します。インタラクションの忠実度とは、メニューが開くか、フォームに入力できるか、エラーを修正できるかなど、ユーザーのアクションに対して何が起きるかに関するものです。そしてコンテンツの忠実度は、そうしたインタラクションに意味を持たせる言葉やデータ、選択肢に関わってきます。

さらに、「広さ」と「深さ」という軸もあります。サービスの全体像を広く浅く見せるプロトタイプもあれば、特定のひとつのフローを詳細に再現するものもあります。Nielsen Norman Groupによるプロトタイプの忠実度に関する解説では、見た目、インタラクション、コンテンツをそれぞれ独立した選択肢として扱っています。これは、デザインの見栄えが良くなれば忠実度も一律に高まると思い込むよりも、はるかに実践的な考え方です。

たとえば、サブスクリプションサービスの解約フローをテストする場合を考えてみましょう。現実味のある更新日や返金条件、アカウントの状態が記載されたシンプルなページがあれば、ユーザーが解約による影響を理解できるかを調べるには十分かもしれません。もし「確定前に警告に気づくかどうか」を検証したいなら、余白や視覚的なヒエラルキーが重要になります。また、「誤って解約してしまった状態からの復帰」を検証したいなら、画面の遷移手順や実行できるアクションを正しく機能させる必要があります。

検証結果を左右するディテールを見極める

プロトタイプテストを行う前に、チームが何を学ぶ必要があるのか、そして何が原因でテスト結果に誤解が生じるかを書き出してみましょう。先ほどの解約フローの例で言えば、日付がダミーテキストになっていると、まさに検証すべき「ユーザーの迷い」が失われてしまう可能性があります。一方で、ダッシュボードに置く無関係なイラストは、おそらく結果に影響しません。

このプロセスを経ることで、見落としがちなインタラクションにも気づくことができます。モバイルの入力方法、読み込みの待ち時間、エラー表示などは、画面の見た目が完成していてもユーザーの行動に大きな影響を与えます。どんな入力でも受け付けてしまうプロトタイプでは、エラーメッセージがわかりやすいかどうかは判断できませんし、フォームの画像を見ただけでは、支援技術（アクセシビリティツール）で正しく操作できるかどうかはわかりません。

必要なディテールを作り込み、それ以上手を動かしても得られるインサイトが変わらない段階になったら、作業を止めましょう。リアルな挙動の検証が目的なら、わざわざ手書きのスケッチから始める必要はありませんし、フローの構造を検証したいだけなら、テスト前にビジュアルデザインを作り込む必要もありません。

「ラフに作れば率直な意見が出る」とは限らない

作り込まれていない外見は、デザインがまだ変更可能であることを伝えるのに役立ちます。しかし、それだけで参加者が必ず批判的な意見を言ってくれるわけではありませんし、逆に見た目が整っているからといって有用なフィードバックが得られないわけでもありません。リサーチの導入説明やモデレーターとの関係性、提示するタスク、参加者自身の状況などもセッションを大きく左右します。

「今回はデザインそのものをテストしているので、使いづらい点があればぜひ教えてほしい」と伝え、実際にタスクを進めてもらいましょう。プロトタイプの見た目だけで参加者の発言しやすさをコントロールしようとするよりも、実際の行動から問題を観察するほうが、はるかに多くの気づきを得られます。

構造的な課題を検証するなら、必要なコンテンツや導線が押さえられているワイヤーフレームテストが適しています。また、階層構造の中で情報を見つけられるかを検証したい場合は、一般的なプロトタイプよりも意図的に視覚要素を排除したツリーテストが有効な場合があります。

制約事項をそのまま結論に反映させる

レポートには、プロトタイプで何を再現し、何を省略したのかを明記すべきです。「参加者が解約フローを完了できた」という結果ひとつをとっても、実際のテスト用データを入力し、途中で考えを変え、エラーに直面しながら完了した場合と、用意された1本のルートをクリックしていっただけの場合とでは、意味がまったく異なります。

テストで省略した要素があるからといって、その調査が無駄になるわけではありません。それは、得られた結論がどこまでを担保できるのか、そして今後どんな課題に取り組むべきかを明確にしてくれます。実際のデータ、通信の遅延、アクセス権限、支援技術への対応などが実装段階で組み込まれたら、初期のプロトタイプで検証済みだと思い込まず、改めてその条件下でテストを行いましょう。