1. ホーム
2. ニールセン博士のAlertbox

UXプロトタイプ：低忠実度か高忠実度か

クリック可能か静的か。Axureかペーパーか。だが、利用するプロトタイピングツールが何であれ、有効なユーザー調査のためにユーザーインタフェースのプロトタイプを作成するときのヒントは同じである。

• UX Prototypes: Low Fidelity vs. High Fidelity
• by Kara Pernice
• on December 18, 2016
• 日本語版2017年4月10日公開

テスト可能なプロトタイプとは何か

ユーザーインタフェースのプロトタイプとは仮説だ。つまり、特定のデザイン課題のために考えたデザインソリューションの候補案といえる。したがって、そのもっとも手っ取り早いテスト方法は、ユーザーがそれを使って作業しているところを観察することである。

プロトタイプにはいろいろなタイプがあるが、そのどれもが以下に挙げた両極のどこかに当てはまることになる：

• 「シングルページ」対「ユーザーがタスクを完全に終えられるだけの十分なメニューや画面、クリックターゲットをそなえたマルチページ」
• 「リアルで詳細」対「紙に書いた手描きのスケッチ」
• 「インタラクティブ（クリック可能）」対「静的（誰かが「コンピュータ」役になって、ページを操作する必要がある）」

どんなプロトタイプを選ぶかは、テストの目的やデザインの完成度、プロトタイプ作成に使うツール、ユーザビリティテストの準備や実際のテストを手助け可能なリソースによって、大きく変わってくる。しかし、どんなプロトタイプを使うにしろ、プロトタイプをテストすれば、ユーザーのインタラクションや反応がわかるようになるので、デザインを改善できるだろう。

プロトタイプをテストする理由

コードの破棄は非常に高くつくからだ。しかし、プロトタイプならそうではない。プロトタイプがただの紙切れ1枚なら、なおさらそうだろう。

ではまず、プロトタイプのテストをしないという根拠の一般的なものを見てみよう。そうした根拠とは次のようなものである：

• デザインが実装されるのを待って、テストをすれば、そのデザインが実際に動作することになるので、テスト参加者も自然なやり方でそのデザインを利用することができる。
• アジャイルやウォーターフォール型のプロセスでは、UXデザインや反復デザインに対応するための修正は発生しない。
• リーンの支持者の中には、プロトタイプのテストをしなければ、（やむをえず）結果が悪いときに破棄するプロトタイプが出ないので無駄がない、と言う人もいる。

こうした根拠は一見、良さそうに見える。しかし、実際には、最終製品をテストしても情報は得られないし、危険でもある。賢明なデザインチームはプロトタイプを作成して、それをユーザーにテストしてもらい、デザインが十分なレベルに達するまで反復を繰り返すものである。（注意：我々も、プロジェクトの最後、あるいは新規プロジェクトならその最初に、最終製品のユーザビリティベンチマークテストをして、ROIを評価したり、競合調査を実施したり、最終チェックをして、ちょっとした微調整をしたりすることはやっている）。

インタラクティブなプロトタイプか、静的なプロトタイプか

プロトタイプをユーザビリティテストで使えるようにするには作業が必要だ。ユーザーの行動に応じてプロトタイプが動くようにするには、テスト前にじっくりと時間を使ってインタラクションを実装するか、テスト中にインタラクションがある「ふりをする」ことになる。そして、このどちらのやり方にも利点と欠点がある。

インタラクティブ（クリック可能）なプロトタイプ

インタラクティブなプロトタイプを使う場合、テストでユーザーの行動が実際に発生する前に、デザイナーはユーザーが取りうる行動の1つ1つに対する反応を設定しておかなければならない。たとえ、ツール自体は適切であったとしても、インタラクティブなプロトタイプの構築には非常に時間がかかる。すべてのクリックターゲットについて正確に理解し、ユーザーがクリック可能なターゲットを操作しているときのみ、システムが反応するようにしなければならないからである。

静的なプロトタイプ

