1. 场景（Situation）

用户在特定时间、地点、角色下，执行某项任务或面临某种情境的具体环境。

特点：  

- 客观性：是用户实际经历的“真实情境”，可描述为“谁（Who）在什么时间（When）、什么地点（Where）、做什么（What）”。  

 - 可复现性：能被观察或记录，例如“财务人员在月底需要手动核对多部门的Excel数据，以生成月度报告”。

 2. 痛点（Pain Point）

用户在特定场景中遇到的具体问题或障碍，这些问题通常影响效率、成本或结果，并且可以通过数据或用户反馈进行量化。

 特点：  

 - 客观事实：用户明确存在的问题，而非主观愿望  

 - 可量化：可通过数据或用户反馈验证

 - 情绪共鸣：隐含客户的不满或焦虑

 - 业务影响：直接关联到客户的核心目标（如营收、合规、竞争力）。

 3. 需求（Need）

用户为解决痛点而提出的期望或解决方案，可能是功能、工具或服务。

特点：  

- 主观性：是用户对痛点的“理想化解决方式”，可能包含不切实际的期望，可以理解为用户对于痛点的“原始需求”

- 可分层：分为“刚需”（必须解决）和“想要”（锦上添花），需优先级区分。  

这三个词如果一定要有一个动词来承接，我感觉应该是下面这样的。

顺便讲讲案例到底怎么写：

1.场景还原：

·目的：为读者提供一个具体的背景，使他们能够理解客户所处的环境和面临的挑战。

·方法：使用“Who-When-Where-What”框架来强制还原客户的具体业务流程和现有工具/方法。

Who（角色）: 生产主管/质检员/设备维护工程师  

When（时间）: 每月月底/设备突发故障时  

Where（地点）: 车间现场/跨部门协作会议  

What（任务）: 人工核对生产报表/处理设备报警信息

2.痛点挖掘：

·目的：明确客户在特定场景中遇到的具体问题或障碍，这些问题通常影响效率、成本或结果。

·方法：量化问题（如成本、效率、风险）或具体描述问题，并指出对企业或个人的隐性影响。

例如，人工录入导致数据错误率10%，影响采购决策，额外增加2天纠错时间。”

3.需求翻译：

·目的：基于用户的场景和痛点分析，结合用户的“原始需求”，所拆解出的可量化、可落地的改进目标与技术路径。

·方法：问题导向，不要绑定具体技术方案，要有明确的验收指标，包含用户的核心需求。

写在最后，

很显然，即便需求的“文字”内容相同，而基于场景的变化、业务/个人痛点的不同，常规的需求对接往往就失效了...

场景X案例、痛点X挖掘、需求X翻译...

按照这个逻辑，应该先做场景匹配会...

有人干这个么？没有...因为出成绩太慢

ALL

#tob #案例撰写 #供需对接