第 4 章 · 用户观

引言#

产品经理最容易高估的能力，是“我懂用户”，这句话太好用了：转化不好，是用户没看懂；老板质疑需求，是用户需要。只要说得足够自信，会议室里就会出现一个看不见的人替所有判断背书，这个人叫“用户”。但“用户”从来不是一个固定身份，有时候他是隔壁工位的运营，急着赶大促页面，需要的不是优雅交互而是一分钟配完活动规则的快捷入口；有时候他是等着看明确指标的数据分析师，而不是一句“用户可能更喜欢 B”；有时候他是明早要汇报的市场同学，最想要的是报表一键导出。而当我们真正面对 C 端时，“用户”又变回沉默的大多数，地铁上单手划手机的白领，加载慢 3 秒就退出；反复比价的宝妈；对弹窗免疫、只想一键跳过的大学生。他们不参会、不发言，只用指尖滑动或卸载。我们在会议室里为一个按钮颜色争得面红耳赤时，真正的用户可能根本注意不到那个按钮在哪，更讽刺的是，无论这个“用户”是隔壁同事还是消费者，他们从不在会议室里，却都要为我们的“我懂”买单。

这一章想回答一个问题：我们凭什么认为自己理解用户？听起来像用户研究问题，其实是产品经理的判断问题。大多数错误，不是发生在“不听用户”的时候，而是发生在“以为自己听懂了”的时候，我们看了反馈，做了调研，拉过数据，画过画像，该有的都有了，然后团队踏踏实实地把本来就想做的东西做出来了，用户被翻来覆去地引用，但最后那个决定，跟用户没什么关系。所以我越来越觉得，理解用户这件事，拼的不是谁更会共情、谁更会访谈，拼的是谁能管住自己。管住自己别急着下结论，别把“我见过”当成“用户也见过”，别把“我觉得合理”当成“用户能懂”，我们得隔三差五跟自己说一遍：我现在知道的，最多算个草图，离真相还差得远。用户研究里最难的一关，从来不是怎么问问题，而是你愿不愿意坐下来承认“我可能完全想错了”，我并不打算将用户访谈、调研等研究技巧展开聊，技巧固然有用，但真正重要的是我们能不能给用户留一个位置，让他真的参与到我们的思考里来，而不是只出现在我们写完的报告里，如果用户从来没有动摇过我们的任何一个决定，那我们其实还没让他进来过。

4.1 用户不是来用功能，是来完成自己的事#

其实我们很多产品经理在做判断的时候会进入一个误区，我们会习惯性假设：用户打开产品，是奔着某个功能来的。这个假设听起来好像没错，电商用户到确认订单页，当然是来确认订单的；运营打开数据看板，当然是来看数据的；私域运营点开群发工具，当然是来发消息的。但只要往真实场景里再多走一步，就会发现用户很少甚至说基本不会把“使用功能”当成自己的目标。我们所谓的功能，其实也只是用户在完成某件事过程中的一个手段，有时候，甚至也只是他们犹豫、补救、确认、想避免出错时恰好路过的一个地方。如果产品经理把功能本身当成任务，就很容易把用户看窄了，你会忙着优化页面、补充模块、增加推荐、强化入口，却始终没看见用户当时真正想完成的那件事。

案例：确认订单页的“加价购”，从促销工具变成生活备忘录

2021 年我在一家社交电商平台负责产品相关工作，当时运营团队拉上产品团队发起了一次关于确认订单页新增“加价购”的功能讨论，我们先还原一下这条链路：用户从购物车点“去结算”，进入确认订单页，核对地址、商品、优惠、总价，然后提交。这个页面原本很克制，核心任务就是让用户确认无误、完成支付，但业务增长压力摆在那里，团队希望在支付前再做一次客单价提升，于是提出在确认订单页加一个“加价购”模块。会议室里很快出现两套方案：

• 运营团队倾向于做“满 99 加 1 元换购”：纸巾、垃圾袋、棉签这类低价刚需品，勾一下就一起下单，理由很直接：行业里都在做，用户也熟悉，上了就能出 GMV。
• 产品团队则更倾向于“智能配件推荐”：买奶瓶推奶嘴，买奶粉推辅食碗，买洗衣液推洗衣球，听起来更像是产品经理会喜欢的答案，因为它更“精准”，也更符合推荐系统的想象。

