码迷,mamicode.com
首页 > 其他好文 > 详细

码农的产品思维培养第2节----一个需求的奋斗史(人人都是产品经理)

时间:2014-10-07 17:38:43      阅读:247      评论:0      收藏:0      [点我收藏+]

标签:产品经理   人人都是产品经理   用户访谈   调查问卷   可用性测试   

今天我们继续坚持每日一节的产品思维培养,我喜欢在纸上画,喜欢做笔记。不是为了自己后面回去看,而是为了当时更好理解。不知道大家是否认同这点。

今天看到苏杰的一句话,其实和我之前讲过的是一致的,看来英雄所见略同,还是给大家分享一下“和学习任何领域的知识一样,建议大家在了解了知识框架之后,坚持“需求驱动学习””。

第二章,讲述的是一个需求的奋斗史。其实就是描述如何从用户那里得到需求,得到需求后如何处理的一个过程。今天,我们这一节讲如何从用户那里拿到需求。

用户研究,或者说需求采集的过程,都会有如下几步:明确目标、选择采集方法、制定采集计划、执行采集、资料整理,然后进入下一步的需求分析阶段。

bubuko.com,布布扣

根据定量和定性以及说和做,我们可以将需求采集的方法分为如下:

bubuko.com,布布扣

定性地说:用户访谈

    一对一的聊天,在每一而用户身上花费较多的时间,可能从几十分钟到几个小时。常常用在新的产品预研中。因为那个时候你也没太多的信息基础,你最好和用户进行深度的开放性聊天,然后在交流中采集用户的需求。

然而,每一种用户采集方法都有它的弊端,存在的问题。用户访谈存在的问题及对策:

1)“说”和”做“不一致的问题。

你问的一些问题,用户没碰到过,不熟悉,然后用户会给出一个无关痒痛的答案,甚至用户会去猜测你的心理,会去迎合你。所以给出一个他觉得你想要的答案。

所以,尽量让用户发生交互,在说的同时也做,就比如索尼的那个游戏机案例,他说喜欢黄色,结果拿的却是黑色。

还要注意点“我做了什么,我的步骤是xxx,我碰到了什么问题”这样的客户访谈内容会比“我觉得,我认为”要可信度高。所以,注意区分收集到的信息的质量分类。

2)样本少,以偏概全的问题

对于这个问题,主要是回来访谈的人毕竟少数,而会来访谈本身也说明了有个刷选过程,可能就和实际的客户群体有偏差了。还有,你说要调查全国,但你可能只调查深圳,甚至是科技园的码农。那都是会受到影响的。对于这些问题,解决的方法是:尽量识别出各种引起偏差的因素;以增量式进行访谈。

3)用户过于强势,把我们往沟里带

这个主要是,用户访谈的过程,用户开始讲故事了。慷慨激昂的讲自己的故事,结果一个下午下来,你的访谈目标没有一个完成。听了一下午的故事。记住时刻牢记访谈的目的,记得拉他回来,如果跑题了,如果拉不回那就早点结束访谈。

4)我们太强势,把用户往沟里带

这个主要是我们的访谈员太强势,当用户可能对我们的产品说出问题的时候。我们的人心里不爽,然后争辩,最后用户服了,就差道歉了。所以,要记住自己的目标是收集用户需求,不是卖我们的产品多好用。


最后,记一次用户大会

  确定以产品卖点,明确产品需求优先级,培养种子用户。


定量的说:调查问卷

    都是听用户说,但是调查问卷和用户访谈是有区别的。

用户访谈是提供一些开放式问题,深入的去交流。它在我们对产品方向也不是很清楚的时候用;而调查问卷往往在用户访谈之后,或者至少我们知道产品方向了。这个时候需要收集大量用户信息,但不需要特别深入的信息。调查问卷只提供选择题,不提供作答题,最好不能太长,几分钟就搞定。而且问题的顺序要讲究,比如一开始应该特别容易的,让用户不排斥,然后中间放重要的,这个时候用户已经投入进去了,基本不会或者说不好意思不去作答,最后要收集用户隐私的时候,放到后面,因为其实用户是特别反感自己的联系方式等等被收集的,所以如果放在前面,那么他所有的题都不会做就走的。就算他不留电话什么的,至少他已经作答了前面的问题,所以,顺序绝对要仔细考虑。


作者还说了一个东西就是,用户有其特点----沉默与骑墙的总是大多数。随机的初始值决定了结果。-----《长尾理论》

调查问卷也有很多弊端以及如何避免。

例如样本偏差,例如样本过少,例如问卷的设计细节等等。

一个真是的问卷案例是苏杰自己的书的问卷调查。http://iamsujie.com/

定性的做:可用性测试

    可用性测试:让实际用户使用产品或者原型方法来发现界面设计中的可用性问题。补充一个UGC的概念。

UGC(User Generated Content,用户产生内容,想到了优酷没有)。

怎么做可用性测试呢?主要的步骤如下:

1)招募测试用户,尽量代表真实的用户。跟用户不要说什么可用性测试,那样他会有戒备心里。而应该说“来试用一下我们的新产品,提点意见”。

2)准备测试任务,那些任务肯定是典型的任务。

3)测试过程。测试的时候,一定要观察用户的测试过程,最好允许发声测试,就像用户在打游戏的时候,让他说,问他,你为什么要走这里,他会告诉你理由,这种交互是非常有用的。记录下过程中暴露的问题。

4)测试结束后,问用户对产品的整体感受。并送人家礼物,作为对人家时间耗费的补偿。

5)研究与分析。

可用性测试中也会碰到很多的问题,以及作者给出了相应的对策。

第一,如果可用性测试做得太晚(往往在产品将要上线的时候),这时发现问题也于事无补了。

其实,产品的每个阶段都可以做可用性测试的,没产品的时候用静态原型也可以,用铅笔给用户画都好。

第二,总觉得可用性测试很专业,所以干脆不做。其实,如果徒省事,你可以叫一个项目外的用户来试一试也是可以的,总比没有更好。

第三,明确是测试产品,而不是测试用户。千万不要带着培训的心去做可用性测试。你要的是用户来暴露你的问题。

第四,测试过程中,组织者该做的和不该做的。

允许发生测试,不得有暗示或者引导。

定量的做:数据分析

这里就体现了日志系统的重要性,记得在产品的一开始就有意的去加入统计代码,比如页面的点击次数,按钮的点击等等这些。数据相对是不会说谎的。

将数据转化为商业价值。


最后,提倡所有的人都参与到需求采集中,理解“一手需求”与“二手需求”,作者还提到了单项需求卡片。这样就方便不专业的同事也可以带着卡片去收集信息。


好今天到这里。






码农的产品思维培养第2节----一个需求的奋斗史(人人都是产品经理)

标签:产品经理   人人都是产品经理   用户访谈   调查问卷   可用性测试   

原文地址:http://blog.csdn.net/minimicall/article/details/39853873

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!