静的なプロトタイプの場合、ユーザーの行動への反応はそのデザインを熟知している人によって、テスト中、リアルタイムで返されることになる。静的プロトタイプに利用できる手法には以下のようなものがある：

• オズの魔法使い（Wizard of Oz）。この手法は同名のFrank Baumの有名な著書（映画はさらに有名）にちなんで名付けられた。（この本や映画を知らない人へ：この作品に出てくる大魔法使いのオズは、普通の人間がカーテンの後ろに隠れてなりすましたものである）。「魔法使い」（デザイナーか誰かそのデザインを熟知している人）が別の部屋からユーザーの画面を遠隔操作するからである。ユーザーのクリックやタップは実際には何の効果も及ぼさない。その代わりに、ユーザーがクリックすると、「魔法使い」が次に何が起こるかを判断して、ユーザーの画面にそのページを表示する。この「魔法使い」はその場の判断でページを作り出し、それを表示したりもする。反応を返しているものの正体がユーザーに知らされることはない。実際のところ、システムは「完成品ではないので遅い」以上のことがユーザーに伝えられることはほとんどない。オズの魔法使いテストは人工知能を実装する前のAIベースのシステムのテストに特に有益である。コンピュータをコントロールする人が自分の自然知能を使って、AIの反応をシミュレーションできるからである。
• ペーパープロトタイプの「コンピュータ」。この手法では、デザインは紙に書かれたものである。そして、そのデザインをよくわかっている人が「コンピュータ」役になり、そうした紙はテーブルの上に並べられる。そのテーブルはユーザーがテストで使っているテーブルの近くに置くが、ユーザーの視線には入らないようにする。ユーザーが彼女の前にある紙の「画面」を指でタップしたら、「コンピュータ」は反応として表示するページ（またはモジュールのパート）を選んで、その紙をユーザーの前に置く。（この記事では、テストセッション中、ユーザーインタフェースを実装する人を「コンピュータ」と呼んでいる）。
  ヒント：
  1. 「コンピュータ」は「自分（コンピュータ）」の作業が終わり、ユーザーが次のインタラクションに進めるようになったら、そのことをユーザーに示すべきである。これには特定のジェスチャーを一貫して使うのもいいし（たとえば、体の前で両手を組み合わせるなど）、「コンピュータ」が適切な反応を探している間は「作業中」という文字、または、砂時計のアイコンが印刷されている特製の紙をユーザーに示しておいて、「コンピュータ」が作業を終えたらすぐにそれを片付けるということにしてもよい。
  2. 進行役はデザイン要素やプロセスについて説明しすぎないようにしよう。
• “マウス奪取型”（Steal-the-Mouse）の「コンピュータ」。この手法はオズの魔法使い法の一種で、ここでは「魔法使い」はユーザーと同じ部屋にいる。（「魔法使い」の役割は進行役が果たしてもよい）。プロトタイプはコンピュータの画面上でユーザーに示される。ユーザーがクリックするたびに、進行役はモニターから一瞬、目をそらしてくれるようにユーザーに依頼する。そして、「魔法使い」が次にあらわれるはずのページを表示させる。それが終わったところで、モニターを見て、続きをするようにユーザーには指示が出される。

プロジェクトに適したプロトタイプ選びの助けになる基準

プロトタイプの忠実度

プロトタイプの忠実度とは、最終システムのルックアンドフィールとの一致度合いのことである。忠実度は以下の領域によって変化することになる：

• インタラクティブ性
• 見た目
• コンテンツとコマンド

プロトタイプの忠実度は、上記の3つの領域の全部または一部において高いこともあれば、低いこともある。下の表は、各領域で忠実度が高い、または低いというのはどういうことかの説明である。

インタラクティブ性

	高忠実度プロトタイプ	低忠実度プロトタイプ
