需求分析

September 21st, 2023 by JasonLe's Tech Leave a reply »

学习目标

  • 理解用户反馈的意义,并知道如何从不同渠道中收集用户反馈并识别关键信息
  • 借助思维导图工具的帮助,从用户-场景-解决方案的角度整理用户需求
  • 通过四象限和其他维度对需求进行优先级排序

本章任务

  • 需求分析及优先级排序

2.1 通过用户反馈解决问题

2.1.1 通过用户反馈关注什么?

自身产品的问题

竞品的问题

可能的机会点

2.1.2 通过哪些渠道来收集用户的反馈?

2.1.3 用户反馈不同渠道的处理策略

AppAnnie、应用雷达、ASO114、CQASO等

2.2 如何处理不同渠道的反馈

2.2.1 应用商店评论与用户反馈

监控应用商店监控什么?

低分差评:重点看1~3分

有效评价:重点看实际描述的评价

异常行为:比如水军刷榜、恶意评价

竞品变化:监控竞争对手的应用变化

2.2.2 微博贴吧与用户反馈

主流平台:微博、贴吧、知乎、雪球

依据产品类型的不同选择不同的用户群所在平台

  • 爱股票、雪球
  • 豆瓣、简书
  • 抖音、快手
  • 懂球帝、虎扑
  • 宝宝树、半米孕期

工具:关键字+收藏夹、微博企业版、百度、Google等

2.2.3 通过用户咨询、投诉发现问题

内容来源:客服后台、录音、意见建议、用户反馈、邮件等

2.2.4 通过用户点评发现问题

差评:为什么差评?原因、现象是什么?

描述:重点看有实际描述的评论

异常行为:比如是否有刷好评的行为?有没恶意评价行为

2.3 思维导图法整理需求

2.3.1 产品设计的核心三要素

  • 产品设计,就是不断解决用户在特定场景下的需求
  • 增加、减少功能并非关键,关键能不能解决用户的问题

 

当需求分析遇上思维导图

用户 场景 需求

2.3.2 思维导图的思考方式

  • 用户:当想到一个功能,先不要想怎么实现的,而是想谁会用
  • 场景:用户分别在什么情况下会用(感兴趣)?
  • 问题:用户分别在上述场景下,碰到什么问题(挑战)?
  • 方案:用户现在的解决方案是什么?

2.3.2.1 第一步:潜在用户有哪些

谁会对优惠码感兴趣?

思维导图,列出所有感兴趣的人

不用思考行不行,把能想到的穷举

2.3.2.2 第二步:列出用户发生(感兴趣)的场景

针对每一类用户“分别”往下分解

把“什么情况”描述清楚,最好简单描述一个故事

2.3.2.3 第三步:不同的用户分别碰到什么问题

  • 注意是“分别”,不要怕重复
  • 不同的群体、不同的场景,问题都是不同的
  • 区分“问题”和“中性词”,如时间、价格

2.3.2.4 第四步:现在的解决方案是什么

2.4 用户-场景-问题-现有解决方案

2.4.1 关于【用户-场景-问题-现有解决方案】四要素的意义

「用户-场景-问题-现有解决方案」这四要素,其实是一个比较友好的沟通和表达工具。

1、它能够快速的将你和其它在来自不同行业,有着不同表达习惯,目前正处在不同语境下的同学,快速拉入到同一个语境里。

2、它能帮你拆分清楚,用户遇到的真正的问题是啥,是在哪种场景下遇到的,以及遇到后目前的现有的解决方案是啥。

 

拿三节课内部,班班和技术同学报bug这件事举例:

有些同学在报bug时,是这样描述他们遇到的问题的:

“遇到问题:作业提交后系统不点亮”

 

如果你这样和刚来公司,正在专心写代码的研发新同学报bug,他应该会一脸懵逼

啥叫不点亮,不点亮有啥问题?正常情况应该是咋样的,这个同学是在哪遇到的这个问题?你到底在说什么?

 

