00's Adventure

产品经理的用研手册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 提升了某个按钮的点击率,但是它依然不能解决产品的深层次问题。通过测试,我们也许可以知道哪个方案更受欢迎,但却无法解释反常识的结果。测试只能让我们「知其然」,想要「知其所以然」,还是需要配合其他的招式,用心解读。

那么,什么时候该「问」,什么时候该「切」?

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


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

下一篇探讨用户研究与精益方法的关系。


如需转载本文,请联系 uegeek@gmail.com

kidult00 wechat
扫码关注 00 的公众号
支持原创,五毛钱不嫌少~