作为ThoughtWorks的一名用户体验设计师，我做过很多不同的产品。我常常发现项目组早已列出了一系列他们想要实现的功能，而在工作中，他们只是在寻找一个新办法去改进设计流程，让其变得更有效。通常我会从他们列出的功能中找出一个，然后问他们一个简单的问题：“这个功能为用户解决了什么问题？”，这个问题往往就能把他们难住。

接下来，我能看出他们脸上的疑惑。 为什么在已经有解决方案的情况下我还要去了解问题？我们不是在走回头路么？这感觉是在浪费时间，让我们这样做的家伙是谁啊？

然而，我一次又一次的发现，由于不了解问题，项目组迷失了方向。而当我尝试让大家简单地去了解问题时，我又一次次的感受到了巨大的阻力。为什么人们会对了解问题如此抗拒？了解问题真的这么重要吗？要怎么样做才能让他们茅塞顿开？

为什么我们不重视理解问题

问题都是抽象的。所有的问题都会引发各种疑惑、假设，以及理解上的缺失；它们会让我们感到不安。而解决方案把这些抽象的事物变得具体，同时也明确解答了一些疑惑，即便有些回答只不过是猜测。无论如何，解决方案让我们感到开心和愉快。

我们的大脑非常擅长于直接给出解决方案。为了更有效率的沟通， 我们常常需要直接给出解决方案。我们常常潜意识的按照需求将不同的细节组合起来形成一个可能的解决方案。具体的东西往往比抽象的更容易让人理解。比如，你不会说，“我的身体告诉我，我想吃点好吃的。”你只会说：“去吃pizza吧。”

因此，直接给出解决方案是可行的，在很多情况下也是必要的。然而，在开发软件产品的过程中却不能这样。

理解问题的好处

在产品开发过程中，如果直接把解决方案作为讨论内容，带来的问题是讨论没有包含问题本身。当人们第一次听到某个解决方案或某个功能的时候，会试着逆向还原用户的问题。接着，他们会根据自己的理解解释这个问题的重要性及成功的标准。然而，每个人逆向还原的过程可能都是不同的，因此从一开始，大家就没有一个明确而统一的目标。随着项目的进行，人们就不得不在细节上互相妥协，并且在MVP的功能构成上争论不休，因为大家推测出的问题和优先级都不一样。这种情形就像你们在用不同的语言交流一样。

在和组织其他人沟通的时候，真正理解用户的问题也是一个非常有用的工具。如果你考虑的只是解决方案，就会拘泥于功能上的对错。而如果你关注的是有衡量标准的问题本身，就可以根据市场反馈来修正策略。只要你们在朝着这个重要的目标前进，用什么具体的功能实现这个目标的其实并不重要。

定义问题的过程

描述一个问题并不会花太多的时间，重要的是要和设计师、开发人员、产品相关人员以及市场需求人员一起合作。这样才能让大家对这个问题有共同的理解，同时也能在验收条件上达成一致。

在描述问题之前，我建议先给大家展示一些相关的调查，并且审视一下当前的市场竞争。不用太关注细节，能够提供市场的大致情况就好，这能够让你知道目前市场的机遇在哪里。如果你是在改进一款现有的产品，请把带有截屏的流程图贴在墙上，也把竞争对手的也贴上，然后和大家一起研究一下。

然后就可以和大家一起来描述问题了。我喜欢用下面的形式，这是我从 Jeff Gothelf 的 《Lean UX》一书中得到的一些灵感，他在书中写到：

产品为用户提供了实现目标的途径。我们发现有些产品并不是为了解决问题而设计的，这往往对产品产生了不良的影响。让用户真正满意的产品是针对问题而设计的，这体现在产品的可度量的验收条件中。

在描述问题时，可以不拘泥于某种形式，但应该含有下面的要素：

• 目标用户

• 目标用户的目标

• 目标用户现在是怎么解决问题的？该解决方案的缺点是什么？

• 如何给用户提供一个更好的解决方案？

• 用于评估结果的可度量的验收条件

现在大家终于有了共同的起点，可以开始评估解决方案和讨论用户意图了。把之前描述的用户问题贴在团队周围的墙上，并经常参考。同时，也让项目之外的人看看这些问题，听听他们的意见。在回顾解决方案的时候，鼓励每一个人对这个解决方案提出反馈。