产品经理的工作主要是分析用户需求,发现其背后的原因,从而创造出能够直击用户痛点的产品。但是如何知道用户需求?实际上需求分析还有一个前置步骤,就是需求采集。只有使用科学的采集方法,才能更深入的了解用户的痛点。仅仅靠着拍脑袋想出来的需求,很可能就是做出来的产品没人用,不好用。

需求采集是什么?

需求采集实际上就是获取/验证需求的方法。其目的就是通过深入了解分析目标用户,发现他们的痛点。随之而来的才是需求分析,需求转化等其他后置工作。

如何进行需求分析?

需求采集的5步:

  1. 确定采集目的
  2. 选择采集方法
  3. 制定采集计划
  4. 执行采集
  5. 总结分析

其常用对于用户需求采集的方法有4种:

  • 用户访谈
  • 调查问卷
  • 可用性测试
  • 数据分析

下面我会按照需求采集的流程,分别说一下哥哥方法的用法和注意点。

1. 确定采集目的

数据采集是要有目的,没有目的的采集通常是盲目的,并且没有办法直戳要害;而且也会因为目的不明确,无法找到合适的数据,因为你不清楚哪些数据能用到,哪些数据用不到,费力不讨好。所以数据采集的第一步就是确定你数据采集的目的。比如,日历用户使用场景的访谈,文档同步可用性测试等等。

2. 选择采集方法

可以根据产品开发的阶段和调研目的选择不同的采集方法。

  • 功能规划阶段:用户访谈,确定产品方向
  • 功能早期阶段:调查问卷,确定需求优先级
  • 功能实施阶段:可用性测试,需求方案校验
  • 功能上线后的优化阶段:数据分析,改进产品,优化体验

3. 制定采集计划

不同的采集方式,有着不同的使用场景和容易存在的问题。

3.1 用户访谈

一般采用1对1,或1对多的形式,围绕几个特定的话题,我们问, 用户答,用户说,我们听。作用是研究新产品的方向,或者是因为数据分析发现了现象,探索背后原因。

言行不一:经常能看到用户言行不一的时候。其原因有的时候用户可能是自己没有考虑,或者是为了迎合调查人员,还有可能是不想回答或者不知道答案随便答的。

解决方案:遇到这种情况的时候,先不要着急的和用户进行争论,或者指出用户的问题,先记录下来,保持微笑和礼貌。可以侧面多找几个问题问问用户的看法,和当时操作时候的想法。注意其他用户是否存在相同的情况,推测原因。

样本少,以偏概全:通常是因为成本有限,性价比比较低。

解决方案:增加样本,先做假设,然后统计变化规律,如果和之前的预计假设偏差值小,就可以停止访谈了。

偏离方向:一种是因为用户强势,容易把话题带偏了,第二种是访谈人强势,把用户带偏了。

解决方案:牢记访谈目的,如果发生了话题偏移,尽量扳回来,如果实在不行,则尽快的结束访谈,节约时间进行下一个用户,不要再这个用户上继续花过多的时间。访谈者不能表现出强烈的引导性,主要还是让用户来表达,对于用户的反馈全盘的接受,不能因为不符合你的预期而表现出来。

访谈目的不明确:没有明确调研目标,为了调研而调研;还有一种就是调研的方向太大,因为问题问得太大的到的反馈效果不好。

解决方案:确立明确的调研目的,题目不要太大。

通过用户访谈,我们一般能获得用户信息,包括个人基本信息,特征信息和用户使用产品的偏好。需求信息,包括用户为什么产生这样的需求,通常在什么场景下出现;行为信息,没有现成解决方案用户是怎么解决的?早操作的时候有遇到什么问题?让用户抓狂的点是哪里?最后分析需要解决的就是之前调研需求信息和行为信息的原因是什么。

3.2 调查问卷

设计问卷由用户填写,回收问卷,统计用户反馈,以量化数据的方式获取用户需求。通常在需要面对大量用户,或者需要调查的问题并不是很深入的时候选择这种方式。

时长过长:不管线上还是线下的问卷,时长都不应该超过五分钟。

题目顺序:调查问卷的题目顺序非常重要,开始选择一些简单不需要思考的问题,中间选择用一点思考或稍微敏感的问题,结尾则可以问一些用户个人信息的问题,这样做的好处就是能够循循渐进,避免了刚开始就要用户的个人信息,而让用户产生抵触心理对问题做出防御姿态,最后就是得到的答案不是用户真实的反馈。

准确性不够:指的是调查问卷的数据并不能符合真实的情况,原因通常是因为样本过少和题目本身具有引导性。

解决方案:调查的时候要覆盖目标群体的各类型用户,还有一点就是其调查人群的比例也要尽可能符合真实用户的类型比例。样本过少,没别的办法,就是增加样本。题目引导,则需要对题目本身制定的时候多思考,更改一下题目的顺序,多做几个版本的题目,先在小范围做试答,进行反馈修改后再正式的投入市场。

3.3 可用性测试

