如何将用户反馈转化为问题陈述.docxVIP

如何将用户反馈转化为问题陈述？ 问题陈述，是一个理论上的神奇概念，一个简单的、准确的、毫无偏见的陈述，在理论上能够层层推进，直至核心并用精准的方案打断无关的陈述。 但是如果你曾在一个团队工作过、或者跨团队合作过，你可能会发现你处在一个这样的环境：给你的反馈意见从四面八方而来，你像玩杂耍一样接住它们，处理反馈的各种团体就像是观众一样围观着你，并且他们也没有为你鼓掌，如果你知道我在讲什么的话。 Problem statement：问题陈述，简单地说，就是一群人或一个人所面对的问题。在学术领域，问题陈述一般用来表达研究目的；在教学领域，问题陈述主用于提出数学或其它教学问题。在日常做计划的过程中，问题陈述是将现实存在的问题表述地更加具体化，目的在于寻找解决问题的方法和途径。 市场营销运营部门希望你处理评价功能，客服想让你加上一个功能使得每个人用户都可以表达意见，CEO希望尽快看到这个新功能。你打算去哪里找时间写问题陈述？ 我已经阅读了无数篇关于如何编写问题陈述的文章，鉴于此，问题陈述多数用“我们该如何”进行描述，“我们该如何…”这样的开头真的理清楚问题的来源了吗？在这个过程中我又是何时真正地创建了问题陈述呢？ 我们生活在一个具有大量新工具来收集反馈的世界。但是，这些工具是怎么结合在一起给我们使用的呢？ 反馈是如何变成问题陈述的？ 2020年，我试图在自己的团队中解决这个问题；并且有了一些进展，目前还在进行中，并且我发现这个进展对如何处理四面八方来的反馈，处理争执很有用。 在我们开始讨论核心内容之前，我想要概述一些其他文章的内容，但这内容可以帮助你们理解我今天的主题，而且如果在后面讲的话，将会很生硬且难以理解。 我认为问题陈述分为三种不同的类型。 你有没有产出过看似产生不了任何结论结果的问题陈述？你已经有一堆解决方案可以来回答这个问题陈述，但是直觉上你仍觉得他们都并不能解决问题。 你可能会遇到难以总结表述问题的情况。用来表述问题的方式有很多，方法的选择会极大地影响后续的解决方案。让我们假设一个可能的基本场景： 一家公司正在调研他们的用户注册环节的转化情况，发现用户量在注册第三步就显著下降，因此产品团队决定将其定义为问题陈述，但我们该如何写这个问题陈述呢？ 将其写成一个商业问题：我们该如何在第三步增加转化率（这是业务方想要从解决方案中得出的） 将其写成一个设计问题：我们该如何在第三步减少决策疲劳（这是对设计师的挑战） 将其写成一个用户问题陈述：我们该如何让用户更快地体验产品（这才是用户真正想要的） 思考一下你在团队内部试图解决的一个问题，并从这些角度考虑它们。让我们先把它搁置一下，我们稍后再进行讨论。 为了陈述残酷的现实，对双钻模型的轻微调整 你应该对用来解决问题的双钻模型方法很熟悉。该方法（在1996年由美籍匈牙利语言学家Béla H. Bánáthy提出），由尼尔森（Jacob Nielson）在用户体验领域推广。所有的不同领域都遵循这一方法，这个方法最适合每种独特的业务类型（如B2B——对公商务模式,B2C——对个人客户商务模式等）。 双钻模型示意图 通过发散和收拢来发现问题；在通过发散和收拢来得出解决方案，这是一个简洁且优雅的设计过程。 但这个模型经常有一个点困扰着我。第一个钻石的开始，几乎暗示着问题从单一的源头产生，即某种用户洞察源头。 但是在实际工作里，你知道的，我之前讲的问题反馈在用户洞察之前就有了。所以让我们把这个模型调整一下，轻微地打开它的开头处，让它从一个灭火器变成一个漏斗形状。 修正后的双钻模型图 让我们把第一部分修正后的“问题漏斗”模型分解为三个操作步骤。 我们从尽可能多的来源收集尽可能多的问题。 我们将收集到的问题反馈分组并筛选，并作出初步问题的陈述草稿。 我们将这些问题和业务一一对应并确定问题的优先级。 双钻模型的第一部分分解为三个步骤 在我们继续之前，我想强调这个漏斗模型非常适用于已投放市场的产品进行新的功能迭代。如果你是想找还没上市场的产品的问题，那完全是另一码事，我会在另外一篇文章中说明这类产品的问题陈述，所以请继续关注。 1. 步骤一：收集 首先，你需要坐下来，并列出你产品得到所有反馈的来源。这是一件乏味的事情，建议你在做的时候喝一杯咖啡。请注意一件事，这些产品反馈的来源并不是显而易见的。 你有客户成功经理吗？你有客服（客户支持）团队吗？客户会像川普一样在 Twitter 上你发送表达他们愤怒的反馈信息吗？ Customer Success Manager：客户成功经理（CSM），指品牌在产品之外向客户提供的全程指导咨询服务的顾问人员；往往具备高度的专业知识，指导客户更好的使用产品、解决产品应用中的问题、提供最新产品升级信息，从而支持产品的最佳化使用。 一旦你有了一个反馈来源清单，你可以在你的日历计划中