今天周末重拾读书，一下子读完了2.2，这部分干货还是蛮多的~所以下面主要是一些整理和摘录，个人的感想可能会少一些~
今天读了2.1.2 你真的了解用户么？和2.2 需求采集的大生产运动，2.2部分真的是干货满满哈哈，围绕用户研究做了一个全面详细的介绍，下面就开始啦~
首先是用户研究的方法，先贴上一张图，我在《互联网产品一：名词解释题、需求分析&用户研究》中也贴了这张图，但这里介绍的更加详细深入，整个脉络都梳理清楚了。（图是我自己画的，但是来自《赢在用户：WEB人物角色创建和应用实践指南》，本书作者苏杰稍有修改。）
上图分两个维度来看。横向是用户的说和做，说表现了目标和观点，做反映了行为，而说和做经常是不一致的。纵向是定向与定量，定性研究可以找出原因，偏向于了解，定量研究可以发现现象，偏向于证实。人们认知新事物的过程通常都是从定性到定量，再定性再定量，并且螺旋上升，而了解和证实也是不断迭代进化的。
说和做、定性与定量，要合理的搭配使用才能发挥最大的作用，下面就是用各种用户研究方法来交替解决问题的一个完整的例子，实际中通常会视情况简化：
①听用户定性地说，确定产品方向做什么。
②听用户定量地说，确定优先级顺序先做什么。
③看用户定性地做，要先做的需求应该怎么做。
④看用户定量地做，根据用户使用情况进行数据分析不断改进产品。
这4个步骤逐渐深入，从产品idea提出到上线运营并改进，是有一个时间上的逻辑顺序的，但是同时他们也是一个循环并螺旋上升的，从①到④是一个产品的过程，然后再从④返回①是对已有产品的改进与完善，也可看做是一个新产品的过程（因为与以往产品不同因此我这里认为是一个新产品了）。
下面说说具体的需求采集过程，即上面具体的每个步骤。用户研究（需求采集的过程）通常有以下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
将上面的用户研究图简化为每个象限中最常见的方法，如下图。
1. 定性地说：用户访谈
通常采用与被访者一对一聊天的形式，样本比较少，一般是几个到几十个，但在每个用户身上花的时间比较多。用户访谈可以了解用户怎么说，即他们的目标和观点，常用在新产品方向的预研工作中，或者通过数据分析发现现象以后，去探索现象背后的原因（与定量地做 数据分析的联系）。
常见问题与对策
①“说”和“做”不一致
用户经常会骗我们，如经典的索尼游戏机的故事。用户欺骗的原因可能是：他们被问了自己也没仔细想过的问题，又不想或不能回答不知道，就现场编造了一个理由，或者他们有讨好访谈者的心理，会回答他们觉得你希望听到的答案，而不是自己真正的想法。
防止被骗的方法：向索尼（让用户最后选择带回家一款游戏机）学习，尽量在用户可以和产品发生交互的场合下进行，让用户在“说”的同时也“做”，不过这样成本会提高。另外，注意区分用户说的事实与观点，一般来说，诸如“我做了什么，步骤如何，碰到了什么问题”这类事实的可信度会比“我觉得、我认为”这类的观点更高一些。
②样本少，以偏概全
选择样本的时候尽量做到随机，常见的“不随机”的例子主要有：地域涉及窄、接受访谈的用户一般比一般用户忠诚度更高。样本选取属于概率与数理统计的范畴，想深入的同学可以自行研究。
常用对策：首先，尽量识别各种可能引起偏差的因素，并在访谈的报告里标明，让读者了解。然后，为了用尽可能少的样本得到尽可能正确的结论，坐着提出可以用增量的方式做访谈。举个例子，先访谈5个用户，得出基本结论，然后再访谈5 个，观察结论是否有改变，如果有改变，就继续加大样本量，或者思考问题是否合适？样本集是否合适？如果没有改变，就停止继续访谈，节省成本。
③用户过于强势，把我们往沟里带
对策：时刻牢记访谈的目的。如果发现话题不对，就赶紧往正道上扳，若发现多次都扳不过来，可以考虑尽快结束。
④我们过于强势，把用户往沟里带
对策：同样是牢记访谈的目的，并且管好自己的嘴。
最后是一些注意点（来自《软件观念革命：交互设计精髓》）
避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。
首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。
避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。
避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。
鼓励讲故事：故事是最好的帮助设计师理解用户的方法。
避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。
2. 定量地说：调查问卷
调查问卷也是听用户说，因此会感觉和用户访谈比较类似，实际中经常通过用户访谈的开放式问题，为调查问卷收集具体的封闭式问题。二者的区别如下：
用户访谈通常是开放式问题，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流；而调查问卷通常是封闭式问题，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，一般为选择题，不适合安排问答题。
作者总结了一些调查问卷的tips：首先，作答时间最好不要超过10分钟。开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放在中间；而有关被访者个人信息的题目一般放在问卷的最后，以免应答者在回答这些问题时有所顾忌，进而影响其他答案。
优势：
调查问卷独立性强，可消除“焦点小组”、“论坛发贴征集需求”等具有群体讨论性质的方法的弊端。这是因为用户有其特点——沉默与骑墙的总是大多数：《长尾理论》里说到“沉默的大多数”，那么站出来的总是很少数，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”说的是，大多数人是没有明确观点的，尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群体的观点，随机的初始值决定了结果。调查问卷的客观性、多份问卷之间的独立性，可以有效避免上述问题。
问题与对策：
（1）样本偏差：样本与想了解的目标用户群体出现偏差
调查问卷的样本选择要尽可能覆盖目标群体中各种类型的用户，比如性别、年龄段、行业、收入等，要保证各种类型用户的样本比例接近全体的比例。
对策：①但在实际工作中，经常会因为各种原因没法做到样本选择的合理性，所以在类似情况下得出结论的时候，最好把这些潜在的筛选条件标明，让报告的读者知道数据获得的方法与来源，同时如果我们是报告的读者，也要一直带着问号去阅读里面的数据。②还有一个小技巧，就是可以把目标群体的特征也定义成一系列问题，放入问卷中，待回收问卷以后通过这些问题评估作答者是否能代表目标群体了。如果发现了偏差，我们也可以从回收的问卷中再筛选出一个接近目标群体的子集来分析。
（2）样本过少
样本量过少时，采用比例来分析是不严谨也是没有意义的。要给出百分比答案的话，至少得有大约100份的答案。
（3）问卷设计
①问题表述应无引导性。比如，不要问“你喜欢某个产品吗”，这时用户可能会考虑到提问者的情感而回答“是”，正确的问法是“你是否喜欢某个产品？”
②答案的顺序，可能产生“顺序偏差”或“位置偏差”，即被调查者选择的答案可能与该答案的排列位置有关。有研究表明，对陈述性选项被调查者趋向于选第一个或最后一个答案，特别是第一个答案；而对一组数字，如价格和打分，则趋向于取中间位置。对策：可以准备几种形式的问卷，每种形式的问卷选项排列的顺序都不同。
对策：对于重要的问卷，为了避免上述问题，还有个通用的办法就是先进行小范围的试答，根据反馈修改后，再大面积投放，类似互联网产品的灰度发布的理念。
3. 定性地做：可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
过程
它是UG（user generated）理念的一种很漂亮的实践，在目的明确的前提下，主要过程如下：
（1）招募测试用户：主要原则是他们要尽可能地代表将来真实的用户。
（2）准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。
（3）测试过程（重头戏）：可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。
（4）测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。
（5）研究和分析：在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。
常见问题与对策
（1）时间要早：如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。
其实，可用性测试在产品的各个阶段都可以做。在尚无任何成型的产品时，可以拿竞争对手的产品给用户做；在产品只有纸面原型的时候，可以拿着手绘的产品，加上纸笔给用户做；在产品只有页面Demo的时候，可以拿Demo给用户做；更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。不同阶段不同做法，从中都能发现相应的问题。
（2）认为可用性测试很专业，所以干脆不做。
可用性测试听着很专业，但收益又无法量化，所以对很多老板来说，不太愿意在这个上面投入资源，经常因为项目时间过紧被略过。可用性测试通常来说做5 个左右的用户才可以发现大部分的共性问题，前前后后的准备也耗时不少，但只做一个用户，并且简化步骤，也比不做要好。作者提到还可以直接找同事做测试。
（3）明确是测试产品，而不是测试用户。
可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。如果用户用的不顺畅，是产品的问题，而不是用户的问题。所以，不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”。清楚地说明这一点将有助于减轻用户的压力，使得他们能像在真实环境一样来使用软件。
（4）测试过程中的注意点。
①刚开始的时候，可以告知用户大概持续的时间，要做哪些事情，让用户心中有数，轻松愉快地完成任务。
②可用性测试中，可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作，等等。
③过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了（这里和上面第3点类似）。
④结束之后，如有可能应该送个小礼品，当然在邀请的时候就要告诉用户会有一些对他付出时间的补偿。尽快总结，并且发给用户，一方面让用户感到他做了一件有意义的事，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的，这份总结要用于指导产品改进，这才是可用性测试的根本目的。
强调
一定要尽早做可用性测试！
对于改版的话，除了“可用性测试”要在足够早的时候做以外，发布后也是有一些方法改进的，比如下面4种：先从次级页面改起、新旧版本并存一段时间并允许用户自由选择、小面积试验、傍上一个用户已经习惯的风格。这4种方法使产品改版比较柔和，容易获得用户的支持，直接发生较大改动容易使得用户一下用不习惯，可能会丢失用户。“总之，对于改版，对于升级，我们要把“暴力革命”变成温柔和谐的“和平演变”。
4. 定量地做：数据分析
上述3 种方法都只能接触特定的少部分用户，那么到底能不能代表目标用户群体？虽然绝大多数情况下的经验证明，只要在用户的选择上没犯什么低级错误，他们是“具有代表性的”，或者说接受这种假设是一种性价比很高的廉价解决方案。不过，我们还有数据分析，一种定量的研究方法，数据来说话，看看用户到底是怎么做的，不论是考察目标用户全体、还是采样，都完全可控，所谓“According to the data”是最难被驳倒的。
数据分析时，根据不同的目的，数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。数据分析的方法，最简单的可以用Excel，复杂一点的可以用一些统计软件、数据库软件，或者直接自己写程序解决。而最最关键的就是对结果的解读，通常数据分析只能发现一些现象和问题，并不能了解原因，所以分析完成后通常会伴随着一些用户访谈，听听用户怎么解释。这里我们就发现，我们从数据分析又回到了用户访谈，所以这4个方法是循环着螺旋上升的，数据分析之后再一轮的用户访谈是对之前产品的改进。
常见问题与对策
（1）避免过于学术，沉迷于“科学研究”。
实际的生产和科研是有很大不同的。科学研究通常只注重“性价比”的性，只要结果好，往往不在乎投入，因为相对而言科研的结果不是为了马上应用，而是为了证明实力，更多地在理论层面。但实际生产环境就更注重综合的性价比了，所以我们日常的数据分析方法也就显得不那么严谨了。
（2）经常无意或有意地误读数据。
无意地误读数据，举个例子，对一个人群，人们的身高用平均数来衡量是有意义的，因为我们知道身高属于典型的正态分布，中间多两边少，所以一个平均值就能了解群体的大致情况，而对人们的收入，就不能用平均值来衡量了，一个超级富豪和1000个零收入的人一平均，很可能得出人均收入100 万的荒谬结论。
对策：学习统计学的知识，努力提高自己的水平。
主动地误读数据：在提取数据之前，我们心中通常已经有一些结论了，无非是想验证它，而抱着这点思想，就总能找到数据来证明自己已有的想法，并且技术越娴熟的人越容易做到这点。
对策：对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯。
（3）平时不烧香，临时抱佛脚。
这是一个很实际的问题，我们经常在做决策的时候才想起来数据分析，但忽然发现手头没有数据可分析。
对策：我们应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等，这也算一种典型的非功能需求，这样做对产品的可持续发展非常必要。
5. 最后：需求采集人人有责
需求采集并不只是产品人员在产品设计之前的工作，而是要贯穿始终，并且需要所有人都参与进来的。
首先我们希望尽可能多地采集需求，作者在这里介绍了一个简单的人人参与地工具——“单项需求卡片”。
单项需求卡片
理念：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间。
内容：一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景，谁在什么时间、地点产生了何种需求，下图是一个模板。
最后作者还简单了分享几个有特点的需求采集方法。
现场调查
打入“敌人”内部，和客户一起工作一段时间，深度了解需求。它是一种典型的定性分析，持续时间长，从几小时到几个月，既能听到用户怎么说，也能看到用户怎么做，不过受众面极其狭窄，一次只有一个，要特别小心被“非典型”用户带到沟里去。
AB测试
基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还是右边好，而我们有10万用户，那就先随机挑选少量的用户发布这个按钮，1000人放左边，另外1000人放右边，然后过一段时间分析结果，再决定剩下的98%用户该怎么办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同学羡慕不已。
日记研究
互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要明白日记的作者往往是同行，而不是主流用户。
卡片分类法
我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。这能让你深入了解用户是怎么给产品划分模块的，用户认为这个网站应该是什么结构。因为产品设计人员的思维和用户的思维通常不一样，这也就导致了如果是产品设计师来单方面决定网站结构的话，很可能导致用户理解的困难，所以卡片分类法能让最终的产品更加符合用户的心理模型。
自己提需求
这是最简单的方法。每一个靠谱的产品都会有一群粉丝用户，不用你去找他们采集需求，他们也会给我们惊喜，主动提出很多需求，作为产品的主人，我们好意思还没有用户了解产品么？产品要用才能感觉出好坏，特别是自己做的产品。产品做多了，我们随便看看别人做的产品，总能一下子挑出很多问题，提出很多需求，反过来看自己的产品越看越完美，这一定有问题，所以必须用自己的产品，最好是发动认识的人都来用。