两边都有道理，接下来很容易陷入方案细节：模块放哪儿、推荐几件商品、价格怎么展示、勾选框怎么设计、会不会影响优惠计算……但这些讨论都默认了一件事：用户到了确认订单页，还有心情再挑一件东西。作为产品团队负责人的我，非常惧怕这样的情况发生，我没急着拍板，而是事后进行了一次黄金链路的漏斗分析及确认订单页的热力图分析，发现一些刺眼的数据：

• 提交按钮的点击率只有 72%：将近 3 成用户已经进了确认订单页，却没有直接点“提交订单”，他们不是没有购买意图，能走到这一步，说明商品、价格、优惠、地址基本都确认过了，那他们停下来的那几秒钟，到底在做什么？
• 用户操作行为高度类似：高度集中在“向上滑动页面”、“返回购物车”，当时推荐模块还没上线，页面上没有任何可逛的推荐区域，用户在确认订单页往上滑，不是在看更多商品；反复返回购物车，也不像是在找优惠。这两个行为更像一种下意识的确认：我是不是漏了什么？

数据只能把问题推到这儿，要继续往下走，就不能靠大家在会议室里来猜测了，我让对应小伙伴找了 10 余位高频出现这个行为的用户做了一次电话回访，电话里只问了一个很朴素的问题：“您在确认订单页犹豫的那几秒，心里在想什么？”。一位买奶粉和尿不湿的妈妈说，她总觉得少买了一样东西，往上滑回去看购物车，后来才想起来忘了加辅食；一位买洗衣液和洗发水的用户说，纸巾快用完了，但买洗衣液时完全没想起来，到了确认订单页才隐约觉得还有事没做；还有一位买牛奶的用户说，每次拆快递才发现又忘了买垃圾袋，单独买一包不够包邮，每次都后悔没顺手带上。一个很明确的模式浮出来：他们不是在想“我还想买什么”，而是在想“我是不是忘了什么”。这两句话差别非常大，“我还想买什么”对应的是推荐、促销、横滑商品列表、满减刺激和更多选择；“我是不是忘了什么”对应的是提醒、补漏、低决策成本和确定性。

这些貌似都在指向一个判断：确认订单页不是一个逛的时刻，而是一个收口的时刻，加价购不是“推荐你可能想买的”，而是“提醒你可能忘了的”。我们将这个判断后来同步给到运营团队，最后这个判断得到了肯定，最终方案简单到有些克制：系统根据用户过去几个月的购买记录推测消耗品周期，面对不同用户优先推荐他们可能当下所需的 1～3 件消耗品，推荐理由上也不是“为你推荐”、“猜你喜欢”，替代的是“纸巾可能快用完了，补一提？”、“家里垃圾袋用完了吗？”，没有横滑列表，没有更多选择，也没有复杂推荐理由。

上线后的数据很干净：补货提醒的点击率 14.8%，明显高于以往结算页推荐模块的常见水平；勾选转化率 69%；A/B 测试里，补货提醒对比配件推荐是 14.8%对 3.2%。而且补货提醒带来的 GMV 里，超过7成来自过去一个月没买过该品类的用户，说明它不是把本来就会买的需求提前截走，而是把“差点忘了”的需求接住了。两个月后回访，有用户说以前经常忘了买纸巾，用完才想起来，单买又不够包邮，现在确认订单时看到提醒，顺手就加上了，感觉像有人帮她记着这些小事。

说服团队的时候，最有用的不是“我觉得用户会喜欢”，而是证据，我们把确认订单页的停留数据、热力图和用户录音放到评审会上，运营原本偏向满减换购，设计师也想过做一排横滑商品，但当大家看到用户在确认订单页平均只停几秒，再听到用户把“提醒”和“推销”分得那么清楚，讨论就从“加购模块怎么做得更丰富”，自然转向了“怎样不破坏确认订单这个任务”。这个案例的价值不止于一个加价购模块，它暴露了一个产品经理很容易踩进去的陷阱：我们习惯按页面功能来思考问题，但用户从来没有按页面功能来过日子。同一个确认订单页，有人想快速收口走人，有人还在犹豫漏没漏东西，有人只是想核对地址，他们共享一个页面，但各自在完成不同的任务。所以首先要判断用户此刻处在什么任务场景里，然后再决定你的产品应该扮演什么角色，角色找准那么方案自然就准了，否则越精细的优化越是在错误的方向上用力。

