B端产品经常只有几十个甚至几个核心用户，团队因此得出结论：“样本太少，没法研究。”另一种极端是只访谈业务负责人，把管理视角当成一线体验。
少量专业用户并不意味着不能研究，而是需要更精准地选择角色、观察真实工作，并区分个体偏好与系统问题。
01 先画利益相关者与角色地图
列出使用者、审批者、管理员、购买者、IT、安全和被数据影响的人。一个系统的付费者和日常用户往往不是同一群人。
按任务、权限、频率和熟练度选择样本，而不是只按职位名称。
02 优先研究高风险、高频和跨角色任务
从耗时长、错误多、培训重、合规高或跨部门交接的流程开始。研究资源有限时，不必平均覆盖每个模块。
明确研究问题，例如“为什么审核退回率高”，不要用“了解用户需求”这种宽泛目标。
B端研究方法与用途
| 方法 | 适合发现 | 注意事项 |
|---|---|---|
| 半结构访谈 | 目标、规则、痛点和决策 | 用户可能描述理想流程 |
| 现场观察 | 真实工具、绕行和中断 | 需要权限与隐私保护 |
| 任务走查 | 步骤、信息与角色交接 | 使用真实案例更有效 |
| 日志/工单 | 频率、失败与异常分布 | 数据口径和缺失需核对 |
| 可用性测试 | 界面理解与操作问题 | 场景和数据应接近真实 |
| 共创工作坊 | 对齐流程和优先级 | 不能用投票代替研究证据 |
03 访谈要追问最近一次真实经历
不要只问“你希望系统有什么功能”。让用户回忆最近一次处理订单、审核、异常或报表，展示当时使用的文件和消息。
真实事件能暴露制度与实践差异，也能减少空泛愿望。
04 把绕行当成重要证据
用户导出Excel、在群里提醒、用纸记录，不一定代表他们抵触系统，可能是系统缺少批量、协作或可追溯能力。
先理解绕行解决了什么，再判断应整合、允许还是禁止。
05 小样本用模式和风险，而不是百分比
五个人中三人遇到问题，不等于“60%用户”。可以描述在多个角色、任务和数据中重复出现的模式及其影响。
将访谈与日志、客服、业务指标和测试交叉验证，提高可信度。
06 把洞察转成可执行设计输入
每条洞察连接到任务、证据、影响、设计机会和仍待验证的假设。
研究报告不应只停留在画像和引言，还要支持流程、权限、信息架构和优先级决策。
常见问题
B端研究需要多少用户？
没有固定数字，应覆盖关键角色、任务和差异，做到模式趋于稳定并能交叉验证。
客户不允许直接访问用户怎么办？
可通过代理访谈、工单、录屏、现场陪同和可用性测试逐步获取证据，但应说明限制。
业务专家能代表所有用户吗？
不能完全代表。他们了解规则，但一线用户更清楚实际操作和绕行。
专业用户说“习惯了”还需要改吗？
看任务效率、错误、培训和新用户问题。习惯可能掩盖长期成本。
研究会不会拖慢项目？
早期聚焦研究通常能减少后期返工，关键是围绕高风险问题控制范围。
链接复制成功
