ユーザが何をするかを観察する（あなたはユーザではない）

私達はどうしても、誰もが自分と同じようなものの見方や考え方をするはずと思っていしまいがちです。しかし実際には、ものの見方や考え方はひとによって大きく違っています。こういう誤った思い込みのことを心理学では「偽の合意効果」とよびます。自分と考え方や行動が違っている人を見た時、私たちは(多くの場合は無意識に)、そういう人たちを、なにか問題のある人、というふうに評価してしまいがちです。

ユーザの身になって考えるということがなかなか出来ないプログラマが多いですが、その理由もこの「先入観」にあると言っていいでしょう。ユーザはプログラマのようには物を考えません。そもそも、プログラマに比べてコンピューターを使う時間が圧倒的に少ないのです。また、コンピューターが中でどう動いてるのかを知らないし、知りたいとも思いません。プログラマなら日頃から当然のように馴染んでいる「問題解決のテクニック」がいろいろありますが、それに頼ることもできません。プログラマならば、ユーザインターフェースをいじるうちはお決まりのパターンや変化、ヒントなどを嗅ぎ取りますが、一般のユーザはそんなことはできません。

ユーザが何をどう考えるかを知るには、ユーザそのものを観察するのが一番です。自分が今開発中のソフトウェアを使ってユーザに何か作業をしてもらい、その様子を見るのです。その作業は、できるだけ本物の業務の中にありそうなものにします。これは例えば「列の数字を足して合わせていく」というような作業のことです。「先月の自分の出費を計算する」ならもっといいですね。しかし「スプレッドシートの特定のセルを選択して、SUM式を入力してください」というような、詳しすぎる指示は避けましょう。あなたは途中で作業に割り込んだり、手助けをしたりしてはいけません。観察しながら、絶えず「なぜ、この人はこういうことをするのだろう？」、「なぜ、こうはしないのだろう？」と考えるのです。

観察していて最初に気づくのは、おそらく「ユーザは基本的にだいたい同じようなことをする」ということでしょう。作業を進める順序も、どこで間違えるかも、ほぼ同じなのです。つまりソフトウェアは、こういったユーザの基本的な振る舞いを踏まえて設計する必要があるということです。これは、会議室で「ユーザは多分、こうするから・・・」などと想像で話し合うのとは全く違います。単なる想像を基話し合っていても、ユーザが何を求めているか、明確なことは何もわからず、結局複雑で使いづらいものが出来てしまうでしょう。ユーザを直接観察すれば、それを防ぐことができるのです。

ユーザがどうしていいかわからず立ち往生する場面も何度か目撃することになるでしょう。そういう時プログラマならば、視点を変え、別の使い方を試します。しかしユーザはそうはいきません。立ち往生したユーザは視野を狭めてしまうため、画面の別のどこかにある解決策を見つけることがとても困難になります。このため、ヘルプはユーザインターフェースの不親切さの解決にならないのです。問題解決のための指示、ヘルプテキストなどは、問題が起きているまさにその箇所に表示されないと意味がありません。ユーザの視野が狭くなってしまっているので、ヘルプメニューよりもツールチップのほうが有用なのです。

ユーザは、自分の目的がどうにか達せられれば、それでよしとします。効率よくやろうとはあまり考えません。なんとか目的を達せられる方法を1つ発見すれば、ずっとその方法に固執します。それがいかに非効率な方法だろうと、容易には変えようとしないのです。ショートカットが2つも3つもよういされていたとしても、たして意味はなく、それより、見てすぐに分かる方法が1つ用意されている方がありがたいと感じます。

ユーザが「こうしたい」と口で言ったことと、実際にやっていることが食い違っていることにもあなたは気づくでしょう。これも非常に厄介な問題です。ユーザが何を求めているかを知ろうとすれば、普通、彼らの言葉を頼りにするからです。実は、ユーザが求めているものを正しく知るには、言葉を聞くよりも、彼らの行動を観察するほうがいいのです。彼らの求めるものを頭で考えて1日過ごすより、わずか1時間でも観察をしたほうが得るものは多いでしょう。