“接触不到用户”通常不等于完全没有证据，而是没有一条方便、稳定、合规的招募渠道。可以先用替代证据降低风险，但必须清楚标注：哪些来自真实行为，哪些来自一线人员转述，哪些只是团队假设。
“接触不到用户”通常不等于完全没有证据，而是没有一条方便、稳定、合规的招募渠道。可以先用替代证据降低风险，但必须清楚标注：哪些来自真实行为，哪些来自一线人员转述，哪些只是团队假设。
01 先划一条底线：替代证据不能冒充用户证据
没有真实用户参与时，团队仍然可以做资料分析、流程梳理、专家评审和低风险验证。但不能把同事的意见写成“用户需求”，也不能用几段生成式内容假装完成了访谈。
更诚实的表达是：
- “客服工单显示，近三个月该问题反复出现”；
- “销售认为采购人最关心权限，但尚未向采购人验证”；
- “根据竞品评论提出一个假设，需要在下一轮真实研究中确认”。
这种区分不会削弱研究，反而让决策者知道承担了什么风险。
02 建立一条证据阶梯
| 等级 | 证据来源 | 可以支持什么 | 主要风险 |
|---|---|---|---|
| A | 当前目标用户的真实行为、访谈与任务测试 | 理解场景、行为、语言和困难 | 招募成本高，样本仍可能偏 |
| B | 产品日志、搜索记录、客服工单、退订与失败数据 | 发现问题规模、路径和异常 | 缺少动机与上下文 |
| C | 与用户长期接触的一线人员，如客服、实施、销售 | 快速收集常见问题和场景 | 转述会被岗位目标和记忆过滤 |
| D | 相邻角色、过去用户、代理用户、领域专家 | 验证概念、术语、流程合理性 | 行为不一定代表目标用户 |
| E | 竞品、公开报告、论坛评论、专家评审 | 建立假设、发现行业模式 | 样本来源和真实性不可控 |
越往下，结论语气越要谨慎。E级证据适合告诉团队“值得调查什么”，不适合直接决定高风险功能。
03 先找已经存在的用户痕迹
很多公司说没有用户研究渠道，却已经积累了大量用户痕迹：
- 搜索关键词与站内无结果搜索；
- 客服聊天、工单分类和升级记录；
- 销售演示中的问题、丢单原因和采购清单；
- 产品漏斗、反复点击、撤销、导出和失败日志；
- 实施培训记录、帮助中心搜索和常见配置错误；
- 退款、退订、合同变更与投诉材料。
这些资料不能解释全部原因，但能帮助团队把问题范围从“用户不喜欢”收紧为“新管理员在导入成员后经常停留在权限配置页”。有了明确线索，后续即使只接触少量用户，也更容易问到关键问题。
04 让一线人员提供事实，不让他们替用户作答
客服、销售和实施顾问非常重要，因为他们长期处在用户问题的入口。但访谈方式要改变。
少问：“客户最想要什么功能？”
多问：
- 最近一次客户因此卡住是什么时候；
- 当时客户准备完成什么；
- 客户用了什么原话；
- 一线人员采取了什么办法；
- 问题是否反复发生，发生在哪类客户；
- 有哪些记录、截图或工单可以回看。
一线人员提供的是事件与模式，不是用户的最终代理。尤其销售提出的需求，可能同时受到成交压力影响；客服看到的则多是已经发生问题的人。需要把来源偏差写进分析。
05 六种现实可行的替代路径
从存量客户关系中建立“小窗口”
不必一开始建立庞大的研究社区。可以请客户成功或客户经理每月协助邀请少量不同角色，明确研究不是销售会议，并把时间控制在30至45分钟。先稳定渠道，再扩大样本。
在培训、实施和支持过程中观察
B端产品很适合研究真实配置、导入、权限和交接过程。研究人员可以旁听一次培训或远程支持，在获得同意后记录用户在哪里停顿、反复询问和建立自己的表格。
使用相邻用户验证低层问题
当真实审批人暂时无法参与，可以让熟悉同类工作的行政或财务人员验证术语、信息结构和基本流程。但涉及组织政治、合规责任或真实决策压力时，相邻用户的结论不能替代目标角色。
用内部专家做认知走查
领域专家可以检查规则遗漏，设计和产品人员可以做启发式评审，研发可以检查技术边界。这能提前清理明显问题，但属于专家证据，不是用户可用性证明。
从公开资料中提取语言和场景
行业论坛、应用商店评论、帮助中心、采购文件和监管材料可以帮助团队理解常见术语与风险。不要统计成精确比例，也不要假设发帖者代表全部用户。
先做低风险试点
无法完整研究时，不要直接全量发布。选择一组愿意合作的客户、一个业务单元或非关键流程，建立反馈和回滚机制，用真实使用补上证据缺口。
06 哪些决定可以先做，哪些最好等真实用户
| 决策 | 替代证据是否足够 | 建议 |
|---|---|---|
| 统一组件样式、修复一致性问题 | 通常足够 | 结合专家评审和现有数据推进 |
| 明显的文案歧义、错误提示缺失 | 通常可以先修 | 后续观察是否降低错误 |
| 新增关键业务流程 | 风险较高 | 至少找到目标角色做任务验证 |
| 改变权限、费用、合规或不可逆操作 | 不足 | 必须获得真实场景和专业审查 |
| 重新定义产品价值与套餐 | 不足 | 需要接触购买者、使用者和决策者 |
| 低风险概念探索 | 可以 | 明确标注为假设，不直接承诺开发 |
07 一个两周的“研究救援计划”
前三天：整理现有证据
收集产品数据、客服与销售记录，邀请一线团队用具体事件说明问题。输出问题地图，而不是功能愿望清单。
第四至六天：建立招募入口
设计简短筛选条件，由客户成功、销售或社区邀请不同角色。同步准备保密、激励和时间安排，降低客户参与成本。
第二周：少量真实研究加交叉验证
先进行3至5场高质量研究，重点验证证据地图里风险最高的问题。每场结束当天与数据、工单或现场记录交叉检查，再决定是否追加某类用户。
即使最终人数不多，真实证据也能校正团队对替代资料的解释。
08 三件不要做的事
把公司员工当成目标用户
内部员工可以试流程、找缺陷，但他们熟悉产品语言、业务目标和组织背景，不能代表第一次使用的客户。
让“合成用户”代替访谈
生成式工具可以帮助整理问题、模拟不同假设，却无法提供真实经历、组织约束和意外行为。它适合准备研究，不适合作为用户证据。
用没有上下文的竞品评论决定功能
公开评论常集中在极端体验，也缺少版本、地区和用户类型。可以用来发现问题，不应直接推算需求规模。
09 结论怎么写才诚实又有用
推荐把发现分成三栏：
- 已观察事实：来自真实行为或可核验记录；
- 较强推断：多个来源一致，但仍缺目标用户确认；
- 待验证假设：主要来自专家、竞品或单一渠道。
同时记录“如果这个假设错了，代价是什么”。低代价决定可以小步试验，高代价决定则应优先解决招募问题。
常见问题
B端客户不愿意参加研究怎么办？
先降低参与成本和风险：时间短、问题明确、不讨论商业机密、允许匿名，并通过客户经理解释研究目的。还可以把研究安排在培训、复盘或续费沟通之外，避免用户以为这是销售活动。
可以只访谈销售和客服吗？
可以用来形成初始问题地图，但不能作为最终验证。销售、客服、实施分别看到购买、故障和落地阶段，三者交叉能减少偏差，之后仍应争取接触至少少量目标用户。
什么时候必须暂停设计，先解决招募？
当决定涉及安全、隐私、资金、权限、医疗、合规或大规模开发，且团队没有任何真实行为证据时，应暂停关键决策。继续做得越精细，返工代价越高。
10 让研究和设计真正进入产品决策
链接复制成功