クリック可能なリンクやメニュー	Yes：多くの、またはすべてがクリック可能。	No：ターゲットは機能しない。
ユーザーの行動への自動的な反応	Yes：プロトタイプ内のリンクはプロトタイピングツール（たとえば、InVision、PowerPointなど）によって動作するようになっている。	No：ユーザーへの画面の表示は「コンピュータ」役の人がリアルタイムでおこなう。

見た目

	高忠実度プロトタイプ	低忠実度プロトタイプ
写実度や画面の要素の優先順位、画面サイズ	Yes：実際のシステムのようなグラフィックや余白、レイアウトになっている（たとえ、そのプロトタイプが紙に書かれたものであったとしても）。	No：実際の最終システムから取り込まれる視覚属性は一部のみ、または何もない（たとえば、モノクロのスケッチやワイヤーフレーム、画像やグラフィックの配置図、画面数個分の情報を書いた紙1枚だったりする）。余白や要素の優先順位は保持されていることもあれば、そうでないこともある。

コンテンツとナビゲーションの階層

	高忠実度プロトタイプ	低忠実度プロトタイプ
コンテンツ	Yes：プロトタイプには最終デザインで表示されることになるすべてのコンテンツが入っている（たとえば、記事全文、商品説明のテキスト、画像など）。	No：プロトタイプにはコンテンツの要約や商品画像の代わりになるものが入っているだけである。

高忠実度プロトタイプの利点

1. インタラクティブ性の忠実度が高いプロトタイプは、テスト中、システムからの反応にリアリティがある（速い）。オンラインであれ、紙であれ、コンピュータ役の人が適切な画面を見つけて、ユーザーのクリックに反応を返すのには追加の時間が必要となる。ユーザーの行動と「コンピュータ」の反応の間にタイムラグがありすぎると、ユーザーの作業の流れが途切れてしまい、前にやっていたことや、次に見ようと思っていたものを忘れてしまうこともある。また、反応が遅いと、ユーザーに今のページを調べる時間が余分にできることになる。その結果、遅いプロトタイプを使うと、ユーザビリティテストの参加者が普段、実際のシステムを使っているときよりも、デザインの詳細を気にするようになってしまったり、コンテンツの理解度が上がってしまったりすることもある。
   ヒント：次に出るはずのページをペーパープロトタイプで探すのがたいへんだったり、クリック可能なプロトタイプで読み込むのに時間がかかるようなら、ユーザーが見ている今のページは引っ込めよう。そうすれば、彼女は代わりに空白のページや領域を見ることになる。そして、次のページの準備ができたら、まず、前のページをもう一度、少しの間、見せれば、ユーザーは今、自分がどこにいるかがわかる。そうしてから、その画面を次の画面と入れ替えればよい。また、テスト進行役がひとこと声をかけることで（たとえば、「ちょっと振り返りますと、「About Us」をクリックしたところでしたね」のように）、ユーザーが前のコンテキストに戻りやすくなり、このプロセスの支援になる。
2. インタラクティブ性や見た目の忠実度が高ければ、ワークフローや具体的なUI要素（たとえば、メガメニュー、アコーディオンなど）、アフォーダンスやページの階層構造、文字の見やすさ、画像の質のようなグラフィック要素、さらにはエンゲージメントについてもテストすることが可能である。
3. 高忠実度のプロトタイプは「本物の」ソフトウェアのようにユーザーには見えることが多い。つまり、テスト参加者の行動は実際のシステムを操作しているかのようなリアルなものになる可能性が高い。ところが、大ざっぱなプロトタイプを使うと、何が動くはずで、何がそうでないかという期待を、彼らが明確に持てない可能性がある。（とはいえ、すべてがリアルというわけではないテストという状況において、多くのユーザーがウソ臭さをしっかり許容するのは驚くべきことだが）。
4. インタラクティブ性の忠実度が高ければ、デザイナーはテストの観察に集中できるようになり、次に何が来るべきかを考えなくてもすむ。つまり、プロトタイプを動作させることについて、テスト中、誰も気にしなくてもよい。
5. インタラクティブなプロトタイプのテストは人為的なエラーの影響を受けにくい。静的プロトタイプの場合の「コンピュータ」にかかるプレッシャーは多大だし、ミスの可能性も高い。焦りやストレス、緊張、ユーザーのクリックに細心の注意を払わなければならないこと、紙の束の中から次を見つけて進んでいかなければならないことのすべてのせいで、「コンピュータ」がパニックになることもありうるし、テスト中、単に間違ってしまうこともあるだろう。