但如果,你用「用户-场景-问题-现有解决方案」的方法进行问题描述的话,研发同学就一下子有画面感了,也知道你具体在问什么了。

 

“遇到问题:小三三同学认真做产品P1第2周作业的时候,提交完作业发现截图中左侧红框的小标记没有被点亮,正常情况应该是被点亮以表示鼓励的,但是他一直提交一直不亮一直提交一直不亮,对于学习的积极性造成了严重打击。小三三同学目前很崩溃,决定进行不写作业了。希望研发爸爸们帮忙看一下“

 

这样的描述过后,研发同学就会在帮你解决问题时,就会很清晰了。

2.4.2 关于用户

用户是一个群体中抽象出共同特征的集合,如:一线城市白领、大学老师、18岁的少女。他们在特定场景中,可能普遍遇到相同的问题、产生相似的需求。

在需求分析中,用户是分析的源头所在,我们需要理解产品的目标用户具体是谁,才可以更好的提出产品上的方案设计。

不过,用户分类也更多是依靠常识,或者自己在该行业持续的经验积累。所以目前在P1的课程作业中,暂时不要求大家掌握用户分类这件事。咱们能大体的概括用户是谁就足够了~

 

这里也介绍下常见的一些基础用户分类方法:用户分类有很多可以参考的维度,可以按照基础属性,比如年龄、性别、教育程度来进行分类;可以按照产品使用习惯,比如新老用户,付费/未付费用户进行分类;还可以从消费能力、兴趣爱好、社交关系等角度来分类用户。如果产品本身存在多种特定的用户角色(比如电商平台就有商家、消费者、平台运营方等至少三类角色),也可以考虑把这些不同的角色作为用户分类的依据之一。

 

尽管用户分类的维度五花八门,我们还是可以回归到用户分类的目的——是为了更有代表性的列举出场景和问题,以便于接下来进行需求优先级排序与产品的解决方案的思考——这也是用户分类的核心依据。

2.4.3 关于场景

场景:用户要使用一个互联网产品都有着其所附属的外在环境(比如时间空间)与内在心理状态(比如各种情绪),这些因素共同构成了产品的典型场景。

对于一个产品经理,「场景」是要经常挂在嘴边的词语。对任何产品的分析、用户问题的描述,都要是在一定场景下进行的。脱离场景的产品设计很可能没有办法解决真实场景下的用户问题。

我们一起来看看场景的例子:

场景的例子:

  • 暑假某日,下午3点,烈日高照,我和队友在操场上踢比赛
  • 期末时期,我在图书馆复习功课
  • 周末下午1点半,我和对象到附近万达广场逛街

很多时候,场景和问题容易混淆,我们接下来也看看问题与场景的区别是什么。

 

2.4.4 关于问题

问题是用户在特定场景下完成某个任务过程中出现的,有些人也直接将问题理解为用户需求或痛点。

「问题」的例子(句子中加粗的部分):

  • 暑假某日,下午3点,烈日高照,我和队友在操场上踢比赛,场上的队员们很快身体就接近脱水状态了,需要补水
  • 期末时期,我在图书馆复习功课,第5章的复习重点不知道是哪些
  • 周末下午1点半,我和对象到附近万达广场逛街,逛累了找不到合适的歇脚点

尽管以上的场景和问题拆得还不够细,但可以看出分析问题时,必须依托于场景。场景要能触发人的反应,才会产生需求/痛点。

  • 【生理】大夏天踢球-出水多渴了 -> 补水需求
  • 【心理】考前翻开书了-不知道如何下手复习 -> 备考指导需求
  • 【生理+心理】周末逛街-逛累了想聊天 -> 休憩&亲密需求

 

2.4.5 关于现有解决方案

这个概念很明确,就是他们面对问题做出了什么回应,不过需要注意的是,这个是用户现在这个时候所选择的解决方案,而并非未来产品可能提供的解决方案。此外,不知所措、无动于衷也是一种解决方案~

 