4.2 走到用户旁边，才看见产品外的那半段#

很多产品方案在系统内部看是完整的，放到用户真实的工作里，却只是半段，产品经理最容易看见的，永远是自己负责的那一段，例如：产品经理关注“用户进入页面→点击按钮→查看数据→提交表单→完成配置”，但任务往往不在这里结束，使用者可能还要“复制数据→打开表格→找人确认→写汇报→发群聊→等审批→向上汇报”或者把这次经验沉淀下来，如果产品只优化自己能记录到的那半段，就很容易误判用户价值。

案例：CMS 的数据看板，从“做一个更全的看板”到“把数据嵌入工作流”

2021 年我所在团队负责过一套 CMS 系统，本质上是一个低代码搭建平台，运营和市场同学用它快速搭建活动页、专题页和大促页，拖拽组件就能配置发布，这套系统已经把页面搭建效率从 3 人/日压缩到 1 小时左右，团队很有成就感。工具越成功，团队就越容易沿着自己的逻辑往下推，当时我们准备新增“数据分析看板”，推理链条非常顺：运营搭完页面，当然想知道效果好不好，过去找 BI 跑数要等大半天甚至一两天；既然页面是 CMS 搭出来的，页面级和组件级的数据自然也能被抽象出来，例如 PV、UV、点击量、转化数据等数据，让运营打开数据看板就能看。我们甚至规划了 8 个图表面板，单看产品形态是很完整的，但这里面藏着一个典型误判：我们理解的是“运营应该怎么看页面数据”，而不是“运营在真实工作中如何使用数据”。

数据看板上线后，PV 远低于预期，很多高频搭建用户明明每天都在CMS里做页面，却没有像我们想象中那样反复进入看板、查看数据，再据此优化页面。这一次，我们没有直接沿着“入口不明显”、“图表不够丰富”这些解释往下优化，而是约了两个高频搭建用户，坐到他们旁边看真实操作：

• 电商运营同学：她点进数据看板，鼠标快速划过趋势图，停在“表单提交量”上看几秒，然后切回编辑器调整了表单文案，这一步和我们的想象还比较接近。但接下来，她关掉页面，打开一个 Excel 表，把 CMS 里的表单提交数填进去，又打开营销自动化后台，查短信打开率和优惠券核销率，再一起填进表格。我问她：“这些能不能都在我们这看？”，她说：“你们这只告诉我页面上表单提交了多少，但我做这个活动的目的不是收表单，是发券让人去核销。我得把前后的数据连起来，才能算出这个页面到底有没有带来生意。你们的数据，我看到一个数就得自己搬走，去和别的数拼起来！”。我们以为自己给她做了一块完整的页面数据看板，但她并没有把看板当成复盘终点，CMS 数据对她来说只是活动复盘链路里的一个输入项，需要和营销自动化数据、活动目标拼在一起，才能回答那个真正的问题：这个活动有没有带来业务结果？
• 用户运营同学：他的操作更让我意外，他根本没有点开数据看板，他做 A/B 测试时，每次都在飞书群里@数据分析师，说“帮我跑个数”。我问为什么不直接在 CMS 看板里看转化率，他说：“我得知道 A 和 B 的差异是不是统计显著，不是光看谁数字大，而且公司要求 A/B 实验必须由分析师用标准方法跑，不能我自己看了就拍板！”。我们以为看板服务的是“一个运营自己看数据、自己做决定”，但没想到的是数据决策是一个协作流程：运营提问题，分析师判断口径，产品或设计理解页面差异，业务负责人拍板，CMS 里的转化率不是没价值，但它不能替代这个协作机制。

