编辑导语：用户在使用产品的过程中，总会产生各种各样的问题或反馈，此时团队人员要如何从用户反馈中提炼出可理解的陈述问题，以便后续产品的迭代优化、提升用户的使用体验？本篇文章里，作者就该问题进行了解答，一起来看看吧。

问题陈述，是一个理论上的神奇概念，一个简单的、准确的、毫无偏见的陈述，在理论上能够层层推进，直至核心并用精准的方案打断无关的陈述。

但是如果你曾在一个团队工作过、或者跨团队合作过，你可能会发现你处在一个这样的环境：给你的反馈意见从四面八方而来，你像玩杂耍一样接住它们，处理反馈的各种团体就像是观众一样围观着你，并且他们也没有为你鼓掌，如果你知道我在讲什么的话。

Problem statement：问题陈述，简单地说，就是一群人或一个人所面对的问题。在学术领域，问题陈述一般用来表达研究目的；在教学领域，问题陈述主用于提出数学或其它教学问题。在日常做计划的过程中，问题陈述是将现实存在的问题表述地更加具体化，目的在于寻找解决问题的方法和途径。

市场营销运营部门希望你处理评价功能，客服想让你加上一个功能使得每个人用户都可以表达意见，CEO希望尽快看到这个新功能。你打算去哪里找时间写问题陈述？

我已经阅读了无数篇关于如何编写问题陈述的文章，鉴于此，问题陈述多数用“我们该如何”进行描述，“我们该如何…”这样的开头真的理清楚问题的来源了吗？在这个过程中我又是何时真正地创建了问题陈述呢？

我们生活在一个具有大量新工具来收集反馈的世界。但是，这些工具是怎么结合在一起给我们使用的呢？

反馈是如何变成问题陈述的？

2020年，我试图在自己的团队中解决这个问题；并且有了一些进展，目前还在进行中，并且我发现这个进展对如何处理四面八方来的反馈，处理争执很有用。

在我们开始讨论核心内容之前，我想要概述一些其他文章的内容，但这内容可以帮助你们理解我今天的主题，而且如果在后面讲的话，将会很生硬且难以理解。

我认为问题陈述分为三种不同的类型。

你有没有产出过看似产生不了任何结论结果的问题陈述？你已经有一堆解决方案可以来回答这个问题陈述，但是直觉上你仍觉得他们都并不能解决问题。

你可能会遇到难以总结表述问题的情况。用来表述问题的方式有很多，方法的选择会极大地影响后续的解决方案。让我们假设一个可能的基本场景：

一家公司正在调研他们的用户注册环节的转化情况，发现用户量在注册第三步就显著下降，因此产品团队决定将其定义为问题陈述，但我们该如何写这个问题陈述呢？

将其写成一个商业问题：我们该如何在第三步增加转化率（这是业务方想要从解决方案中得出的）将其写成一个设计问题：我们该如何在第三步减少决策疲劳（这是对设计师的挑战）将其写成一个用户问题陈述：我们该如何让用户更快地体验产品（这才是用户真正想要的）

思考一下你在团队内部试图解决的一个问题，并从这些角度考虑它们。让我们先把它搁置一下，我们稍后再进行讨论。

为了陈述残酷的现实，对双钻模型的轻微调整

你应该对用来解决问题的双钻模型方法很熟悉。该方法（在1996年由美籍匈牙利语言学家Béla H. Bánáthy提出），由尼尔森（Jacob Nielson）在用户体验领域推广。所有的不同领域都遵循这一方法，这个方法最适合每种独特的业务类型（如B2B——对公商务模式,B2C——对个人客户商务模式等）。

双钻模型示意图

通过发散和收拢来发现问题；在通过发散和收拢来得出解决方案，这是一个简洁且优雅的设计过程。

但这个模型经常有一个点困扰着我。第一个钻石的开始，几乎暗示着问题从单一的源头产生，即某种用户洞察源头。

但是在实际工作里，你知道的，我之前讲的问题反馈在用户洞察之前就有了。所以让我们把这个模型调整一下，轻微地打开它的开头处，让它从一个灭火器变成一个漏斗形状。

修正后的双钻模型图

让我们把第一部分修正后的“问题漏斗”模型分解为三个操作步骤。

我们从尽可能多的来源收集尽可能多的问题。我们将收集到的问题反馈分组并筛选，并作出初步问题的陈述草稿。我们将这些问题和业务一一对应并确定问题的优先级。

双钻模型的第一部分分解为三个步骤

在我们继续之前，我想强调这个漏斗模型非常适用于已投放市场的产品进行新的功能迭代。如果你是想找还没上市场的产品的问题，那完全是另一码事，我会在另外一篇文章中说明这类产品的问题陈述，所以请继续关注。

1. 步骤一：收集

首先，你需要坐下来，并列出你产品得到所有反馈的来源。这是一件乏味的事情，建议你在做的时候喝一杯咖啡。请注意一件事，这些产品反馈的来源并不是显而易见的。

你有客户成功经理吗？你有客服（客户支持）团队吗？客户会像川普一样在 Twitter 上你发送表达他们愤怒的反馈信息吗？

