知识分享

  • 首页
  • 市场分析
  • 需求分析
  • UI设计
  • 产品运营
  • 产品设计
  • 项目管理
  • 新玩意儿
不积跬步无以至千里
不要停留,欣赏沿途的风景
  1. 首页
  2. 产品设计
  3. 正文

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

2021年10月21日 544点热度 0人点赞 0条评论

编辑导语:产品在优化的过程中,需要做好相应的用户调研,洞察用户需求,进而找准迭代的方向。然而我们应该如何整理得到的用户洞察数据,最终驱动产品决策呢?本篇文章里,作者结合实际案例,针对该问题进行了梳理,一起来看一下。

这些天我们获取了许多关于产品的定量和定性数据。这些数据无处不在,你可能做了许多用户访谈,从用户调查问卷中获取反馈,或者使用其他方法来获取数据。

同样,用户也给我们提出了许多功能需求或者对产品提出了许多问题。用户确实通过这些让我们了解他们的想法和困难。收集完这些数据之后,你将拥有一个海量而杂乱的数据库等待被使用。

“用户的洞察是重要的,数据驱动的产品策略是必要的。”

我们都知道用户洞察是制定产品策略的基石之一。用户洞察是十分有价值的,因为我们可以根据这些来制定产品阶段性目标,并且创造出最大的价值。

然而,你需要很小心地使用这些数据,否则你将会做出错误的决策或者最终根本没有发挥这些数据的价值。如果没有很好地使用这些数据,难道不是错失了一个良好的机会吗?

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

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

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

一、使用什么方式来整理数据? Can any structure work?

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

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

我们把产品分成几个部分(比如注册/首页),在每个部分下面把从不同渠道收集到的数据以主要功能和其下的子功能的形式标明。

遵循这一结构,哪一洞察出现的数量越多,我们就可以关注这一部分的功能需求并且制定产品阶段性目标(给每个洞察打分会比单纯的计算哪一洞察出现的数量多更加复杂和严谨)。

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

二、问题所在 The problem

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

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

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

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

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

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

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

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

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

现在我们来看我们的整理结构,我们有许多功能需求可以解决这个问题(比如增强加载指示,修复前端加载问题等)。所以你会把这些需求放在哪里呢?把他们放在一个需求下面,还是两个?

不管用哪种方式,你都没有从宏观角度来看问题,我们无法意识到一个问题的重要性,是因为我们把这些碎片放在不同的部分下面且没有统一考虑。

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

三、如何去解决? How tosolvethis?

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

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

四、我们寻找理想方法的过程 Our way to the ideal structure

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

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

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

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

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

根据这个流程,你要从解决方案反向追溯到需要解决的具体问题。在这个例子中,具体的问题就是用户有音频连接问题。

知道了问题所在,所以接下来怎么办?现在就到了创意发散环节,我们需要找到这个问题的最佳解决方案。也许你们可以给用户一个音频故障排除指南,或者你们可以自己修复连接的问题。

我们这样做得到了什么?我们得到了一个根本问题更多更好的解决方案,我们当然可以确认这些解决方案都是围绕着这个根本问题展开的。

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

我们现在,有 100 个问题可以选择去深挖。根据用户反馈的数量和比重以及其他因素(业务目标,用户画像等),你可以选择去深挖哪一个问题。然后你会进行创意发散环节,获得 100 个解决方案。

接下来,进行优先级划分,有许多方法去寻找最佳和最终的解决方案。这篇文章并没有涵盖这个部分,如果你有兴趣,可以阅读这篇文章:https://plan.io/blog/feature-prioritization/

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

五、最终的数据整理结构 The final structure

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

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

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

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

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

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

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

六、这个新的整理结构如何帮助你的日常工作?How does this new structure help our job?

1. 优点1

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

2. 优点2

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

3. 优点3

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

4. 优点4

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

七、使用软件 Tools

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

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

八、定量数据 Quantitative data

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

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

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

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

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

作者:Zsófia Kothencz

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

译者:王英睿;审核:徐曼璐、李泽慧、张聿彤;编辑:孙淑雅

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

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

标签: 暂无
最后更新:2021年10月21日

小虾米

同理心,洞察力!

点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复
最新 热点 随机
最新 热点 随机
县城咖啡之战的最后赢家是谁? 字节跳动再战长视频,这次有何不一样? 网文IP的风,吹到“下饭剧”? 提升B端产品易用性:搭建帮助体系 小红书关停“自营电商平台”,作何打算? 从陌生人社交的产品演进看创新 如何快速了解一个行业? 汽车行业数字化转型_SCRM私域平台 产品用户体验升级 做一款以短视频为主的手机,市场如何? 一个严肃的问题:互联网巨头们到底创造了多少就业? 海外版妙鸭相机,“像不像”不重要 产业化思维助力招聘直播数据翻倍(下篇) 产品周报267期 | 蔚来手机NIOPhone正式亮相,妙鸭相机免费版发布 谁拿走了飞猪携程们的长假? TikTok豪赌黑五 “加速包”抢票有用?第三方平台们都玩出了哪些花样? 薄盒借周杰伦IP卖藏品,引出了元宇宙的“空城困境” 抖音越追越近,美团的反击战打到哪一步了? 用了“信息转换”后,用户点击率明显变高了! 产业化思维助力家服业务增长(上篇)
从虚拟偶像到虚拟主播,一场TO C到 TO B生意的大迁徙今天我们来聊一聊小红书电商盘点一下那些虚实结合的文本输入方式自动驾驶,又到黎明前?万亿规模能源产业互联网【能链】为何一枝独秀?经营指标层面深度解读骑手需要的不是同情,而是尊重数据更新|不只是一个更新按钮而已名实唯一性:数字与AI经济里的那些潜规则实战分享!系统可见原则在交互方案中的运用从商业模式入手,搭建一款产品的底层拆解框架小红书走到命运拐点微信的聊天记录占比,被网友玩成了新一代 MBTI ?SaaS产品数据分析之指标与标签一篇文章搞懂一个系统之 SRM 系统一个真秀才倒下去,十个假靳东站起来谈谈在B端落地第三方大模型的步骤从0开始设计产品搜索功能(一)瑞幸的“9块9”突围战,只需几滴茅台?如何从0-1建设企业微信SCRM顶流网红“秀才”翻车,“中老年收割机”易主?
年轻人不爱看书了,但卖书看起来还是一门好生意 别爱太满,别睡太晚:寺庙的流量密码与新媒体生意经 如何做好客服产品进阶术 个人中心该怎么画? 开放外链仅是开始,互联网将被重塑 营销平台,从0到1搭建思路 产品设计请考虑场景呀!各位! Instagram Reels 能干掉 TikTok 吗? 产品如何设计交易系统——结算篇(0-1) 方案分享:2019飞猪3周年庆活动如何策划? 短期保险续保,我想看到什么? “种草直播”,会是直播电商的转折点吗? 股权激励下,互联网人戴着镣铐起舞 抖饿合作要开全国?辟谣还是放风 自由职业后,我开始羡慕996了 收费未必能解决发展痛点,闲鱼应该如何突围? 1年半工作总结:B端产品经理需要注意的那些事(1.0) 疯狂小杨哥,下一个辛巴? 手把手,教你做CRM系统! 企业产品如何设计用户教育系统?

COPYRIGHT © 2023 知识分享. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang