编程的97件事——3多问“用户会怎么做”（你不是用户）

Posted 2020-09-10

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

---

多问“用户会怎么做”（你不是用户）

 

我们都倾向于认为别人和我们想得一样，然而并没有。心理学家将这种现象称之为虚假同感偏差。当别人想得或做得和我们不一样，我们很大可能会（下意识的）给别人贴上某方面有缺陷的标签。

 

这种偏差解释了为什么程序员难以站在用户的角度，用户不会像程序员那样思考。首先，他们使用电脑的时间少的多。他们不清楚也不关心电脑是怎样工作的。这意味着他们不会像程序员那样熟悉各种技术问题。他们不认识程序员围绕接口工作时使用的模型和提示信息。

 

了解用户想法的最好的办法是直接观察。请用户使用和你正在开发的类似的产品完成一个任务。确保这是一个真实的任务：“添加一列数字”可以，“计算你上个月开销”更好。避免太细节的任务，例如“你能选择这些单元格并在下面输入求和公式吗？”—提示过于明显。让用户描述任务进行的过程。不要打断，不要试图帮忙。不断地问自己“他为什么要这样做？”、“她为什么不那样做？”

 

首先你会发现用户们用相似的方式完成核心事务。他们会尽量用同样的顺序完成任务—然后在同样的地方犯同样的错误。你应该围绕这种核心行为做设计。这不同于设计会议，人们在会上讨论“如果用户想要这样做该怎么办？”，这导致了过于纠缠于细节，不能看清用户真正的需求。直接观察用户可以消除这种迷惑。

 

你会看到用户卡住了。当你卡住的时候，你会四处看看。当用户卡住时，他们会聚焦于卡住的地方，这让他们在屏幕其他地方寻找解决办法更加困难。这就是为什么对于糟糕的界面设计帮助文本是一种糟糕的解决办法。如果你一定要使用提示信息或帮助文本，确保将它们放置在发生问题的区域旁边。用户能够注意的范围非常有限，这就是为什么提示工具栏要优于帮助菜单。

 

用户倾向于得过且过，他们找到一个可以工作的套路，无论它多么别扭，都会坚持使用下去。提供一个足够明显的操作流程，要比提供2到3条捷径更好。

 

你还会发现用户声称他们想要的和他们实际想要的之间的差距。这是传统的问卷调查令人担心的地方。这就是为什么最好的捕捉用户需求的方式是直接观察他们。花一个小时观察用户比花一整天猜测他们想要什么能获得更多有价值的信息。

 

后记：本篇内容较为简单，没有技术门槛，却是我们技术人员最常忽视的，写程序时将这些记在心里，会少走不少冤枉路。