Customer Success Manager：客户成功经理（CSM），指品牌在产品之外向客户提供的全程指导咨询服务的顾问人员；往往具备高度的专业知识，指导客户更好的使用产品、解决产品应用中的问题、提供最新产品升级信息，从而支持产品的最佳化使用。

一旦你有了一个反馈来源清单，你可以在你的日历计划中留出一周一次的时间来检查这些反馈。

当到达这个阶段，你可能会想我该如何收集整理这些反馈？比如，我该使用什么工具，这取决于你和你的团队，但我喜欢尽量让它简单化。

我截图或引用用户原话，并把它们贴在Miro在线白板上（见下图）。

Miro Board：一个提供在线白板的网站，用户可以把自己的想法贴在上面进行可视化整理。

例子：白板

我用不同的方式来处理不同的来源信息。比如，我用便签代表每个用户访谈和研究；同时我用截图来处理用户评论，这样可以看到用户的打星评价。

但实际上，这一步的目标是把所有的信息放到同一个地方以便进行分组。

专业提示：如果你的用户反馈来自你的同事们（比如客服），请预定每周签到提醒，并请他们把每周收到的任何反馈以截图的形式保存并发送给你。（你可能需要请同事们吃点心，但是，这只是很小的代价）

2. 步骤二：分组&筛选

在收集了大量的反馈之后，我们需要开始对它们进行分组，但是，并不是所有反馈都是一样重要的，所以请记住先筛选。

筛选前需要确保每个反馈都满足以下四种属性：

单独的：确保一条反馈来自一个用户，而不是多个用户。多样化的：确保反馈不是来自同一个用户在多个平台上的同一投稿。无偏见的：确保反馈不受内部意见的影响，尽量确保它代表了用户。可阅读的：保证可以即使脱离环境也能够被理解，这有助于分组。

例子：如何改进你的用户反馈陈述

现在是时候对反馈进行分组了。

首先将类似主题的反馈放在一起，并对其进行简短的描述。不要把它们写成问题陈述，请记住将这些分组保持开放，以便进行改变。

例子：反馈分组

如果一条反馈不适用于任何已有的分组，请不要删除它或硬把它放到某个组。保持这条反馈未分组的状态，因为随着更多的反馈出现，你可能会改变你的想法。

3. 步骤三：配对

在这篇文章的开头，我提到了不同类型的问题陈述——商业问题、设计问题和用户问题——这些问题都有其存在的地方，但是任何问题陈述都需要在一开始当成一个用户问题来写。

在这里你可以关注无数篇关于如何写出好的问题陈述的文章。

这里有一个在Trello上的例子：

在Trello上写的用户问题

好，干得不错！我们现在有了问题陈述！但我们还没有完成，我们缺失了这一部分内容：

如果没有相应的业务问题，用户问题将无法被进行优先级排序。

让我来解释一下。

如果你尝试基于路线图来对用户问题进行优先级排序，你最终可能会以非常昂贵的方式实现功能。

roadmap：路线图。指一种战略计划，它定义了目标或预期结果，并包括实现该目标所需的主要步骤或里程碑。

举一个例子，假设你在用户注册环节发现存在的一些问题，并获得了大量的反馈，但是你的用户留存率也被打破了，所以你修复了用户注册环节的问题并获取了更多用户。但是当用户在你的产品中离开时，你失去了（获取到的）所有的用户。这是多么昂贵的修复啊。

所以，让我们把每个问题陈述和业务问题一一关联起来。

4. 业务问题

业务问题应该在长期的OKR管理，V2MOM管理或者季度考核管理中进行设置，这具体取决于公司的结构，但是在理想的情况下，它们以考核指标的方式展示，例如每日活跃用户增加 10%，降低客服处理数量等。

OKR:指目标与关键成果法（Objectives and Key Results），是一套明确和跟踪目标及其完成情况的管理工具和方法。

V2MOM:公司管理模型，代表愿景（Vision），价值（Values），方法（Methods），障碍（Obstacles），衡量标准（Measures）的组合。也是一种意识的练习，它最终的结果是聚焦和对齐。此外，它有一个明确的方向，将全员的能量集中在期望的结果上，由此来消除变革时代所带来的焦虑。

如果你了解更多关于如何设置指标驱动产品目标的话，你可以阅读我的另一文章。

以用户为中心并不意味着你只解决用户问题，而是意味着你解决的每个业务问题都有一个相对应的用户问题。

当你将它们就像这样关联起来（见下截图），用户问题变得更容易管理。更重要的是，这样能更容易与利益相关者沟通并关联对应的客服反馈工单。

用户问题有对应的业务问题

我讲完了。我希望这篇文章可以帮助到那些一直致力于关注并解决用户问题的人。如果你有任何建议或者反馈，请留下你的评论，无论如何祝你工作愉快！

本文翻译已获得作者的正式授权（授权截图如下）

原文作者：Zandre Coetzer

原文地址：https://uxdesign.cc/how-to-funnel-user-feedback-into-problem-statements-c3b940e2cecc

译者：陈羽姿；编辑：李莉好；：TCC翻译情报局（ID：TCC-design）；连接知识，了解全球精选设计干货

本文由@TCC翻译情报局 翻译发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议