如何根据数以千计的用户洞察做出最佳的产品决策

▲点击 "TCC翻译情报局" 关注，回复 "社群" 加入我们

本文共 4633 字，预计阅读 12 分钟

TCC 情报局的 第 82篇 干货分享

2021 年的 第 70 篇

TCC 推荐：大家好，这里是 TCC 翻译情报局，我是李泽慧 。管理用户的功能需求和意见洞察是非常困难的 。以正确的方式整理这些数据能帮助我们更好地利用这些有价值的信息。不是所有的整理方式都是有效的，你需要关注痛点而不是解决方案。 这个步骤会帮助我们更好地规划产品各个阶段并且关注在用户调研上，然后为用户创造更多的价值。

这些天我们获取了许多关于产品的定量和定性数据。这些数据无处不在，你可能做了许多用户访谈，从用户调查问卷中获取反馈，或者使用其他方法来获取数据。同样，用户也给我们提出了许多功能需求或者对产品提出了许多问题。用户确实通过这些让我们了解他们的想法和困难。收集完这些数据之后，你将拥有一个海量而杂乱的数据库等待被使用。

我们都知道 用户洞察是制定产品策略的基石之一。用户洞察是十分有价值的，因为我们可以根据这些来制定产品阶段性目标，并且创造出最大的价值。然而，你需要很小心得使用这些数据，否则你将会做出错误的决策或者最终根本没有发挥这些数据的价值。如果没有很好得使用这些数据，难道不是错失了一个良好的机会吗？

“所以，你想要分析这些用户洞察数据吗？首先，你需要整理它们....”

严肃的说，你需要用某种方法使用这些数据并从海量的数据中理解用户的诉求和洞察。

我的团队已经意识到这一步的关键在于如何整理这些数据，为了做出数据驱动的产品策略，你需要浏览数据，然后快速地确定需要聚焦在哪一部分数据上。

1. 使用什么方式来整理数据？

1. Can any structure work?

我的团队曾尝试使用一种备受推荐的结构来整理数据，这一年内，我们在根本没有考虑洞察的情况下就做出了产品策略。

这种备受推荐的结构如下：

我们把产品分成几个部分（比如注册/首页），在每个部分下面把从不同渠道收集到的数据以主要功能和其下的子功能的形式标明。遵循这一结构，哪一洞察出现的数量越多，我们就可以 关注这一部分的功能需求并且制定产品阶段性目标（给每个洞察打分会比单纯的计算哪一洞察出现的数量多更加复杂和严谨）

但是这一方法并不奏效，因为一些原因这个方法是误导的且令人迷惑的。

2. 问题所在

2. The problem

1）更快的马还是一辆汽车

这是一个来自 Henry Ford 的著名的故事，Ford 说，如果我问人们他们想要什么，人们会说他们想要更快的马。

这意味着用户不会总是告诉你最佳的解决方法，在这个情境下，给人们一辆车是更加理想的选择，但是你会理解用户的需求并且想出一个更好的解决方案。

“更快的马”是我们使用备受推荐的结构来整理数据时遇到的一个问题，让我来举一个例子。

这是 Jimmy，他正在使用一款视频会议软件，他想要我们加入一个音频故障排除功能。

这的确是一个解决方案，但是问题在于 Jimmy 在音频连接上有太多问题了，在我们这边解决这个问题，而不是让他自己手动解决这个问题是一个更好的解决方式。不幸的是，Jimmy 并没有提出这个更好的解决方式，但是我们不会责备他，因为他并不是专家。

所以想象一下，你一直使用这种备受推荐的结构来整理数据，把每一条需求都放进去，不断得获得越来越多的投票，之后你就决定实现这个需求，可是这个方案并不理想，这根本就不是最佳的解决方案。

2）随处可见的碎片化信息

这是 Katie，她在使用视频会议软件，她说软件加载需要很多时间。

现在我们来看我们的整理结构，我们有许多功能需求可以解决这个问题（比如增强加载指示，修复前端加载问题等）。所以你会把这些需求放在哪里呢？把他们放在一个需求下面，还是两个？不管用哪种方式，你都没有从宏观角度来看问题，我们无法意识到一个问题的重要性，是因为我们把这些碎片放在不同的部分下面且没有统一考虑。

这并不能帮助我们确立问题的优先级。

3. 如何去解决？

3. How to solve this?

让我来给你们展示一种我们 整理定性数据的技巧。在这个新技巧的帮助下，我们可以更快地从产品和调研的角度来关注那些重要的部分。

同时我也附上了团队用户洞察数据整理工作坊的流程，所以你们可以创建自己的整理结构。这个技巧可能适合我们的产品团队，但是可能并不适合你们的，所以让我们来创造自己团队的整理结构吧！

4. 我们寻找理想方法的过程

4.Our way to the ideal structure

首先，让我先来展示一下你已经非常熟悉的 双钻模型。

根据这个流程，首先需要找到你所探究的一般问题，接着，作为一个用户体验研究者，你将深挖问题并且发现更多的问题，然后，你需要决定哪个问题是接下来要着手去解决的。

到这里就结束了吗？还没有！我们仍然需要去寻找问题的解决方案....所以我们会如何做呢？我们开始发散创意去寻找最佳的解决方案。我们最终会拥有许许多多的提案，然后我们从这些提案中找出最优秀的那一个（拥有最高的价值和最少的实现成本）。

这是一个高效且合适的产品设计流程。

