可用性测试的常见问题与对策：
第一，如果用可行测试做得太晚（产品将要上线的时候），这时发现问题于事无补。
第二，总觉得可用性测试很专业，所以干脆不做。
第三，明确是测试产品，不是测试用户。
第四，测试过程中，组织者该做的和不该做的。
定量的做：数据分析
数据分析时，根据不同的目的，数据来源多种多样，常见的有用户使用产品的日志，客户管理系统里的信息，网页访问情况的统计信息等。数据分析的方法，最简单的可以用Excel，复杂一点的可以用一些统计软件，数据库软件，或者直接自己写程序解决。而最最关键的就是对结果的解读，通常数据分析只能发现一些现象和问题，并不能了解原因，所以分析完成后通常会伴随着一些用户访谈，听听用户怎么解释。
数据分析的常见问题与对策：
我们要意识到用户怎么做 和 怎么说 是不同的，甚至经常有矛盾，有时候用户的行为比语言更能反映出他的真实需求。比如用户说在搜索买家的时候应该加一个“按交易额搜索”的条件，也许只是他某次特殊的需求使然，但如果我们听他的做了这个功能，之后通过用户行为分析发现，只有1/10000的人用过，那就表明我们被用户的说法骗了，单数据永远不会骗我们。
数据分析时，有一些特定的问题：
第一，过于学术，沉迷于“科学研究”
科学研究通常只注重“性价比”的性，为了好的结果，往往不在乎投入成本，但是商业不是科学，更多的是对数据的敏感，对商业的敏感。
第二，虽然数据不会主动骗人，但是我们经常无意或有意的误读数据。
举个例子，对于一群人中，人们的身高用平均数是有意义的，那是我们知道他们符合正态分布，中间多两边少，所以一个平均值就能够了解群体的大体情况。而我们的收入并不符合正态分布，一个超级富翁和1000个零收入的人，平均下来每人100万，这是很荒谬的。解决办法：学习统计学的知识，努力提高自己的水平。
主动的误读数据，是比较有意思的事情。在提取数据之前，我们心中通常已经有了一些结论，无非是想验证它，而抱着这样的思想，就总能找到一些数据来证明自己已有的想法，并且技术越娴熟的人越容易做到这一点。对于这一点，我想一个简单的对策就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯，比如为了证明老板的判断，或是为了保持自己之前拍脑袋的英明形象等。
第三，平时不烧香，临时抱佛脚。
产品日志的商业价值
先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。
需求采集人人有责：
第一，生孩子和养孩子的区别。
第二，二手需求采集工具：单项需求卡片。
单项需求卡片：产品的需求工作不只是需求分析人员的事，而是涉及产品的每一个干系人的义务，至少得参与“采集”的过程。
表 2-3 单项需求卡片模板
需求编号（可由需求人员填写） 需求类型（可由需求人员填写）
包含“采集时刻 + 采集者”信息 功能需求、非功能需求等
来源（Who）（重要信息，方便追根溯源）
产生需求的用户：最好有该用户的联系方式等信息
用户背景资料：受教育程度、岗位经验，以及其他与本单项需求相关经验
场景（Where、When）（重要信息，用来理解需求发生的场景）
产生该需求的特定的时间、地理、环境等
描述（What）（最重要的信息）
尽量用（主语+谓语+宾语）的语法结构，不要加入主观的修饰语句
原因（Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的）
为什么会有这样的需求，以及采集者的解释
验收标准（How） 需求重要性权重（How much）：
（如何确认这个需求被满足了）
1. 尽量用量化的语言
2. 无法量化的举例解释
满足后（“1：一般”到“5：非常高兴”）
未实现（“1：略感遗憾”到“5：非常懊恼”）
需求生命特征（When） 需求关联（Which）
1. 需求的紧急度
2. 时间持续性
1. 人：和此需求关联的任何人
2. 事：和此需求关联的用户业务与其他需求
3. 物：和此需求关联的用户系统、设备，以及其他产品等
