ユーザが何をするかを観察する (あなたはユーザではない) – プログラマが知るべき97のこと

What-Would-the-User-Do

この記事は、「プログラマが知るべき97のこと」について、英語と日本語訳を記載したものです。

プログラマが知るべき97のこと(オライリー・ジャパン、2010年)
Kevlin Henney(編)、和田 卓人(監修)、夏目 大(訳)
各エッセイはCC-by-3.0-USによってライセンスされています。

We all tend to assume that other people think like us.

私たちはどうしても、誰もが自分と同じような物の見方や考え方をするはず、と思ってしまいがちです。

But they don’t.

しかし実際には、物の見方や考え方は人によって大きく違っています。

Psychologists call this the false consensus bias.

こういう誤った思い込みのことを心理学では「偽の合意効果」と呼びます。

When people think or act differently to us, we’re quite likely to label them (subconsciously) as defective in some way.

自分と考え方や行動が違っている人を見た時、私たちは(多くの場合は無意識に)、そういう人たちを、何か問題のある人、というふうに評価してしまいがちです。

This bias explains why programmers have such a hard time putting themselves in the users’ position.

ユーザの身になって考えるということがなかなかできないプログラマが多いですが、その理由もこの「先入観」にあると言っていいでしょう。

Users don’t think like programmers.

ユーザはプログラマのようには物を考えません。

For a start, they spend much less time using computers.

そもそも、プログラマに比べてコンピュータを使う時間が圧倒的に少ないのです。

They neither know nor care how a computer works.

また、コンピュータが中でどう動いているのかを知らないし、知りたいとも思いません。

This means they can’t draw on any of the battery of problem-solving techniques so familiar to programmers.

プログラマなら日頃から当然のように馴染んでいる「問題解決のテクニック」がいろいろありますが、それに頼ることもできません。

They don’t recognize the patterns and cues programmers use to work with, through, and around an interface.

プログラマならば、ユーザインターフェースを弄るうちにお決まりのパターンや変化、ヒントなどを嗅ぎ取りますが、一般のユーザはそんなことはできません。

The best way to find out how users think is to watch one.

ユーザが何をどう考えるのかを知るには、ユーザそのものを観察するのが一番です。

Ask a user to complete a task using a similar piece of software to what you’re developing.

自分がいま開発中のソフトウェアとよく似たソフトウェアを使ってユーザに何か作業をしてもらい、その様子を見るのです。

Make sure the task is a real one: “Add up a column of numbers” is OK; “Calculate your expenses for the last month” is better.

その作業は、できるだけ本物の業務の中にありそうなものにします。これは例えば「列の数字を足し合わせていく」というような作業のことです。「先月の自分の出費を計算する」ならもっといいですね。

Avoid tasks that are too specific, such as “Can you select these spreadsheet cells and enter a SUM formula below?” — there’s a big clue in that question.

しかし「スプレッドシートの特定のセルを選択して、SUM式を入力してください」というような、詳しすぎる指示は避けましょう。それだとユーザは自分でソフトウェアの使い方を考えたり、判断したりする必要がないからです。

Get the user to talk through his or her progress.

作業がどこまで進んだか、今どんな状況かをユーザ自身に話してもらいましょう。

Don’t interrupt. Don’t try to help.

あなたは途中で作業に割り込んだり、手助けをしたりしてはいけません。

Keep asking yourself “Why is he doing that?” and “Why is she not doing that?”

観察しながら、絶えず「なぜ、この人はこういうことをするのだろう?」、「なぜ、こうはしないのだろう?」と考えるのです。

The first thing you’ll notice is that users do a core of things similarly.

観察していて最初に気づくのは、おそらく「ユーザは基本的にはだいたい同じようなことをする」ということでしょう。

They try to complete tasks in the same order — and they make the same mistakes in the same places.

作業を進める順序も、どこで間違えるかも、ほぼ同じなのです。

You should design around that core behavior.

つまりソフトウェアは、こういったユーザの基本的な振る舞いを踏まえて設計する必要があるということです。

This is different from design meetings, where people tend to be listened to for saying “What if the user wants to…?” 

これは、会議室で「ユーザは多分、こうするから……」などと想像で話し合うのとはまったく違います。

This leads to elaborate features and confusion over what users want.

単なる想像を基に話し合っていても、ユーザが何を求めているか、明確なことは何もわからず、結局複雑で使いづらいものができてしまうでしょう。

Watching users eliminates this confusion.

ユーザを直接観察すれば、それを防ぐことができるのです。

You’ll see users getting stuck.

ユーザがどうしていいかわからず立ち往生する場面も何度か目撃することになるでしょう。

When you get stuck, you look around.

そういう時プログラマならば、視点を変え、別の使い方を試します。

When users get stuck, they narrow their focus.

しかしユーザはそうはいきません。

It becomes harder for them to see solutions elsewhere on the screen.

立ち往生したユーザは視野を狭めてしまうため、画面内の別のどこかにある解決策を見つけることがとても困難になります。

It’s one reason why help text is a poor solution to poor user interface design.

このため、ヘルプはユーザインターフェースの不親切さの解決にならないのです。

If you must have instructions or help text, make sure to locate it right next to your problem areas.

問題解決のための指示、ヘルプテキストなどは、問題が起きているまさにその箇所に表示されないと意味がありません。

A user’s narrow focus of attention is why tool tips are more useful than help menus.

ユーザの視野が狭くなってしまっているので、ヘルプメニューよりもツールチップの方が有用なのです。

Users tend to muddle through.

ユーザは、自分の目的がどうにか達せられれば、それでよしとします。効率良くやろうとはあまり考えません。

They’ll find a way that works and stick with it no matter how convoluted.

何とか目的を達せられる方法を1つ発見すれば、ずっとその方法に固執します。それがいかに非効率な方法だろうと、容易には変えようとしないのです。

It’s better to provide one really obvious way of doing things than two or three shortcuts.

ショートカットが2つも3つも用意されていたとしても、大して意味はなく、それより、見てすぐにわかる方法が1つ用意されている方がありがたいと感じます。

You’ll also find that there’s a gap between what users say they want and what they actually do.

ユーザが「こうしたい」と口で言ったことと、実際にやっていることが食い違っていることにもあなたは気づくでしょう。

That’s worrying as the normal way of gathering user requirements is to ask them.

これも非常に厄介な問題です。ユーザが何を求めているかを知ろうとすれば、普通、彼らの言葉を頼りにするからです。

It’s why the best way to capture requirements is to watch users.

実は、ユーザが求めているものを正しく知るには、言葉を聞くよりも、彼らの行動を観察する方がいいのです。

Spending an hour watching users is more informative than spending a day guessing what they want.

彼らの求めるものを頭で考えて1日過ごすより、わずか1時間でも観察をした方が得るものは多いでしょう。

by Giles Colborne

タイトルとURLをコピーしました