临走前我还注意到一个细节：两位同学都会在历史页面上停留，指着效果好的页面说“想参考它的结构，但已经忘了具体好在哪了”或者说“老板问最近页面效果怎么样，我得临时翻好几个地方凑数据写总结”。这说明还有第 3 个问题：数据看过一次就流失了，散落在 CMS、自动化后台、飞书群、Excel 复盘表里，用户需要的不是一块更大的看板，而是能让数据沉淀、被带走、被协作的能力。现场观察之后，我们暂停了数据看板二期迭代，把方向从“做一个更全的看板”调整为“把数据嵌入运营的工作流”。具体做了三件事：

• 增加数据导出能力：让运营可以把某个数据块导出为带口径注释的 Excel 表格，直接粘进复盘表
• 把页面对比和协作分享做进系统：整理好问题描述、页面范围和核心指标，帮运营和分析师之间减少来回沟通成本
• 增加页面案例的数据快照和归档：优秀页面可以存入案例库并标注标签，下次搭新页面时直接调出来参考

这些改动都不炫技，导出一个数据表、分享一个页面对比、给历史页面加一个数据快照，听起来都不像重大发明，但它们比继续堆图表更接近用户的真实任务。数据也验证了方向，最朴素的“导出数据为 Excel 表格”反而跑得最好：每 100 次看板访问触发约 32 次导出，日均导出次数是截图操作的 4.2 倍。30 天内运营发起了 28 次“申请统计检验”，其中 26 次得到分析师回复，平均响应时间从过去的“半天左右”缩短到约 2.3 小时。案例库 60 天内自发存入了 41 个页面案例，其中 12 个被其他运营至少调用过一次。改版后看板访问频率提升了约 1.7 倍，但停留时长反而下降了 18%，用户不是更愿意泡在看板里，而是更快拿到自己要的东西，然后去完成下一段工作。

做内部工具，最容易高估“系统内闭环”的价值，我们会很自然地把用户任务想象成一条从登录到退出的完整路径，然后在这条路径上把所有功能做全。但用户真实的路径几乎不会在系统边界内闭合，他们会频繁地跨系统搬运数据、跨角色对齐判断、跨时间复用经验。真正决定一个工具好不好用的，往往不是它内部的功能密度，而是它在这些“跨”的时刻有没有主动搭把手。产品经理很容易只看到用户在产品里做了什么，但更要紧的问题是：他离开产品后，还要继续做什么？如果那半段任务始终要靠用户自己拼凑，系统里的前半段做得再漂亮，也只是半段。很多功能之所以没被用好，不是因为那一段做得不够完整，而是因为它没有接住用户产品外的那半段任务。功能的价值有时候不取决于它自己多完整，而取决于它能否让用户任务真正闭环

4.3 低使用率背后，常常藏着用户潜在压力#

很多低使用率功能，第一眼看上去都是体验问题：入口不明显、路径太长、提示不清、操作成本高。产品经理很容易顺着这个方向优化，因为它们都能被界面改造解决，也都能很快进入版本计划，按钮外露一点、流程缩短一点、默认值聪明一点、文案清楚一点，数据大概率会有提升。问题是，用户不用一个功能，不一定是因为不会用，有时恰恰相反，他完全知道怎么用，只是不敢用、不愿用，或者用了之后要承担一个产品经理没有看见的后果。这类问题在 B 端、内部工具和运营平台里尤其常见。因为用户不是一个孤立的人，他还嵌在组织关系里，他要对老板负责，对客户负责，对数据口径负责，对群发内容负责，对异常结果负责。一个功能如果只降低了他的操作成本，却增加了他的担责风险，用户未必会用。

案例：企微私域工作台的定时群发，从“让定时更方便”到“补上还能反悔的安全感”

2022 年我们团队接手过一套企微私域工作台，里面有一个触达模块，运营可以把软文、种草内容、活动消息选择“立刻群发”或“定时群发”。从功能设计上看，这个能力很基础，也很合理，内容准备好了，可以立刻发；如果想在第二天早上、周一早高峰或活动开始前固定时间触达，就设置定时。但后台数据显示，定时群发的使用率不到 5%，90%以上内容都选择立刻发送。如果只看数据，最容易得出的结论是：定时群发入口不明显或者操作太麻烦。负责企微的产品同学最开始也是这样判断，于是准备做一版体验优化：把“定时群发”按钮外露，改成更大的日期选择器，再加上“明天 9 点”、“周一早高峰”这类快捷选项，让定时变得和立刻发送一样顺手。这个方案听起来没问题，它确实在降低操作成本，也符合产品经理处理低使用率功能的常规反应，可是这里假设了“用户不使用定时，是因为定时不够方便”的前提。

