16.3 理解用户
数据告诉你"发生了什么"，用户访谈告诉你"为什么发生"。两者结合才能做出好决策。
"不好用"到底是哪里不好用？
小明收到一条反馈："你这个产品不好用。"
他盯着这五个字，完全不知道该改什么。是界面不好看？操作太复杂？功能不够？加载太慢？
老师傅说："去问用户。不是发个问卷，是真的跟他们聊。"
The Mom Test：怎么问才能得到真话
小明约了一个用户线上聊。他问："你觉得我的产品怎么样？"
用户说："还行吧。"
聊了 15 分钟，小明什么有用的信息都没得到。老师傅笑了："你问错问题了。"
老师傅给他介绍了 The Mom Test——一套用户访谈方法，核心思想是：问对问题，连你妈都没法对你撒谎。
这个方法有三条核心原则。第一，谈论过去而非未来——过去的行为是真实的，"你上次怎么做的"比"你以后会不会用"可靠一万倍。第二，谈论具体而非笼统——"你上次遇到什么困难"比"你觉得怎么样"有价值得多，细节能揭示真实问题，笼统回答什么都说明不了。第三，少问多听——让用户多说，你少说，从细节中发现真实需求。
好问题 vs 坏问题
这是 The Mom Test 最核心的部分。
"你会用这个功能吗？"是坏问题，因为未来意愿不可靠——大部分人会出于礼貌说"会"。好的替代是"你上次怎么解决类似问题的？"，这问的是过去的真实行为。
"这个功能重要吗？"也是坏问题，因为你会得到礼貌性的肯定。好的替代是"你什么时候需要用到这个？"，如果用户说不出具体场景，说明其实没那么需要。
"你觉得这个设计怎么样？"是坏问题，因为可能只是客套。好的替代是"这个设计让你哪里困惑？"，直接问困惑点。
"你想要什么功能？"是坏问题，因为用户不是产品经理，他们不知道什么功能是可行的。好的替代是"你最近遇到什么困难？"，从困难出发，你来想解决方案。
小明的第二次访谈
小明学了 The Mom Test，又约了一个用户。这次他换了问法。
"你上次用我的笔记应用是什么时候？"
"上周吧，想记个会议纪要。"
"当时顺利吗？"
"嗯……其实我找了半天那个新建笔记的按钮。后来发现要先选分类才能新建，我当时就想随便记一下，不想选分类。"
小明恍然大悟。他设计的"先选分类再新建"流程，在他看来很合理——但用户只想快速记点东西，分类是后面的事。
他又让用户演示了一遍操作过程。观察中他发现，用户在好几个地方犹豫了，甚至有一次点错了按钮。这些问题，用户自己都没意识到，但小明看得清清楚楚。
这就是观察的价值。用户嘴上说"还行"，但操作时的犹豫、停顿、皱眉，才是真实的反馈。犹豫停顿说明用户不确定该怎么做，反复尝试说明功能不直观，表情变化（困惑、沮丧、惊喜）是最诚实的评价，跳过某个步骤可能意味着他们根本没看到那个功能。
访谈实操
小明的第二次访谈效果好多了，他想把方法固定下来。老师傅帮他梳理了一套实操框架。
怎么问
访谈的核心是用开放式问题打开话题，再用追问把细节挖出来。
开放式问题分几类：背景类（"能说说你的使用场景吗？"）、行为类（"你上次怎么完成的？"）、困难类（"哪里让你感到困惑？"）、感受类（"那个时刻你感觉怎么样？"）。这些问题没有"正确答案"，用户可以自由发挥，你才能听到真实的想法。
用户回答后，别急着跳到下一个问题。用追问把模糊的回答变具体："能具体说说吗？""能举个例子吗？""和之前的方案相比呢？"还有一个最强的追问技巧——沉默。不说话，让用户继续。用户说一半时，不要急着回应或给建议，沉默会促使他们继续说下去，往往后面的话才是最有价值的。
怎么做一次完整的访谈
访谈前要做准备：明确你想验证什么假设，准备好核心问题，不要即兴发挥。开场时说明目的，强调没有"正确答案"，让用户放松。访谈中让用户演示操作过程，不要打断，用好问题深入挖掘。记录时要记原话，不要只记你的总结——你的总结可能已经过滤掉了关键信息。访谈结束后 24 小时内整理笔记，因为记忆会淡化。
做多少次够？不需要太多。小明做了 6 次访谈，从第 4 次开始就反复听到同样的问题了。一般来说，1-3 次能开始发现模式，5-10 次大部分问题会重复出现，超过 10 次新发现就递减了。当你连续两次访谈都没有听到新东西，就可以停了。
从反馈到行动
访谈做完了，一堆笔记摆在面前。怎么从"用户说了什么"变成"我该改什么"？老师傅教小明分四层提炼。
第一层是原始反馈，比如"找不到设置在哪里"。第二层是问题，设置入口不明显。第三层是洞察，用户期望在右上角找到设置（因为大部分应用都这么放）。第四层是行动，移动设置按钮到右上角。
从原始反馈直接跳到行动很危险——"找不到设置"不一定意味着要移动按钮，也可能意味着需要加个引导提示。中间的"问题"和"洞察"两层，帮你理解真正的原因，才能找到正确的解决方案。
常见误区
老师傅提醒小明几个新手容易踩的坑。最常见的是推销产品——你忍不住想解释"其实这个功能在这里"，但这样用户就不会继续说真话了，保持中立。引导答案也很常见——"你是不是觉得这个按钮太小了？"用户只会附和你，让他们自由表达。只听好的是人之常情，但负面反馈才是金矿。过早解决是技术人员的通病——用户还没说完，你已经在想怎么改代码了，先理解再解决。
定性 + 定量：两条腿走路
访谈给了小明很多"为什么"的答案。但老师傅提醒他："访谈是小样本，别只听几个人的话就下结论。把访谈发现和 Umami 数据对照着看。"
数据（定量）告诉你 What——发生了什么，客观可测量，大规模覆盖，能看到趋势和模式。反馈（定性）告诉你 Why——为什么发生，主观但深入，小样本但有深度，能揭示背景和原因。
小明把访谈发现和 Umami 数据对照，发现了两个清晰的改进方向。数据显示某页面跳出率 70%，访谈中用户说"找不到核心功能入口"——改进导航。数据显示注册转化率只有 30%，访谈中用户说"表单太长了"——简化注册。
单看数据，你只知道"跳出率高"；单听反馈，你不确定是个别现象还是普遍问题。两者结合，才能确信该改什么。
北极星指标
老师傅问小明："你的产品最核心的一个指标是什么？"
小明想了想："用户数？"
"不对。用户数是虚荣指标——它只会涨，不会告诉你产品好不好。你要找的是北极星指标——最能反映产品核心价值的那个数字。"
不同类型的产品，北极星指标不同。SaaS 工具可能是月活跃用户，电商可能是订单转化率，内容平台可能是内容消费时长，工具产品可能是核心功能使用率。
对小明的笔记应用来说，北极星指标可能是"每周创建笔记数"——这直接反映了用户是否在持续使用核心功能。如果这个数字在涨，说明产品在变好；如果在跌，不管用户数怎么涨，都说明有问题。
假设验证循环
有了数据和反馈，小明开始学习一种更系统的思维方式：假设驱动。
不是"我觉得应该改 X"，而是"我假设改 X 会带来 Y 效果，因为 Z 原因"。然后设计实验验证这个假设。
假设的陈述格式是："如果 [改变 X]，那么 [预期结果 Y]，因为 [理由 Z]"。比如："如果简化注册表单，那么注册转化率会提高 20%，因为用户更愿意完成简短流程。"
验证假设最直接的方法是 A/B 测试——把用户随机分成两组，一组看旧版本，一组看新版本，只改变一个因素，比较效果。关键是单一变量——如果你同时改了三个东西，就不知道是哪个起了作用。
案例：Super Daily 的注册优化
一个真实案例。数据显示注册页流失率高达 70%。
假设：注册表单太长，要求信息太多，导致用户中途放弃。
实验：简化注册表单，只保留邮箱，其余信息注册后收集。
| 版本 | 转化率 |
|---|---|
| 原版本（7 字段） | 30% |
| 新版本（1 字段） | 55% |
转化率提升 83%。一个简单的改动，效果远超预期。这就是假设驱动的威力——不是拍脑袋改，而是有依据地改，改完有数据验证。
数据驱动的陷阱
数据很有用，但也容易误导。
最常见的陷阱是"相关即因果"——A 和 B 同时发生，不代表 A 导致了 B。冰淇淋销量和溺水事故正相关，但买冰淇淋不会导致溺水，它们都是夏天的结果。要验证因果关系，需要设计实验。
选择性偏差也很常见——只看支持你观点的数据，忽略不支持的。确保你看的是全部数据，不是挑出来的。
短期主义是另一个坑——某个改动短期内提升了转化率，但长期可能伤害留存。关注长期趋势，不要被短期波动迷惑。
还有数据崇拜——完全依赖数据，忽略直觉和反馈。数据不是万能的，有些东西数据看不到。以及过度分析——花太多时间分析，迟迟不行动。够用就行，先做再说。
常见问题
Q1: 数据量小怎么做分析？
小数据量时，定性反馈更重要。每个用户的反馈都更有价值，深入访谈比大规模统计更有效。不要因为"样本量不够"就什么都不做。
Q2: 用户说的和做的不一致怎么办？
相信行为，不相信语言。用户说"很好用"但使用时一直皱眉，说明有问题。这就是为什么观察比询问更有价值。
Q3: 数据和反馈矛盾怎么办？
优先相信数据，但用访谈理解原因。数据可能揭示了你没注意到的模式。
Q4: 没有数据团队怎么办？
不需要。用 Umami 等现成工具就够了。从简单的指标开始——留存率、核心功能使用率、转化率。不需要复杂的数据基础设施也能开始数据驱动。
小明现在知道该改什么了。但怎么改？一次性全改完？还是分批来？改完怎么告诉用户？
下一节，我们来聊迭代的节奏和成长。