邀请用户实际使用产品,在用户使用产品的过程中观察用户遇到的问题,从实际使用情况来分析产品体验和用户需求。可用性测试可以提前发现产品设计的问题,优化用户体验,而且有可能在测试的过程中还能发现新的需求。

晚做不如早做:如果功能已经上线,在做可用性测试,如果原来存在的问题实际上就已经影响到用户了,这就太晚了。

觉得专业,太过复杂,就不做了:实际上,很多企业都认为可用性测试比较复杂,而且其结果是没办法预估,性价比低,所以通常是有功夫再做,没工夫就不做了。其实是可以根据情况来定,简化步骤,可用性测试能够得到很多数据发现不了的问题,不管结果有多差,怎么都比不做要好。

测试产品,而不是测试用户:用户来测试之前,明确告知用户测试的目的是发现软件问题,即使用户在使用过程中完不成任务,也是产品的问题,不是用户的问题。

招募用户:招募的用户尽可能就是以后产品的目标用户,这样的出来的反馈才是最真实有效。

测试:提前准备测试任务,主要测试产品的核心需求相关功能。测试前要提前告知用户目的,大概的时间和测试任务,让用户心理有数。如果有条件最好是在取得用户同意的情况下进行录像记录过程。

3.4 数据分析

通过统计用户日志文件或实际使用数据,采集和分析用户需求。特点是数据来自于真实的用户,是可以控制的,避免了只听用户说的误导,真实的看到了用户的是如何做的。能够验证之前的预想是否正确,起到校正用户和用户需求的作用。

过于学术,沉迷“科学研究”:数据分析要考虑成本,特别是初创企业,不能每一步都进行数据分析,这样会导致效率比较低。而且数据只能看到现象,但背后的原因还是需要自己去寻找。

数据不会骗人,但容易误读:人是习惯性的先有了猜想,然后去找数据证明它。这样做很容就变成为了证明自己是对的,出现误读的情况。

解决方案:保持中立,学习科学家精神,不要为了迎合某一观点,针对观点来找数据。

提前布局:不要等着想要数据分析的时候在去找数据,而是要提前埋点,这样才能有数据来分析。

4. 执行采集

采集的过程中有以下注意点。

  • 提前向用户说明来意:测试之前提前和用户打好招呼,说明测试的目的,大概花费的时间。
  • 让用户放松,征求用户的意见:不要过于严肃,同时调查人员可以选择去用户熟悉的场景来进行测试,让用户保持放松的状态,尽量还原平时用户平时使用产品的场景,如果有录像,一定要提前征求用户的意见。
  • 避免引导性的举动:题目和采集过程的接触中尽量不要有引导性的举动,这样可能会造成用户的答案是你想要的答案,而不是用户真实的答案。
  • 保持感谢:用户花时间来配合采集,一方面是用户处于对你的相信,还有一点是对于产品的喜爱。所以一定要保持感谢,预算充足的情况下可以准备一些小礼品送给用户。最后的结果如果没有什么特别需要保密的,也可以给用户发一份,并附上感谢,让用户感受到他也在产品里有自己的一份付出。

5. 整理资料

采集完了,一定要将资料进行整理规划分析,要不然采集做了等于白做。之前提到过不能光听用户说,要观察用户。有的人就会问,那么我只要看用户怎么做不就好了。为什么还要听用户说呢?其实听用户说和看用户做都非常重要,只看用户如何做,只能看出现象,只有两者结合才能知道背后的原因。

而且言行不一,也可能是某种功能需求的表现,比如某些隐私对应着选择性展示的功能,就是产品经理发现了用户一些不想说的原因,做了可选择性展示的功能。如果只看用户如何做就没办法做到这么的深入人心。让你的产品通人性,两者缺一不可。

这里具体的整理方式和方法,打算放在需求分析里面详细说明。

需求采集有什么好处呢?

说了这么多,可能觉得步骤非常多,而且很麻烦,但是做需求采集有什么好处呢?最直接的好处就是需求采集能够加深产品经理对目标用户的了解。好的产品经理应该抓住一切机会与目标用户进行接触,你只有接触了才能可能发现一些你坐办公室根本想不到的问题。毕竟一个人的大脑能预想到的情况有限,只有接触了各种各样的用户,你才能发现用户的痛点,然后在今后的工作中去更好地解决他们的问题。

还有一点好处,通过需求采集,你能发现现有产品的问题,只有通过这些采集手段,把产品存在的问题暴露出来。产品有错误不是大问题,最大的问题就是不知道产品有问题,而产品的问题就是产品的方向标,它能为我们展示产品的优化方向。

这里说的这个4个采集方法都是面对用户常用的方法,还有其他的一些需求采集的方法,比如说Bug转需求,头脑风暴,需求卡片,竞品分析等等。我会在之后的内容进行整理,有需要的可以私信留言,按照需求的人数我会适当的提前整理。

文章来源于互联网,如有雷同请联系站长删除:产品经理如何进行需求采集?

发表评论