这位产品同学后来去一个 30 人左右的内容和私域团队现场蹲点，坐在运营旁边看他们发内容，一个运营准备好一篇软文后，仍然选择立刻群发。问他为什么不用定时，他说不是不想用，是不敢用。如果设了明早 9 点发送，晚上 10 点领导突然说标题要改，或者客户临时要加一段话，等他第二天醒来才发现，事情就麻烦了。另一个运营说，他只有怕自己忘记发送时才会用定时，但设完之后反而更焦虑，一晚上打开手机看好几次，怕出问题。还有同学补了一句更关键的话：他们内部的习惯是软文、活动尽量立刻发。不是不需要定时，而是“定时”只解决了什么时候发，没有解决发送前如果情况变了怎么办。

原来我们以为用户缺的是更方便的时间选择器，现场看下来，用户缺的是发送前的控制感。对运营来说，一条群发内容不是一个孤立消息，它背后有领导审核、客户要求、活动节奏、文案风险、用户投诉和业绩压力。只要内容在未来某个时间点自动发出，中间那段等待时间就会变成一种不确定性。用户不是不会设置定时，而是不愿把一条可能变化的内容交给一个不可逆的定时器。“立刻发送”之所以被大量使用，并不是因为它总是更合理，而是因为它更可控。点下去，事情当场发生，如果要改，至少在发之前自己还握着控制权。定时发送表面上让运营更省事，实际上让他多了一段悬空时间，只要组织里存在最后一刻改标题、换利益点、补业务要求的情况，这段悬空时间就会变成心理负担。

后来方案没有继续优化日期选择器，而是改成“预约发送+发送前 30 分钟二次确认”。运营设定发送时间后，内容进入预约状态，在预约期间可以随时撤回修改，不会锁死；发送前 30 分钟，系统再推送一条确认通知，运营可以确认发送，也可以取消退回草稿。这个改动上线后，定时群发使用率从不到 5%提升到 22%，这不是因为日期选择更方便了，而是因为产品补上了“还能反悔”的安全感。

有些产品问题不在操作路径，而在责任结构，产品经理如果只看界面，会问“怎样让他更快完成”；如果看见责任，会问“他为什么不敢完成”，这两个问题会导向完全不同的方案。很多 B 端产品、内部工具和运营系统，真正决定用户行为的不是功能本身，而是功能之后的后果。一个报表导出功能，点击导出的人可能是一线运营，但真正读报表的是主管，质疑口径的是财务或数据同学，最终拿着报表做判断的是业务负责人。产品如果只让一线运营“更快导出”，却没有把指标口径、统计周期、权限边界和版本时间写清楚，导出越方便，后面的解释成本可能越高。用户会觉得功能好用，但不一定敢用，因为他知道一旦报表被质疑，解释的人不是系统，而是他自己。一个审批或群发功能也是如此，使用者关心的不只是“能不能提交”，还关心提交之后有没有修改余地、谁会收到通知、系统是否留下记录、出错后能不能撤回。我们经常把这些能力归到“异常流程”里，实际它们对用户来说可能就是主流程的一部分。因为用户并不是生活在理想流程里，他生活在会临时改需求、会有人追责、会有口径争议、会有突发变化的组织里。

所以在观察低使用率功能时，不要只问用户为什么不用，也不要急着让他评价功能好不好。更有价值的问题是：如果用了，最坏会发生什么？谁会知道？谁要解释？有没有回退？有没有记录？这几个问题听起来不像交互问题，却经常比交互本身更接近用户行为的根因。产品经理常说要降低用户成本，但成本不只是点击次数、学习时间和页面跳转，成本还包括担责成本、解释成本、等待成本、返工成本和心理负担。只看见操作成本，看不见责任成本，可能会反复优化一个“无用”的功能，你把前一种成本降下来了，却把后一种成本转嫁给用户，他当然会绕开你的功能，有些“不使用”，不是冷漠，而是自我保护。