根据用户的现有解决方案,可以对比市场中是否已经有产品提供更优的解决方案了;若没有,对自己的产品来讲,很可能是个不错的机会。

2.4.6 与【用户-场景-需求】的联系

在没有相应产品功能的情况下,用户现有的解决方案可能并没有真正帮助用户解决问题,所以需要通过产品设计提供一个比用户现有解决方案更好的解决方案,来真正解决用户的问题。所谓产品满足了用户需求、产品解决了用户痛点,本质就是产品为用户提供了一个适当的解决方案。

 

当我们在以「用户-场景-问题-现有解决方案」的思考方式来分析需求时,目的是为了思考用户存在的问题有哪些没有得到解决,哪些问题的重要性更高,从而可以进一步思考目前的产品设计是否存在要解决的问题,以及未来如何通过产品设计提供更好的解决方案,帮助解决用户现存的问题;

 

而当我们用产品设计三要素「用户-场景-需求」来分析产品时,出发点是分析产品目前的功能/解决方案是如何解决用户之前发生的问题的。

 

比如:

“小明在电商公司里担任产品助理,最近618,公司里的业务同学常常加班。但是他们公司又在郊区,上下班非常不方便。每当小明深夜加班到2点的时候,打开滴滴出行,想打快车回家时,就总是打不到“ 像这样的描述方式,就是 用户场景问题现有解决方案的运用~

 

而”小明同学最近常常在公司加班,备战公司618大促。每到深夜2点下班的时候就打不到车回家。这个时候小明同事给他推荐了嘀嗒出行这款产品,说用这个app在深夜打出租车的时候特别方便快捷。“

 

“嘀嗒出行满足了小明在深夜2点加班后,想打车回家的需求”这句话的描述,就是 用户场景需求的描述运用~

 

这两个描述方式,本质上表达的都是用户需求

不过,用户场景问题现有解决方案这种描述,可以更好帮助我们去思考清楚,当前产品还存在哪些问题,产品有没有办法提供给用户更好的解决方案。

而用户场景需求的描述,更多是用于分析产品目前的功能/解决方案是如何解决用户之前发生的问题的。

2.5 需求的优先级排序

四个维度

2.5.1 四象限看用户量与发生频率

  • 优先解决大用户量的高频问题,基础体验
  • 最后解决少量用户的低频问题,超好体验

某垂直电商平台

2.5.2 开发难度与见效快慢

  • 优先见效快且开发难度不大的,这就是迭代
  • 最后做很费劲而且见效慢的,这可能是未来的机会

2.5.3 产品价值

  • 迫切程度:用户是不是真的非常需要?还是空想的?
  • 付费意愿:用户是否会为了解决问题而付费?
  • ARPU:如果未来开发出来,用户会为之付多少钱?

2.5.4 你对目标群体的熟悉程度

  • 你是否深入了解用户使用场景?
  • 你对用户群体的理解是否足够里哦阿姐?

2.5.5 总结你的结论

用户:这个功能,第一批核心用户是谁?

场景:这个用户在什么场景下会使用?

问题:解决了这个用户最大的痛点是什么?

对比:和用户现在的解决方案相比,体验/效率提升有多大?

在不同的业务场景下,应该如何决定优先采用哪种排序维度呢?

需求的优先级并不存在标准答案,这里的四个维度是帮助你思考的框架。在不同的业务和产品中,优先级要考虑的因素可能差距也是巨大的。比如,对于银行系统的小伙伴来说,哪怕是一个影响面很小的安全漏洞,可能都必须要以第一优先级来响应。因此,结合自己产品的情况来组合成不同的排序四象限,是你在工作中可以思考的问题。

并且,这几个排序维度也是可以叠加使用的,比如先用用户量和发生频率筛选出第一象限,再用开发难度和见效快慢进一步缩小范围。