用户体验研究对于产品设计来说至关重要，其中倾听用户的观点和想法是必要的，但是用户作为非专业人员，在产品设计方面具有一些认知障碍，他们的观点和想法或许会带有一些主观色彩。所以，设计师在做产品设计时，要对用户意见有一个全局性的思考，不过度迷信用户意见。

多数用户体验设计师认为：让用户参与到产品的创造与改进中来是一个必不可少的环节，他们招募用户来了解他们的需求、使用痛点、改进产品的想法以及自认为必要的功能。

但这实际是有风险的，因为让用户参与到产品开发过程中的目的是为了更好地了解用户，而不是真的让他们做出决定。这需要充分的准备，以及对于定性数据的慎重分析。

问题就是：多数设计师没能很好地处理这一点，而是倾向于做出一些快速决策和改进。

为什么不该一味听信用户？

用户表述很可能会成为设计人员验证自己现有观点或偏见的工具，这并非出于恶意，而是多数企业都在鼓励做快速决策。

设计师可能会直接攫取用户的表述，来证实自己已经相信的想法，然后做出决定并推进开发，而不是尝试以全局视角理解用户的生活状况。这会让我们无法从用户身上获取真正有价值的研究结果。

设计师不应该问用户想要什么，而应该具备一种能构想出产品不同设计方案，并从中选择最优解的眼界。同时，知道自己的产品可以如何解决用户遇到的问题，改善他们的生活状况。

用户在真正看到和上手使用一个新产品前，是无法认识到它的价值或自己对它的需要的。当他们尝试后，才有可能爱上这款产品。

倾听用户是一件难以把控的事情，用户通常并不知道自己真正要的是什么，即便知道，在沟通中也可能存在表述与理解偏差。

设计师一般通过结构性与非结构性的手段收集反馈，前者是由设计师提前构想反馈内容的分析方法，备好提纲以获取预期的信息。

但在这种情况下，提纲有可能会将用户反馈限制在一个特定的范围内，客观性就会下降。而非结构性的反馈收集方式又会让后续的数据处理变得困难重重。

如果将用户期望的东西都实现只会让你的产品愈加复杂，甚至于，那些让你添加功能的用户也不会用你的产品。

一般来说，设计师会询问并记录用户在使用产品中碰到的问题，但却忘了去了解哪些设计是有效的。他们通常认为用户没抱怨的地方都没问题。

设计师问错问题或问太多问题时，就会误导潜在用户，导致用户无法理性、客观、诚实地回答问题。

设计师通常会偏信掌握话语权的人，这种现象很常见，且通常会在团队中出现。在讨论设计稿或原型时，设计师可能会把注意力集中在那些掌握话语权的人身上，而忽视了其他人。

当用户产生误解或碰到产品可用性问题时，设计师不能完全依赖于用户提供准确无误的反馈。因为在回答设计师的问题时，没有用户能够主动地思考那些细节。或是他们可能会试图在「咄咄逼人的」设计师面前展现出更好的一面，因此给予有偏差的反馈。

用户会说：“这里加一个按钮，我就可以……”如果设计师能够继续深究问题，也许会意识到这个用户期望实现的动作，其实可以自动为用户完成，根本就不需要在界面上再徒增一个按钮。

那该怎么做？

我们可以通过观察用户与界面交互的行为来判断哪个设计更优。

这个方法非常简单，但许多人却忽视了它的价值，总想着通过其他方法来做可用性测试。

可用性测试可归结为以下三个基本法则：

1. 观察用户的真实行为。
2. 别相信用户说他们会怎么做。
3. 更不要相信用户预测他们未来会怎么做。

任何数据（包括用户反馈和量化数据）都可能是有关的，但如果你收集的不是有效数据（或数据量不够），那么，你的行动可能依然会基于猜测或个人经验进行。

因此，当设计师将更多注意力放在用户的真实行为时，才能设计出用户体验最佳的产品。

自我报告通常是不可靠的，用户对于自己未来行为的预测也一样。用户不知道他们真正要什么，也不会知道他们使用新产品时会有什么反应。通常情况下，他们会表现出与日常生活截然不同的行为。

总之，通过观察用户与产品的真实交互行为是最重要的获得用户反馈的方法。但这并不意味着可用性专家就不需要倾听人们的想法，而是应该在观察用户行为后再听听他们的感受。

不论是记录用户数据、倾听他们或是观察他们使用产品，最为行之有效的方式还是让他们在进行操作的同时“发声思考”，说出自己的想法。这可以让你了解到更多产品的不足，以及真正了解普通用户的思维模式——他们的想法往往与你的想法存在差异。

即便如此，人口统计学数据的分析（不论是在实验室还是实际场景中）依然是产品设计与优化中的主要部分，而观察用户真实行为则是可用性测试的基石。

有一些设计者会谨小慎微地听取用户意见，记好笔记，会意地点头，答应满足他们的需求，然后按照自己认为产品应该的样子做出来，再努力说服用户：这就是你们想要的产品。

但如果你听取了上文的建议，就不需要这样做了。

多说一点

讲一个小故事：

二战时期，同盟国面临着一个问题：战机在执行轰炸任务时的坠毁率超出50%。

他们尝试研究返航的战机机身，查看各部位的损坏程度，进而判断出哪里最需要加固。然而，坠毁率并没有因此下降。

问题就在于：他们研究的是归来的战机而不是坠毁的战机，因为还能回得来的战机身上的损坏部位显然并不致命，他们需要的是坠毁的战机的数据。

数据采集是必要的，但要确保你所获取的数据是准确并有效的。

如果条件允许，可考虑使用一些产品内的可用性观察手段：

1. 内部审核跟踪（Internal Audit Trail）

用户所有的行为变化数据都会被记录到产品的数据库中，包含有：日期时间、原始数据表格、改变的字段列名、原数值、新数值、“从哪个页面跳转？”以及，“谁的行为发生了改变？”。

通过它可以了解到：用户真正使用的是哪些功能？以及，到底是哪些人在使用你的数字产品？

2. 内部事件日志（Internal Event Log）

不论是产品异常，或是用户的登录登出，都会记录在日志中。你就可以知道哪些人登录了产品系统，有多少人成功登出，或是放着等待会话过期。由于数据记录了用户ID、登录时间以及事件发生的日期与时间，设计师与程序员也可在「审核跟踪」数据中找到相应的信息。

所以，有时候其实可以通过详细的用户日志了解用户的真实行为，而不需要直接观察用户（虽然这么做也是有用的）。

关键是日志只能反映出用户做过什么，而直接观察用户可以让你知道用户会花多少时间完成一个操作决定，从而了解你的产品体验如何，交互界面是否让用户产生困惑。

通过面对面的沟通，你还能了解：用户当时想做什么？以及，他们的实际行为。

举个例子：日志可以告诉你网站地图中的点击数是多少，但它并不告诉你用户是不是不小心来到这个地方，或者用户选择这个路径是不是因为他不理解导航栏的提示。

总之，不要盲目地相信你的用户！

内容原创作者：Maxim Grozny，翻译：F.Lee

译文地址：http://uxren.cn/?p=61229

本文由 @黑眼镜的猫 发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议