4.4 可靠的用户证据，要能回到具体事件#

用户研究最危险的地方，不是用户会说谎，而是产品经理太容易把用户的话当成完整事实。大多数用户并不是故意误导我们，他们会真诚地表达自己的偏好、抱怨和解释，也会努力回答产品经理提出的问题。但人对自己行为原因的理解，本来就不是完整透明的。人可以反馈自己的感受、判断和选择，却未必能完整表述出这些判断背后的心理过程。在我们的产品工作里，不是“用户不可信”，而是提醒我们：用户的解释需要被尊重，但不能被直接当成因果。这也是为什么“你希望我们做什么”、“你觉得这个方案怎么样”、“如果上线你会不会用”这类问题，很容易把产品经理带偏，用户会基于礼貌、想象、当前情绪、对产品的理解，给出一个听起来合理的答案。这个答案可能有参考价值，但它往往离真实行为还隔着一段路：他过去是否真的遇到过这件事？当时怎么处理？付出了什么代价？有没有绕路？有没有人催他？如果你提供新方案，他是否愿意改变原来的习惯？

产品经理需要区分“声音”和“证据”。**声音很重要，因为它告诉你哪里有不适、哪里有期待、哪里有抱怨、哪里可能藏着机会，但声音进入产品判断之前，必须被放回具体事件里，也就是找到证据。**用户说“这个页面不清楚”，要追问上一次不清楚发生在哪里；用户说“想要导出”，要追问上一次导出后拿去给谁看；用户说“希望更智能”，要追问他现在为了完成这件事用了哪些笨办法；用户说“这个功能我一定会用”，要追问他过去有没有为同类问题主动付出过成本。没有具体事件，用户原话很容易变成一种情感宣泄，有了具体事件，哪怕样本不大，也可能足以推翻一个看起来很合理的产品假设。那么证据有哪些具象的表现，这里我罗列几个常见的：

• 观点：比如“我觉得这个不错”、“我希望你们加一个功能”、“这个页面不好用”。观点不是垃圾，它能帮你发现方向，但往往不能决定最终的产品方案，观点往往更倾向是“声音”。
• 回忆：比如“上周我做活动复盘时，等 BI 数据等了半天”、“上次买洗衣液时，我忘了顺手买纸巾”。回忆比观点更接近事件，但仍然可能被用户加工过，产品经理要继续追问细节。
• 现场动作：你亲眼看到用户打开哪个系统、复制哪个数字、在哪一步停顿、把什么截图发到哪个群里、为什么没有点那个按钮。现场动作会把很多口头解释拆开，让你看见用户自己也没意识到的习惯。
• 动作背后的代价：谁在等他，谁会质疑，谁要担责，哪里返工，哪里出错，哪里会让他不敢继续。因为产品最终要降低的不是抽象痛点，而是这些具体代价。

当然我并不是要说用户访谈没有作用，也不是说情景访谈、现场观察这类才能起作用，而是想表达不同证据解决不同问题。大样本数据告诉你哪里异常、影响有多大；访谈告诉你用户如何理解自己的处境；现场观察告诉你行为如何发生；业务结果告诉你方案是否真的改变了任务完成。**真正可靠的用户判断，通常不是来自某一种证据，而是来自几类证据互相校验。真正有用的用户证据，往往不是单点证据，而是一条能互相咬合的证据链。**数据先指出异常，访谈帮助提出解释，现场观察校准解释是否成立，上线后的行为再验证方案是否改变了任务完成。任何一环都可能出错：数据可能只告诉你问题冒出来的位置，访谈可能被用户事后解释加工，现场观察可能样本太小，上线数据也可能被短期激励污染。产品经理要做的，不是迷信其中某一种证据，而是看它们能不能互相支撑。一旦证据链成立，用户原话就不再是孤立的一句话，它会被放回时间、动作、责任和代价里，成为一个可以被讨论的判断依据。这个时候，团队争论的重心也会发生变化：不再是“用户到底是不是这么说过”，而是“我们是否理解了这句话发生的场景，以及产品应该介入哪一段”。产品经理不能因为“用户未必说得完整”，就摆出一副比用户更懂用户的姿态，那会变成另一种傲慢。更成熟的态度是：用户比我们更懂自己的处境，但他未必能把处境翻译成产品答案；产品经理比用户更懂产品系统，但未必懂用户在系统外承担的生活、工作和组织代价。用户研究的价值，就在这两种“不完整”之间建立证据。