低忠実度プロトタイプの利点

1. 静的プロトタイプの作成には時間がかからないので、テスト前にデザインのための時間がより長く取れる。クリック可能なプロトタイプの作成には時間がかかる。プロトタイプが動くようにする必要がなければ、ページやメニュー、コンテンツのデザインに費やせる時間が増える。（そうはいっても、「コンピュータ」が適切なページをすぐに見つけて、提示できるように、テスト前にページを整理しておく必要はある。しかし、一般に、この作業のほうがクリック可能なプロトタイプの作成よりはずっと時間がかからない）。
2. テスト中のデザイン変更が容易である。テストの次のセッションまでに（またはセッション中に）、デザイナーがすばやく次の反応を書いたり、デザインの一部を消したり、変更したりすることが可能である。そして、インタラクティブなプロトタイプで、新しいページのリンクがどうなっているかを心配する必要もない。
3. 忠実度の低いプロトタイプはユーザーのプレッシャーを減らす。デザインが完成していないように見える場合、そこまでのデザインにかかった時間が1分なのか、数ヶ月なのかは、ユーザーにはまったくわからないことが多い。その結果、実際にテストされているのはデザインであって自分ではない、と理解しやすくなり、うまくやらなければとあまり思わないですむ。そのため、否定的な反応も示しやすくなると考えられる。
4. プロトタイプの忠実度が低いと、デザイナーがあまり固執しないですむ。完全にインタラクションが可能で、きれいにデザインされているものよりも、不完全なデザインのほうがデザイナーには変更しやすい。デザインに時間と労力をかければかけるほど、それがうまくいかなかったときに諦めるのは難しくなるからだ。
5. まだ完成品ではないということが利害関係者にもわかる。大ざっぱなプロトタイプを見れば、それが明日出荷されるとは思わないものだ。そして、デザインが決定するまでにはまだ変更があるとチーム全員が思うだろう。（逆に、デザインの完成度が非常に高いと、「このデザインはカッコいいね、もう稼働させよう」と言ってしまう罠に上層部が陥りやすい）。

プロトタイプテスト中のユーザーとのやりとり

プロトタイプのテストでは、本物のシステムのテストよりも進行役が参加者に話しかける機会が少し増えるものだ。そうしたほうがよい主な理由は以下のとおりである：

• 調査開始前に、（そのデザイン自体がどう動作するかということではなく）プロトタイプというメディアの特性をユーザーに説明する必要がある。
• ときにはシステムの状態を説明して（たとえば、「このページは現時点では動作しません」など）、「どうなると思っていましたか」とたずねなければならないこともある。
• ユーザーがじっとしているときに、（遅いシステムからの）反応を待っているのか、それともタスクを達成できたと思っているのか、明らかにしなければならないかもしれない。

テスト進行役とユーザーの間で、上記のようなやりとりが必要になるにしても、究極的には、デザイン案を操作している参加者を静かに見守り、彼らとは会話しないことを、テスト進行役は目指すべきである。

ヒント：

1. 反応をまだ用意していないアイテムをユーザーがクリックした場合：
   • 「それは動きません」と言おう。
   • 「それをクリックしたらどうなると思っていましたか」とたずねよう。
   • もしあれば、次善のページを提示し、説明にあたることを言おう。たとえば、「「小型車」というリンクをクリックしていただきましたが、本日はその画面を用意しておりません。そこで、「中型車」のほうをクリックしたことにしていただいてもよろしいでしょうか」。そして、ユーザーから承認が得られたら、中型車のページを提示すればよい。その後はできるだけ何も言わないようにし、中立の立場を守ろう。
