用户反馈系统(用户反馈平台)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

双钻模型示意图

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

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

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

修正后的双钻模型图

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

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

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

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

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

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

例子：白板

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

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

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

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

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

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

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

例子：反馈分组

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

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

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

在Trello上写的用户问题

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

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

让我来解释一下。

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

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

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

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

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

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

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

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

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

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

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

题图来自 Pexels，基于 CC0 协议