我以前带团队时，经常会要求产品同学在需求内审过程中回答这个问题：你做出这个判断的理由是，存在有力的证据来证明吗？如果答案是“用户说了很多次”，我会继续问：用户上一次为这件事付出了什么？如果答案是“数据下降了”，我会继续问：你有没有看过用户在这个环节前后做了什么？如果答案是“竞品也这么做”，我会继续问：我们的用户任务和竞品的任务是否一致？如果答案是“业务很着急”，我会继续问：着急背后是用户有真实的痛点，还是只是停留在用户嘴上的表达或者是你自己的焦虑中？这个追问不是为了把人问住，而是为了让团队形成一种层层深入，挖掘证据的习惯，产品经理可以有直觉，也需要直觉；但直觉要能被证据校准。不能每次都用“我感觉用户会”开始，用“上线后看数据”结束，上线后看数据当然重要，但如果上线前没有把假设说清楚，数据不好时团队很难知道是用户判断错了、方案形态错了、场景选择错了，还是目标本身错了。可靠的用户证据，最好能回答四个问题：谁在什么具体场景里，试图完成什么任务？他现在怎么做，付出了什么代价？现有方案为什么无法承接住？如果按照这个方案实现了，用户是不是不再会付出之前的代价？这四个问题答不完，也没关系，真实项目里不可能每次都研究到完美，关键是产品经理要知道自己哪里还不知道。知道证据缺口，至少会让你在评审里更谨慎，在方案里留验证点，在上线后知道该看什么，最怕的是证据很薄，语气却很满。用户研究不是让产品经理不犯错，而是让错误更早暴露、更小发生、更容易被修正。

4.5 用户研究不是求证方案，而是重画边界#

很多团队做用户研究，其实是在给已经想好的方案找证据。功能想得差不多了，去问用户喜不喜欢；页面都画出来了，去看用户能不能用；方向内部已经达成一致，去找几句用户原话放进汇报里。这种研究你说没用吧，也不是，它能发现一些细节问题，帮团队少犯点明显的错。但你说它能产生真正的产品判断吗？很难。因为它一上来就把最重要的问题绕过去了：我们到底是不是在解决一件正确的事？

用户研究真正值钱的地方，是它能改变方案的边界。什么叫边界？不光是功能做多大规模，而是产品到底该管什么、不该管什么；能力放在哪个环节、不放哪个环节；哪些事系统做、哪些事用户做、哪些事交给组织里的其他人做；哪些代价该降，哪些代价不能偷偷转嫁出去。很多方案之所以越做越重，就是因为边界一开始就画歪了。你以为自己做的是推荐，其实用户要的是提醒；你以为自己做的是报表，其实用户要的是能带走的材料；你以为自己做的是效率工具，其实用户要的是出错之前还能控制一下。边界画错以后，团队越努力，产品越完整，偏差反而越大。所以用户研究不能光问“用户还想要什么”，还得问“我们现在的方案哪里不对”。后面这个问题比加需求难多了，因为它逼着团队承认，之前的设想没那么稳。一个已经画好的推荐模块，可能得缩成一个提醒；一个已经规划成数据中心的看板，可能得退回工作流里的数据出口；一个原本打算优化入口和控件的功能，可能得先把撤回、确认和留痕补上。这不是把产品做小，是让它站对位置，很多产品失败，不是因为能力太少，而是能力放错了地方。用户研究的价值，就是把产品从它自认为正确的位置上挪开那么一点，挪到用户真实任务会经过的地方。很多产品经理做用户研究，最放不下的就是自己的原方案，方案已经想了很久，原型可能都画了，评审会上也讲过好几轮。用户证据一旦要动边界，就意味着前面的努力有一部分要推翻，这时候人就会本能地把证据往原方案里塞：用户说要提醒，那就在原方案上加个提醒；用户说要导出，那就在看板上加个导出；用户说担心发错，那就在定时页加句提示。这些补丁可能有点用，但不一定解决问题，真正该问的是：这些证据是不是在说，原方案就是方向错了？如果确实错了，最好的改法往往不是加东西，而是换。换任务，换入口，换角色分工，换成功指标，甚至换掉原来那个听起来更完整的产品形态。这个动作不一定更大，很多时候反而更小，但它能让产品更贴近用户真正要完成的事。

