Ask “What Would the User Do?“问自己“用户将会做什么？”(97 Things Every Programmer Should Know 3/97)

Ask “What Would the User Do?” (You Are not the User)

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. 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(复杂的,费解的). It’s better to provide one really obvious way of doing things than two or three shortcuts. 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.

by Giles Colborne

“问自己“用户将会做什么？”(你不是用户)

我们都倾向于假设其他人自己那样思考。但他们不。心理学家称这为“虚假同感（一致性）偏差”。当人们思考或者表现地和我们不同，我们很可能在某种程度上（下意识地）给他们贴上“有缺陷的人”的标签。

这种偏差解释了为什么程序员很难站在用户的角度思考。用户不像程序员那样思考。首先，他们花很少的时间使用电脑。而且他们不知道也不关心电脑怎么工作。这意味着不能够凭借任何一种解决问题的技术，尽管这些对于程序员来说是那么的熟悉。他们不能意识到这些模式或者提示，这些正是程序员用来工作的接口说明。

查明用户如何思考的最好方式是观察他们。请求用户使用和你开发的产品类似的软件去完成任务。确保这个任务是一个真实的：“添加一些数”是可以的，“计算最后一个月你的花费”这个更好。避免任务太过具体，比如“你可以选择这些电子表格单元并且在下面输入一个求和公式吗？”——在那个问题中需要个大的线索。让用户讨论自己的过程.不要打断他们.不要尝试去帮助.持续问自己"为什么他们会那样做".

你将会最先注意到的是用户做一个事情的核心是类似的.他们按照相同的次序去努力完成任务,而且他们会在相同的地方犯相同的错误.你应该在那些核心行为上做设计.这和设计会议是不同的,那里人们经常听别人说"如果用户想要…该怎么办?"这将在用户想要什么方面带来复杂的特征和困惑.观察用户能够消除这种困惑.
你将看到用户阻塞在哪里.当你发生阻塞时,你会到处查看.当用户阻塞时,他们会缩小他们的焦点.对他们而言,在屏幕之外的地方寻找解决方案变得更加困难.这就是为什么帮助文档是一个不好的解决方案对于不好的UI设计的原因之一.如果你必须做一个指示或者帮助文档,确信放在问题区域的附近.用户狭小的注意力焦点解释了为什么工具栏比帮助菜单更有用.

用户倾向于得过且过.他们将找到一个好使的方法并且忍耐下去无论问题多么复杂.去提供一个真正明显的方法去做事情好过提供两个或三个快捷方式.你也将发现用户说的他们想要的和他们真正想要的是不一致的.这是令人担忧的,因为收集用户的常规方法是问他们.这就是为什么获取需求的最好方式是观察用户.花一个小时去观察用户比花一天猜测他们想要什么更加有用.

–Giles Colborne