面对一个新问题时，我首先想知道的不是“页面要做成什么样”，而是这件事为什么会发生：谁正在什么情境下做什么，他想完成什么，又是什么让事情变得困难。只有回到真实的任务和处境里，我才有可能区分用户说出的需求、业务希望实现的目标，以及系统真正需要改变的地方。
需求不是单点输入。只有把角色、业务、系统、场景和约束放在一起，才能从表层诉求回到真正需要改变的关系。
从诉求背后寻找真正的问题
我会把访谈、观察、资料梳理和业务讨论看作同一件事的不同入口。用户的表达让我理解感受和习惯，业务规则让我看到组织如何运转，数据和流程则帮助我发现那些仅靠描述不容易暴露的断点。它们不是为了堆积信息，而是为了拼出一张足够接近现实的问题地图。
在这张地图里，我尤其关注几种关系：角色之间如何协作，信息如何流动，决定在哪个环节发生，风险由谁承担，结果又如何被感知。复杂业务的难点常常不在某个功能缺失，而在这些关系彼此割裂。把关系重新连接起来，往往比增加一个入口或页面更接近问题的核心。
把事实、假设与机会分开
理解问题并不意味着等到所有信息都齐全才开始。我会先区分已经知道的事实、仍需确认的假设和可能存在的机会，再用影响程度与不确定性决定下一步。这样既能避免过早押注某个方案，也不会因为复杂而停在研究阶段。
这一阶段最终形成的不是厚重的调研报告，而是一个清晰的问题定义：服务谁、发生在什么场景、最关键的阻力是什么、希望产生怎样的改变，以及哪些边界不能被忽略。它为后面的设计提供方向，也让团队知道我们正在共同解决什么。
我真正想定义的，不是页面还要增加什么，而是产品中的哪一种关系需要被重新理解。