一个产品经理成熟不成熟，很大程度上就看这一点：你敢不敢让用户证据动到方案的根，而不是只动到方案的皮。这事对团队也很关键，很多团队并不反感用户研究，但把它做成了流程节点：立项前调研一下，设计后可用性测一下，上线后回访一下，流程走了，判断未必发生。因为用户研究一旦被钉在“验证方案”这个位置上，它就没法挑战方案本身了。我更愿意把用户研究看成一种持续的校准，不只需求前做，方案中做、上线后做、复盘时也做。需求前，它帮你判断问题是不是真的存在；方案中，它帮你判断产品该站在哪里；上线后，它帮你判断真实使用跟假设是不是一回事；复盘时，它帮你把一次项目的经验，变成下一次判断的底子。这也是为什么用户研究不能只是用户研究员的事，研究员可以帮你设计方法、找样本、做访谈、整理洞察，但产品经理不能把“理解用户”这件事外包出去。因为最后要改方案边界的人是你，要在评审会上解释为什么不按原方案做的人是你，要扛资源投入后果的人还是你。一个产品经理如果只把用户研究当材料，他会问：“报告里有没有能支持我方案的结论？”如果把用户研究当判断，他会问：“这些证据是不是要求我重新定义问题？”。前者让研究变成背书，后者才让研究真正进入产品。

当然，也别把用户研究神化，它不能替你搞定所有商业判断，不能替你摆平资源冲突，也不能保证方案一定成。用户证据只回答一部分问题：用户在什么场景下付出了什么代价，产品进去以后有没有可能把这个代价降下来。至于这个代价值不值得现阶段投入，符不符合产品定位，会不会破坏商业结构，能不能跟组织资源匹配上，这些还是要产品经理回到产品观和需求观里去接着判断。用户观不是要产品经理无条件站用户那边，而是要产品经理别拿自己想象的用户去给判断背书。产品观决定什么值得存在，需求观决定什么有资格进队列，用户观决定你对用户的判断离现场有多近。三个放在一起，产品经理才不会一边喊着用户价值，一边做出一款只有会议室用户才会用的产品。

闲言碎语#

做产品这些年，我说过很多次“用户会”，用户会从这里进入，用户会注意这个利益点，用户会理解这套规则，用户会愿意为了更好的体验多走一步。很多时候我说对了，也有很多时候，结果只是没有人回来追问当时那句话。后来我越来越警惕这种表达，不是因为产品经理不能判断，而是因为“用户会”这三个字太轻了。它轻到可以绕过证据，轻到可以掩盖不确定，轻到可以让一个会议室里的方案显得顺理成章。我更愿意把话说慢一点：基于目前这些数据、访谈，我判断用户可能会这样做；如果后续发现他们在某个场景里没有这样做，我愿意回来修改判断。这句话不够漂亮，也不够像一个“很有把握”的产品负责人，但我越来越觉得，产品经理真正的专业性，不是永远显得笃定，而是在不确定里仍然负责任地做判断。承认不知道，并不会削弱产品经理的价值，真正削弱价值的，是明明不知道，却因为会议需要一个答案，就迅速创造出一个用户替自己作证。

我也不喜欢把用户研究讲得太神圣，用户不会自动给你答案，访谈不会自动产生洞察，现场观察也不会自动让产品变好。你还是要判断，要取舍，要承担后果，只是当你愿意走到用户身边，看他真实完成一件事的全过程，你会变得没那么容易自信过头。很多时候，产品经理不是缺少聪明，而是缺少一点迟疑。不是犹豫不决的迟疑，而是在说“用户需要”之前，停下来问一句：我真的看见了吗？最后附上本章的《用户观自查表》，它不教你做用户研究，只在你准备说“用户会”、“用户需要”、“用户不喜欢”之前，提醒你把证据再拿近一点：