从 Jimmy 的想法来考虑，他给出了一个具体的解决方案。现在，我们与其去收集功能需求，然后根据哪个需求获得更多的票数来决定去实现哪个功能，不如尝试另外一个方法，同样也顺应了双钻模型。

根据这个流程，你要从解决方案反向追溯到需要解决的具体问题。在这个例子中，具体的问题就是用户有音频连接问题。知道了问题所在，所以接下来怎么办？现在就到了创意发散环节，我们需要找到这个问题的最佳解决方案。也许你们可以给用户一个音频故障排除指南，或者你们可以自己修复连接的问题。我们这样做得到了什么？我们得到了一个根本问题更多更好的解决方案，我们当然可以确认这些解决方案都是围绕着这个根本问题展开的。

现在最激动人心的部分来了，随着产品的成长，你将会获得海量的用户反馈，这些反馈映射出海量的问题。你需要耐心的去选择哪些需要深挖，哪些不需要。理想情况下，你需要去解决那个最紧迫的问题，实现最大的用户需求来创造最大的价值。好消息是，你现在可以着手去做了！

我们现在，有 100 个问题可以选择去深挖。根据用户反馈的数量和比重以及其他因素（业务目标，用户画像等），你可以选择去深挖哪一个问题。然后你会进行创意发散环节，获得 100 个解决方案。接下来，进行优先级划分，有许多方法去寻找最佳和最终的解决方案。这篇文章并没有涵盖这个部分，如果你有兴趣，可以阅读这篇文章：https://plan.io/blog/feature-prioritization/

太好了！我们有一个解决方案来实施了，它非常重要，非常棒，是我们所希望的一切，我们真的很喜欢它，非常感谢！

5. 最终的数据整理结构

5.The final structure

现在我们来可视化一下我们最终的方法是如何去整理数据的。

正如你所见，用户洞察被分配到不同的功能下，功能可以关联到问题所在，问题可以整理到用户场景或者用户目标下。我们引入用户场景的层级是因为我们的产品非常庞大，我们所以希望对问题进行分组，以便在不同问题之间浏览切换。

如果我们是那个视频会议产品的团队成员，下图就是我们用这种方法来整理Katie和Jimmy反馈意见的例子。

正如你所见，一个用户洞察并不一定被分配到一个功能下，如果没有功能这一层级，你可以优先考虑问题，然后你就可以发散出更多的解决方案，所以这个方法是完全可用的。

我想强调的是，这是一个可以不断添加的结构。适用于今天的整理结构不一定适用于明天。这导致整个结构化主题更加困难。除此之外，适用于我们公司的结构不一定适用于你的公司，这就是为什么我会把工作坊流程发布出来来引导我们每个人去寻找适用于自己产品的方法，所以一定会根据这个方法找到你们的整理结构。

我们目前尝试去让我们的结构更加扁平，但是如果你发现浏览不同问题时很困哪，这可能就是你需要拓展出更多其他层级的信号。这种情况下，你可以在更小的问题上面引入另一个更大的问题层级，或者在低层级的用户场景之上加入更广泛的用户场景。这取决于你需要什么。

小建议：如果你在创建一个问题还是两个问题上犹豫，或者是否需要把一个问题拆解成两个问题，你可以选择后者，因为你永远可以把任何内容组合起来，但是很难去分开他们。

6. 这个新的整理结构如何帮助你的日常工作？

6.How does this new structure help our job?

1）优点1

从现在开始，这个结构不仅只是对产品管理有用。同样也适用于用户体验研究。体验研究人员可以看到哪个问题是紧迫的并且可以开始深挖研究。另外，这种思考方式也会鼓励每个人去思考每一个用户需求背后的原因，而不是一味去增加产品功能。

2）优点2

产品设计与开发变得更加高效。不再需要去做那些毫无价值的、浪费时间且无法结局问题的工作。

3）优点3

这是一个适用于产品 - 用户体验研究之间合作的完美工具。用户研究人员可以非常简单地加入到流程图的设计中，产品经理也可以更好地去选择创造更多价值的功能。

4）优点4

用户体验设计师和不能在洞察处理环节中紧密参与的其他同事（营销，销售等）可以更加简单地浏览这个结构，给予更宏观的呈现与总结，并且可以让紧迫的大问题只需要看一眼就可以快速定位。

7. 使用软件

7.Tools

现在有非常多的软件可以帮助你整理这些内容（Productboard、User Voice、Aha!、ProductPlan 等等）。

我非常建议谨慎思考哪个工具会更加满足你的需求。一旦你使用了一款软件，就得在那里收集数据，然后按照这种结构整理；所以一旦开始使用就不要更换，把数据迁移到另一个平台上需要巨大的时间和精力。

8. 定量数据

8.Quantitative data

到现在为止，我们一直在谈论定性数据，但是，这个方法同样也适用于定量数据！是不是很棒！

比如说，每当你看到某个功能需求在公共功能需求页面上有 88 票时，你只需要把这个洞察分配到相应的功能需求下，然后给它赋予一个比基础影响分数（当在用户访谈中，只有一个人提出了这个功能需求）更大的影响分数。

这个方法也适用于一些问卷和其他定量调研方法，你只需要变得稍微有创造力一点，但是这个方法是适用的！

非常感谢 Linda Czinner（Bitrise 的首席产品经理），她与我一起参与了这个旅程。

原文：https://uxdesign.cc/how-to-make-the-best-product-decisions-based-on-thousands-of-user-inputs-7fc0d7658a12

作者：Zsófia Kothencz

译者：王英睿

审核：徐曼璐、李泽慧、张聿彤

编辑：孙淑雅

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

往期精选文章：