产品经理的用研手册08 - 用研四式之「切」

今天我们来介绍用户研究「望闻问切」第四式，也是最好玩的招式：做试验。

如果说用户研究的目的无非是解答疑惑、辅助决策，那么是不是也可以跳出「假设-验证-判断」的循环，直接测试用户的反应和行为，直接获得判断？

答案是肯定的。

做试验的目的，是用较低的成本去测试想法的可行性和接受度，以及从中发现可能会遇到的问题。

人心难测。互联网变化如此之快，有时候我们可以通过逻辑和分析得出结论，但是更多时候需要把手伸到水中一探深浅。前面花了那么多时间望、闻、问，这回终于可以来真的了。

测试态度和概念

当我们有一些新的想法，尤其是一些比较具体的点子，不知道用户会如何看待，想在开始做之前快速收集一些想法。这时候除了去找用户聊，还可以直接在产品或者用户论坛中拟造一些信息，吸引用户的注意，获取他们的反馈。

第一招，以假乱真的泄露版。

2004 年愚人节，Google 对外发布了拥有 1GB 存储空间的免费邮箱 Gmail，被大家当做笑话，也引发了无数讨论。到了第二天，大家才发现只是来真的，Gmail 一炮而红。

第二招，先建城门后建城。

功能太复杂来不及开发？但是又想提前收集反馈？没问题，入口先摆出来。但是注意不要玩火自焚，承诺最终还是要以某种方式兑现的。

比如 2015年火起来的计步 App Walk up ，记录每天的步数，然后可以在虚拟的世界地图内前进，抵达不同的城市。因为挤牙膏般的开发进度，不得不先放出入口，再慢慢开发。这个过程中可以收集大量的反馈。

测试新版本的使用体验

每当产品有较大改动时，产品经理都免不了神经紧绷：如果上线后效果不好怎么办？如果骂声一片怎么办？

那么就尽早做用户测试，尽早反馈。

这里所说的测试，跟前面介绍过的可用性测试基本类似，只是不必等到开发完成才开始找用户测试，而是在概念阶段、设计阶段、开发阶段，就可以用一些「假」的原型或者半成品给用户试用，只要能够让用户明白这只是初步一些想法，希望了解他对这些想法的意见。

阶段	展示	测试什么
雏形	线框图	用户对产品的理解和需求，主要模块的设计和衔接是否合理
设计	界面原型	用户对流程和界面的理解，界面可用性
开发	Demo 版本	真实的使用体验，有哪些 bug
测试	可上线版本	产品上线后的效果，整体可用性

在设计开发阶段，还不需要完整、严谨的测试，只需要快速了解用户意见、找到明显问题的「迷你测试」：

测试不同方案的真实效果

在产品设计开发过程中，总是有各种各样的纠结，特别是两个方案摆在一起，不相伯仲，改选哪一个？说到这里，A/B test 终于要出场了。

大家对 A/B test 的直观印象是：有 A、B 两个方案，分别放在线上，测试看哪个效果好，最终就采用哪个。

每当有重要页面的修改和流程上的优化，通过灰度发布到 1% 或者 5% 的用户，看实际数据的变化（访问时间增加、留存提高、下单率提高等），决定此修改到底是 100% 发布还是被砍掉。听起来简直是完美的解决方案，对不？

但是事情远没有这么简单。A/B test 的本质，是受控的对照组科学实验。通过严谨的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论推广到全体样本仍然可信。

什么是「可控」？变量是定义清晰、完全受人为控的。

假设有一个因变量 Y（比如购物车结算率），它的变化会受到 A、B、C、D、E、F、G 等 7 个自变量的影响（如何确定只有这些影响因素？），且这种影响无法通过确定的函数来表示。我们现在设计了两个方案，想提高 Y，怎么通过实验验证哪个方案更有效呢？可以接受的做法是，进行若干组试验，让 A 的值变化，而其他自变量全部不变，若 Y 也产生变化，说明 A 的改变起到了效果。

但是如果现在有两个方案，一个改动了 A、C、D，一个改动了 B、D、G，就无法证明是哪些因素影响了 Y 的变化，也就无法判断到底哪个方案更优。

A/B test，难就难在识别所有自变量，并且控制单一自变量的变化。数据不全、脏数据、随机事件、建模人为因素等等影响，都会影响 A/B test 的结果。要解决这个问题，对采样、聚类、流量分割等要求非常的高，而且要检验统计结果的有效性。

所以在现实应用中，A/B test 多用于测试界面元素/控件变化对结果的影响，因为这些因素容易分离和控制。大部分实验只能带来个位数百分比的改进，或者甚至是分数百分比。

A/B test 是好东西，但是要真正用好，需要特别注意实验设计和数据统计：

测试不是万能

不论是用户测试还是 A/B test，都无法完全反应客观现实。即便通过 A/B test 提升了某个按钮的点击率，但是它依然不能解决产品的深层次问题。通过测试，我们也许可以知道哪个方案更受欢迎，但却无法解释反常识的结果。测试只能让我们「知其然」，想要「知其所以然」，还是需要配合其他的招式，用心解读。

那么，什么时候该「问」，什么时候该「切」？

如果重在探究背景和原因，用「问」；如果需要快速测试行动结果，用「切」。当然，另外一个重要的考量因素是执行的成本，面对面调研要花费较多的时间获取和分析数据，灰度试验需要把多个方案都实现出来，选择哪一种，投入产出比会更高？最终还是要靠经验去做成判断。

产品经理的用户用研四式「望闻问切」就介绍完了。