作为Mobile Majority 的用户体验团队的负责人，让我们的产品在移动端平台上可用、易用、直观，并帮助用户达到他们的营销目的是我的职责。

当然，在没有获得用户反馈的时候，我们并不能确知我们的思路和产品是否真正迎合用户的需求。所以我们开辟了许多沟通的渠道，我们通过邮件、电话、服务请求、销售人员和客服经理等各种各样的方式来获取各类反馈。通过这些反馈，我们能够知道哪些用户体验设计会让用户觉得痛苦、感到挫折，毕竟他们的使用频率更高，更容易碰到问题、发现我们未曾注意的盲点。

但是有一点很重要：我们不能按照用户所说、所要求的那样做设计。

“难道我们不应该构建令用户愉悦，帮他们达成目标的产品么?”你可能会这么想。

对，这并没有错，做好设计并不意味着我们得准确按照“用户所说”来做设计。

太多的设计师在不经过仔细质疑、研究、思考、总结，就直接根据用户反馈，简单地按照需求来执行。

这就像面对一个喜欢吃糖的小孩，由着他的性子投食只会让他长蛀齿，合理膳食才能保持健康。做设计是一样的道理。

绝大多数的普通用户无法确知他们真正需要的是什么，他们只会将他们认为重要的东西告诉你，两者之间有着明显的差距。对，人们说的很多，但是很少按照诺言来践行，少有人能够真正预期他们的未来。明天开始减肥、明天开始运动、明天收拾桌子、明天早上按时起床，然而第二天并没有什么改变，和第一天没有区别，绝大多数人是这样。这里要说的并不是拖延症和谎言，而是真正的需求和自己认为的需求，并不一致。

人们高喊着要更快的马，而你制造的应该是汽车。接下来，我们聊聊为什么我们应当设计人们需要的，而非人们想要的。

用户认为他们想要的东西

用一个典型的案例来说明问题吧。我们曾收到一个用户的反馈，他想知道每一个项目每天的详细情况，什么时候开始，什么时候结束，什么时候过半，运作状况好坏，开局是否顺利，收尾是否利落，是否按时完成。所以如果按照他的要求，那么他所需要的通知邮件应该是这个样子：

不过有时候同时进行的项目不止一个。想想同时有20个移动端的项目进行会怎样吧。且不说用户他所提出的需求好坏，20个邮件每天同时发送到他的邮箱，这些邮件没有任何的可操作性，也不具备任何可组织整理的可能，即使作为回执，对于邮箱也是巨大的负担。

所以，我们真正要搞清楚的是他们真正的需求，而不是简单的按照他们所说的去做。我们不妨再深挖一下，我们需要知道问题的根源：他们为什么会提出这样的需求，他们为什么想要这些邮件(即使他们根本没想过他们是否能处理的过来)。

“别纠结他们所说的需求——搞清楚他们为什么会提出这些需求才是当务之急。”

为了做到这一点，我通过亲自面试并对聊天过程进行了视频记录。通过筛选和分析之后，我们了解了他们的唯一的根本需求：他们只是想知道他们的项目是否正常地运作。

对，这就是访谈和面试的意义所在，这是获得用户反馈的最佳方式：听他们说，了解想法，观察用户的一举一动。

无论是观察他们使用实际产品，如何完成特定任务，每一次观测都可以让你更深入了解他们的目标，也能让你更清醒地认识到你怎样才能帮到他们。

通过这些访谈，我观察到最值得注意的一点是，几乎所有用户都喜欢在早上登录我们的平台，观察每一个项目的细节，并且试图找到任何异常的情况。在我看来，这一用户习惯非常值得利用。

给用户真正需要的东西

所以，通过大量的研究之后，我们决定设计一个能替代这些电子邮件的有效工具，来满足用户的真实需求。所以我们并没有设计一套自动的邮件系统，而是集成在系统中的通知体系。

我们在顶部全局菜单栏的右侧提供了一个通知的分类，它是轻松可见的，并且不是干扰性的通知方式。自从知道我们的用户会每天登录平台，只需要通过通知栏给他们推送信息即可，任何异常活动或者重要的信息都通过它来告知用户。

我们充分利用用户的这一使用习惯，来实现了这个基础功能，这不仅解决了许多用户之前提到过的问题，而且预防了许多未曾料到的障碍。

对于用户体验设计师、工程师和产品经理而言，获取用户反馈是最重要的事情之一，而观察用户直接使用产品所获得的反馈是最直接的，这种用研最好频繁地进行。

但是千万不要简单依托用户口头反馈就简单作出设计方案，记住，用户本就很少按照自己的说法来做事，也无法确知真正的未来。对于这些反馈，仔细思考，深入研究，找到他们这么说的原因，找到症结才是核心。

当我们的用户有了这个通知系统之后，确实被感动到了。有部分用户坦言他们确实没想到这个方案，并称赞了我们的设计和考量。能帮助用户完美地解决问题，就是设计师的成就感的来源。