在提出方案前，用同理心框架把用户问题讲清楚…

适用于启动发现研究、确定优先级或撰写 PRD 时，先对齐谁是受阻用户、想做什么、为何受阻，再讨论解决方案。

适用场景

解决思路

1. 收集用户上下文：整理用户访谈或研究中的直接引语、观察到的行为和痛点。
2. 收集 Jobs-to-be-Done 洞见：明确用户“雇用”产品来完成什么，参考 `skills/jobs-to-be-done/SKILL.md`。
3. 明确 persona：确定具体是谁遇到该问题，参考 `skills/proto-persona/SKILL.md`。
4. 收集约束数据：地理、技术、时间、人口统计学等限制。
5. 若缺少上下文，执行发现访谈、情境调查或用户影子观察；不要编造问题。
6. 以 persona 视角填写 Problem Framing Narrative：在 “I am” 中描述关键 persona，突出 3-4 个关键特征或痛点。
7. 填写 “Trying to”：用一句话列出 persona 最关心的期望结果。
8. 填写 “But”：描述阻止 persona 达成结果的障碍，列出 1-3 个 job-to-be-done 或结果阻碍。
9. 填写 “Because”：以有同理心的方式描述根因。
10. 填写 “Which makes me feel”：从 persona 视角描述情绪。
11. 质量检查 “I am” 具体性：能否想象出这个人，还是泛泛的“忙碌专业人士”？
12. 质量检查 “Trying to” 清晰度：这是结果（可衡量）还是任务（活动）？
13. 质量检查 “But” 深度：这些是真实障碍还是只是不便？
14. 质量检查 “Because” 诚实度：这是根因还是症状？
15. 质量检查 “Makes me feel” 真实性：情绪来自研究还是假设？
16. 记录 Context & Constraints：列举地理、技术、时间或人口统计因素。
17. 示例约束：必须在网络受限的农村离线工作；由不熟悉复杂软件的非技术用户使用；时间敏感，决策须在 24 小时内完成。
18. 检查约束相关性：这些约束是否直接影响问题？
19. 检查约束具体性：是否足够具体以指导设计决策？
20. 将叙事综合成 Final Problem Statement：一句有力、简洁、有同理心的总结。
21. 使用公式：`[Persona] needs a way to [desired outcome] because [root cause], which currently [emotional/practical impact].`
22. 示例：`Enterprise IT admins need a way to provision user accounts in under 5 minutes because current processes take 2+ hours with manual approvals, which causes project delays and frustrated end-users.`
23. 检查最终陈述一句话：若需要多句说明问题还不够清晰。
24. 检查可衡量：能否判断问题是否已解决？
25. 检查同理心：是否能在情感上引起共鸣？
26. 检查可分享：能否在会议中说出来并让利益相关者点头？
27. 用用户验证：向经历该问题的人朗读；他们是否说 “Yes, exactly!”？
28. 与利益相关者分享：产品、工程、设计和高管；是否对齐所有人？
29. 根据反馈迭代：若有人说 “I don't think that's the real problem”，继续深入挖掘。
30. 避免方案夹带：不要把“缺少某功能”当问题；重述为用户期望达成什么。
31. 避免业务问题伪装成用户问题：不要写“用户想提高我们的收入”或“问题是我们的流失率”；追问用户为何流失或什么会让他们多花钱，并从其视角表述。
32. 避免泛化 persona：不要写“忙碌专业人士想更高效”；具体到如销售代表用表格手动管理 50+ 线索，想优先跟进且不遗漏高价值机会。
33. 避免症状代替根因：不要停在“UI 令人困惑”；连续问为什么，直到找到根因，例如用户对系统如何运作没有心智模型。
34. 避免捏造情绪：不要用“赋能、愉悦”等营销式情绪；使用用户访谈中的真实引语，如 frustrated、overwhelmed、anxious、stuck。

适用边界 · 注意事项

• 尚未进行任何用户研究时不要使用：不要猜测，先做访谈。
• 不适用于内部运营问题；此框架针对面向用户的问题。
• 不要把它当作 PRD 的替代品：它框定问题，PRD 定义解决方案。