ユーザーにインタビューする
弱点はいろいろとあるにしても、インタビューというのは探索的ユーザー調査のための有益な手法である。
ユーザーの言うこととすることは違う。私はこのことを今まで数え切れないほど指摘してきた。「ユーザビリティの第一法則？ ユーザーの声は聞くべからず」というコラムまで書いたほどだが、そのコラムは9年前に書かれた当時と同様、今でも重要な意味を持っている。（最も優れたユーザビリティ手法というのは非常に安定したもので、だからこそ、有効な方法論を学ぶことによって、生涯使える非常に強力なROIを持つことになる）。
観察力のある読者は、応答時間の遅延についての最近の分析で、私が自分で書いた処方箋に違反したと不満をもらすだろう。その記事では、「エクスペリエンスとしてのブランド」セミナーに向けて実施した、一連のユーザーインタビューについて報告をした。では、人々が実際にどう行動するかを観察する代わりに 、彼らが何を考えているかをいきなり聞くというのはどうなのだろうか。
その答とは、インタビューはむしろユーザー調査の手法としてふさわしいというものである。ただし、それは有効なデータを生み出す事例に対して利用される場合に限られる。
インタビューでできないこと
インタビューの良い面の話をする前に、いろいろとあるインタビューの悪い点についておさらいしておこう。（その多くはウェブデザインのプロジェクトにおいて、広範囲で乱用されているフォーカスグループと共通している）。
ユーザーインタビューの重大な欠点は、あるシステムの過去の利用について思い出すこと、あるいは未来の利用について推測することを求めようとすることにある。回答はどちらもかなり説得力に欠け、誤った結論を導き出してしまうことが多い。
- 人の記憶は当てにならない。（詳しくは、「人の心」についてのセミナーで論じる）。 人々はウェブサイトをどのように利用したかを細かくは思い出せないし、 覚えている（あるいは間違ってはいるが覚えていると自分で思っている）ことがなんであれ、それを正当化するために話を作ってしまいがちである。そうすれば、話が実際以上に理に叶って聞こえるからである。
- ユーザーというのは物事を実用的かつ具体的に考える。 彼らは説明だけをベースにして、新しいテクノロジーをどのように使ったらいいかは考えつかないのが普通だ。ユーザーはデザイナーではないし、存在しないものについて想像をめぐらすスキルはほとんど持ち合わせていない。（その反対に、デザイナーはユーザーではない。したがって、あることが容易にできそうかについて、彼らが個人的にどう思うかは重要ではない）。
ユーザーのコメントはそれがどの時点で発せられたかを考えた方が良い。価値のあるデータが得られる時点は一箇所だけ、つまり、現在であり、そのユーザーがたった今、していることについてである。ユーザーに間違った過去を思い出させたり、誤った未来を予測させたりするのは、どちらも避けるべきなのである。
スペックが機能しない理由の1つは、ユーザー（や経営陣）には、仕様書が提供しているものが、形成されてしまった問題を解決するであろうものかどうかがわからないことにある。書面では間違いなくいい感じがしても、最後は大失敗に終わったと「ユーザー担当」が認めたケーススタディは数え切れないほどある。
これがアジャイル開発とペーパープロトタイピング手法がなぜ有益であるかの理由である。ユーザーは具体的に関われる何かがあるときに、あなたがたが容易で快適なやり方で問題を解決しようとしていると理解することが多い。そして、同様に、解決しようとしてないということもわかってしまうけれども。
デザインについての具体的な問題のほとんどは、ユーザーインタビューからは答が得られない。以下はインタビューからはわからない事柄である：
- Buy（：購入）ボタンは赤くすべきか、それともオレンジにすべきか。
- 選択肢のセットがいくつかあるのだが、ドロップダウンメニューを利用した方がいいか、それともラジオボタンのセットの方がいいか。
- Aという製品ラインはIAのどこに存在すべきか。
- ナビゲーションのレベルは3段階あった方がいいか、それとも、たとえメニューが長くなろうとも2段階にすることにこだわるべきか。
- システムの正確な利用方法を1番うまく教えるためにはヘルプ情報はどのように書くべきか。
もちろん、これらの質問はどれもユーザーに尋ねることが可能だ。しかし、その答は実際のウェブサイトにとって効果的なデザインとは全く関係のないものになってしまうだろう。特定のUI要素に関するジレンマは、特定の解決策を実装したデザインに対し、ユーザーがどのように反応するのか、を見ることによってのみ解決することができる。そうすれば、実際の使用時にどのくらいうまくいくかを確かめることができるからである。（あるいは複数のオプションを実装して、比較テストをしてもよい）。
同様に、「Xという（将来、実現可能な）機能をあなたは利用するでしょうか」という質問もしてはならない。なぜならば、ユーザーは見たことがないものについて、予言はできないからである。既に存在する機能に対しても、「Yという機能はどのくらい便利でしょうか」と聞いてはならない。実際のところ、多くの調査では、インタビュアは存在しないが、呼び鈴としてインタビューの中に仕込まれた特定の機能について、ユーザーにコメントを依頼していた。そして、ユーザーからは大量のフィードバックが戻ってきてはいた。
（The take awayじゃないかって？（訳注：The take awayというのはアメリカのラジオ番組。リスナーに質問を投げかけ、その回答をSNSを通して集め、番組に反映させるスタイルで有名）。あなたの開発している機能をどの程度いいと思うかをユーザーに尋ねざるを得ないのなら、基準値を集めるために、実際には存在しない機能を忘れないようにいくつか入れておこう)。
ある有名な調査の話だが、MicrosoftはOffice 2007の開発を始める前、それのための新機能を提案してくれることを顧客に依頼した。しかし、顧客からリクエストのあった「新しい」コマンドのほとんどは既にOffice 2003にあるものだった。それによって、デザインチームは自分たちの主な問題は、既存の機能の発見しやすさにある、という結論に正しくたどり着いた。
機能を評価するには人々に使ってもらうことである。ユーザーがその機能に関わっている間のコメントには無条件に注目しよう。タスクの実行直後、その機能についての記憶がまだ新しい間であれば、補足的なコメントをお願いすることも可能である。
インタビューからわかること
ブランドセミナーに向け、我々はユーザーが長い間ウェブサイトを利用することによって、彼らのそのサイトに対する印象やそのブランドの未来への期待がどのように確立されるかを知りたいと考えた。言い換えれば、我々にはページごとのデザインへの興味はなかった。そのことはユーザーテストを通して、ずっと調査をしてはきたが。そうではなく、むしろ知りたかったのは、サイトの利用後にユーザーがそのサイトについて何を思ったか、であった。そして、そうしたことこそが質問によって一番うまく評価できる事柄である。
インタビューはユーザーの一般的な態度、あるいは、ある問題について彼らがどのように考えているかを調査したいときにも有益である。こうした情報を得た後に、その問題に対処する機能をデザインするのは（そして、その機能が正しいものであることを保証するためにそのデザインのプロトタイプをテストすることは）あなたがたの責任になる。
クリティカルインシデント法はこうした探索的インタビューには特に有効だ。その手法ではユーザーに彼らがぶつかった特に困難だった状況、あるいは何か特にうまくいったことの中から、特定の例を思い出してもらうように依頼する。こうした極端な事例はユーザーの記憶の中でより鮮明に残っていることが多いので、有効な機能を考え出すのに必要な細部についての情報が手に入るのである。
（反対に、あるタスクについていつもはどのようにしているかを尋ねてしまうと、聞かれた場所が家であろうと、オフィスであろうと、現実のプロジェクトの特徴である様々なショートカットや逸脱を抜きにした、理想的なワークフローについて描写されてしまうことが多い。アプリケーションの良質なワークフローを決定するために重要なことの1つは、理想的な状況のためではなく、人々が実際にしているやり方に向けてデザインすることである）。
クエリー効果に用心せよ
ユーザーに意見を聞くときにはクエリー効果に気をつけよう。というのも、人というのはどんなことについても意見を作り上げることができるので、聞かれればそうしてしまうからである。その結果、どうでもいいことや、自分からは二度とそれについて考えたりはしないことについて、ユーザーに長々とコメントさせてしまう可能性もある。
「ユーザーがこれを好きではないから」とか「ユーザーがそうして欲しいと言ったから」といった理由で大規模なデザイン変更をするのは危険なことである。誘導尋問をされたり、回答を迫られたりすると、参加者というのはこれっぽっちも自分の実際の嗜好を反映していない意見を創り出してしまうこともある。
例えば、デザインの見た目について繰り返し聞くと、色についてのコメントが必ず出てくる。色がそのユーザーにとって特に重要でなくても、だ。その一方で、人々がサイトを利用しながら（自発的に）色の話に触れるのであれば、そこには何か考慮すべきものがあると思われる。（例えば、「うわっ、この派手な青は目にささるね」といったコメントや、「その群青色は落ち着いていていいね」といったより肯定的な発言がそれに当たる）。
複数の方法を組み合わせよう： データの三角測量
インタビューというのは他のユーザビリティ手法を大いに補完するものである。もし１つしか手法を用いることができないというのなら、常に最も推薦される手法はユーザーテストだろう。しかし、なぜ１つの手法しか使わないと決めてしまうのか。どの手法であれ、実行するには数日しかかからないのだから、ごくわずかな予算のみで、複数の手法を組み合わせることは可能である。
このコラムのきっかけになった例、つまり、ウェブサイトの応答時間から得られた最新の発見について思い出してみよう。特定のページの読み込みや、フォームの処理、AJAXウィジェットの操作のための最適なスピードを知りたければ、これらのデザインを用いた代表的なタスクをユーザーがどのように実行するかを観察する必要がある。何かの反応が遅すぎれば、ユーザーはイライラして、覚えられなくなっていき、終いにはそのサイトから離れてしまうということがわかるだろう。しかし、数週間後、ユーザーにそのことを聞いても、彼らは具体的にどのUI要素が遅すぎたかは覚えていないだろうし、彼らの注意持続時間の限界が何秒だったかも全く思い出せなくなっている。しかし、その反対に、反応ののろいサイト、あるいはてきぱきとしたサイトのブランドへのインパクトを知りたければ（これを我々は最近調査した）、インタビューをするのが良い。こうした高いレベルの問題に対して、そうしたサイトを使ってしばらく経った後もユーザーの頭から離れないそうした強烈な印象というのが何によって作られるのかを知りたくなるはずだからである。
手法にはそれぞれ長所と短所がある。各手法から得られる一番優れたデータを使えば、１つの手法のみを利用して得られるよりもずっと豊かな内容を理解することができる。また、個別の手法を様々な他の手法を用いて補うことによって、調査結果を三角測量して、間違った結果を生み出すのを防ぐことが可能である。