2. ユーザーがクリックした後に出たページが間違っていた場合、「コンピュータ」はできるだけ早くそのページを取り下げ、前のページに戻すべきである。そして、進行役はそれが違うページだったとすぐにユーザーに言って、「「About Us」をタップしましたよね」というふうに、先ほどのページでユーザーがおこなったことを伝えるべきである。その後、「コンピュータ」が適切なページを提示すればよい。

「コンピュータ」のエラーはマイナスの影響をもたらす

「コンピュータ」によるエラーがテストに深刻な影響を与えることは覚えておかなければならない。画面が出るたびに、ユーザーはそのシステムや調査手法がどうなっているのかというメンタルモデルをかたちづくっていっているからだ。

もし表示されたページが間違っていても、たった今、見たものをユーザーに忘れさせることができるなどとは思ってはならない。（記憶が消去できるのはスタートレックの中だけだ）。該当の画面を取り下げたり、それはエラーだったと説明しようとしても、ユーザーがその間違った画面もタスクに関連したものだろうと推測することはありうる。また、あなた方の説明から追加の情報を得てしまうかもしれない。

そして、後になって、そうした情報に左右されることもあるだろう。また、間違ったページを見ることで、ユーザーの作業の流れが途切れて、彼らが混乱してしまうこともある。他にも、その後のテスト中、現れた画面が自分の期待と違うと、またプロトタイプが正常に機能していないだけかもしれないと思ってしまう可能性もある。こうなると、ユーザーの期待や調査手法への信頼、一貫性のあるメンタルモデルを形成する能力にも影響が出るだろう。

コンピュータのエラーは調査そのものに悪い影響を与えるので、全セッション開始前にパイロットテストをして、プロトタイプについての課題を解決する時間を取るべきである。

結論

プロトタイプのテストは必ずやるべきことだ。デザインというのはいずれにしろ、テストされることになるからである。それには自分たちが計画しているかどうかは関係ない。いったん、システムが立ち上がって、ユーザーの利用が始まると、彼らによってテストされていくことになるからである。

調査という、学んで、反応して、デザイン変更が可能な、低リスクの環境でフィードバックを集める、ということをやらないのであれば、あなた方が手にすることになるのは、不満を実際に抱えた顧客だ、というである。そして、彼らとともにもたらされるのは、売上の低下、注文の放棄、コンテンツや商品の理解不足、不適切な口調による疎外感、返品、サポートコールの増加、トレーニング費用の増加、ひどいエクスペリエンスのSNSでのシェア、低いネットプロモータースコア、ブランドからの離反といったうんざりするほどの課題だ。

企業としてはこのすべての課題を解決する方法を検討していくことになるし、開発チームはそれに応えて、デザインの修正に奔走し、動作中のコードやビジュアル、コンテンツを破棄して、やっつけで作ったかろうじてマシなだけのコードに差し替えることになるだろう。こうしたすべての作業は多大な代償を伴う。

デザインを変更し、コードを破棄し、新デザインに合わせてコーディングをやり直し、そのコードの品質テストをおこない、そして、必要なら、マーケティング用の資料や付属資料も変更するというのは、プロトタイプの破棄に比べると、はるかに費用がかかるからである。

プロトタイプをテストしよう。クリック可能なタイプであろうが、静的なタイプであろうが、忠実度が高かろうが、低かろうが、それは関係ない。自分たちのデザインをどう変更し改善していくかの理解を目的にすればよいのだ。そうすれば、あなた方のデザインの欠陥が顧客の目に入ることはなくなるはずである。

関連記事：「プロトタイプの忠実度に対するIAにもとづく視点」も読んでみよう。

テスト可能なプロトタイプの作成についてのさらに詳しい情報は、ペーパープロトタイプのトレーニングビデオで入手可能だ。また、「ワイヤーフレームとプロトタイプ」についてのトレーニングコースに参加するのもいいだろう。