プログラマが知るべき97のこと/ユーザが何をするかを観察する (あなたはユーザではない)
私たちはどうしても、誰もが自分と同じような物の見方や考え方をするはず、と思ってしまいがちです。しかし実際には、物の見方や考え方は人によって大きく違っています。こういう誤った思い込みのことを心理学では「偽の合意効果」[1]と呼びます。自分と考え方や行動が違っている人を見た時、私たちは（多くの場合は無意識に)、そういう人たちを、何か問題のある人、というふうに評価してしまいがちです。
ユーザの身になって考えるということがなかなかできないプログラマが多いですが、その理由もこの「先入観」にあると言っていいでしょう。ユーザはプログラマのようには物を考えません。そもそも、プログラマに比べてコンピュータを使う時間が圧倒的に少ないのです。また、コンピュータが中でどう動いているのかを知らないし、知りたいとも思いません。プログラマなら日頃から当然のように馴染んでいる「問題解決のテクニック」がいろいろありますが、それに頼ることもできません。プログラマならば、ユーザインターフェースを弄るうちにお決まりのパターンや変化、ヒントなどを嗅ぎ取りますが、一般のユーザはそんなことはできません。
ユーザが何をどう考えるのかを知るには、ユーザそのものを観察するのが一番です。自分がいま開発中のソフトウェアとよく似たソフトウェアを使ってユーザに何か作業をしてもらい、その様子を見るのです。その作業は、できるだけ本物の業務の中にありそうなものにします。これは例えば｢列の数字を足し合わせていく」というような作業のことです｡｢先月の自分の出費を計算する」ならもっといいですね。しかし「スプレッドシートの特定のセルを選択して、SUM式を入力してください」というような､詳しすぎる指示は避けましょう。それだとユーザは自分でソフトウェアの使い方を考えたり、判断したりする必要がないからです。作業がどこまで進んだか、今どんな状況かをユーザ自身に話してもらいましょう。あなたは途中で作業に割り込んだり､手助けをしたりしてはいけません。観察しながら、絶えず「なぜ、この人はこういうことをするのだろう？」、「なぜ、こうはしないのだろう？」と考えるのです。
観察していて最初に気づくのは、おそらく「ユーザは基本的にはだいたい同じようなことをする」ということでしょう。作業を進める順序も、どこで間違えるかも、ほぼ同じなのです。つまりソフトウェアは、こういったユーザの基本的な振る舞いを踏まえて設計する必要があるということです。これは、会議室で「ユーザは多分、こうするから……」などと想像で話し合うのとはまったく違います。単なる想像を基に話し合っていても、ユーザが何を求めているか、明確なことは何もわからず、結局複雑で使いづらいものができてしまうでしょう。ユーザを直接観察すれば、それを防ぐことができるのです。
ユーザがどうしていいかわからず立ち往生する場面も何度か目撃することになるでしょう。そういう時プログラマならば、視点を変え、別の使い方を試します。しかしユーザはそうはいきません。立ち往生したユーザは視野を狭めてしまうため、画面内の別のどこかにある解決策を見つけることがとても困難になります。このため、ヘルプはユーザインターフェースの不親切さの解決にならないのです。問題解決のための指示、ヘルプテキストなどは、問題が起きているまさにその箇所に表示されないと意味がありません。ユーザの視野が狭くなってしまっているので、ヘルプメニューよりもツールチップの方が有用なのです。
ユーザは、自分の目的がどうにか達せられれば、それでよしとします。効率良くやろうとはあまり考えません。何とか目的を達せられる方法を1つ発見すれば、ずっとその方法に固執します。それがいかに非効率な方法だろうと、容易には変えようとしないのです。ショートカットが2つも3つも用意されていたとしても、大して意味はなく、それより、見てすぐにわかる方法が1つ用意されている方がありがたいと感じます。
ユーザが「こうしたい」と口で言ったことと、実際にやっていることが食い違っていることにもあなたは気づくでしょう。これも非常に厄介な問題です。ユーザが何を求めているかを知ろうとすれば、普通、彼らの言葉を頼りにするからです。実は、ユーザが求めているものを正しく知るには、言葉を聞くよりも、彼らの行動を観察する方がいいのです。彼らの求めるものを頭で考えて1日過ごすより、わずか1時間でも観察をした方が得るものは多いでしょう。