0%

问“用户需要做什么?”(你又不是用户)

我们总倾向于假定其他人也和我们一样思考。但其实不是。心理学家把这种现象称为“错误共识效应”。当别人和我们有不同的见解和行为的时候,我们很可能会在潜意识里给他们贴上SB(not english)的标签。

这种偏见解释了为什么程序员很难站在用户立场。用户不会想程序员一样思考。首先,他们平时用电脑就不多。他们既不知道也不关心电脑是如何工作的。这就意味着他们无法用任何程序员熟悉的问题解决技术。他们无法识别程序员围绕界面产出的模型和提示。

观察用户是了解用户的想法的最佳方案。请求用户使用一款与你正在开发的相似软件来完成任务。确保任务是真实的:“添加一列数字”即可;“计算你最近一月花费”那就更好了。要避免太特殊的任务,“您可以选中这些表格但愿并在最下方编辑求和公式吗?” - 这个问题有个很大的线索。让用户谈他/她的进展。不要打断!不要试图给予帮助。不断问你自己“为什么他会这么做?”以及“为什么她不这么做?”

你首先要留意用户在做相同事情的核心。他们以相同的顺序完成任务 - 并在同样的地方犯同样的错误。你应该围绕这些核心行为做设计。这与设计会议不同,设计会议倾向于听一种声音“如果是用户,他们想要什么…?”这将导致进一步细化功能然后一直惑于用户想要什么。所以,观察用户并消除这些困惑。

你将看到用户卡壳的时候。当你卡壳了,你会环顾四周。当用户卡壳了,他们会缩小注意力。对他们而言想从屏幕的其他地方找到解决方案是更困难的。其中一个原因就是帮助文就是个垃圾的用户界面。如果你有指导手册或帮助文档,要确保能够正确定位到问题。因为用户的注意力会集中到为什么工具提示要比帮助菜单更有用。

用户总是糊里糊涂的,无论有多复杂,它们总会找到一种方式坚持下去。所以最好仅提供一种明显的做事方法,而不是两三种快捷方式。你总能发现用户表达他们想要的和他们实际做的是有差距的。通常召集用户问它们需要什么是很糟糕的方式。这也是为什么观察用户以捕捉他们真正需要的才是最佳方案。花一个小时观察用户要远远好过你花一天时间来猜测用户想法,前者可以获得更多真正有效信息。

小小鼓励,大大心意!