标签：产品经理 人人都是产品经理 用户访谈 调查问卷 可用性测试
今天我们继续坚持每日一节的产品思维培养，我喜欢在纸上画，喜欢做笔记。不是为了自己后面回去看，而是为了当时更好理解。不知道大家是否认同这点。
今天看到苏杰的一句话，其实和我之前讲过的是一致的，看来英雄所见略同，还是给大家分享一下“和学习任何领域的知识一样，建议大家在了解了知识框架之后，坚持“需求驱动学习””。
第二章，讲述的是一个需求的奋斗史。其实就是描述如何从用户那里得到需求，得到需求后如何处理的一个过程。今天，我们这一节讲如何从用户那里拿到需求。
用户研究,或者说需求采集的过程,都会有如下几步:明确目标、选择采集方法、制定采集计划、执行采集、资料整理,然后进入下一步的需求分析阶段。
根据定量和定性以及说和做，我们可以将需求采集的方法分为如下：
一对一的聊天，在每一而用户身上花费较多的时间，可能从几十分钟到几个小时。常常用在新的产品预研中。因为那个时候你也没太多的信息基础，你最好和用户进行深度的开放性聊天，然后在交流中采集用户的需求。
然而，每一种用户采集方法都有它的弊端，存在的问题。用户访谈存在的问题及对策：
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
